【转】京东金融App端链路服务端全链路压测策略

京东金融移动端全链路压测历时三个月，测试和服务端同窗通过无很多天日夜夜，通宵达旦，终于完成了移动端链路的测试任务。整个测试有部分涉及到公司敏感数据，本文只对策略部分进行论述。

1.系统架构与策略

在聊性能测试以前，简单的对金融系统架构进行简单的梳理。京东金融App架构较为复杂，为了说明问题对架构进行简化和抽象。

金融App客户端主要是经过原生主框架和运营平台（乐高）配置搭建组成App客户端；主框架和运营平台（乐高）经过调用网关接口链接各个业务系统。实现整个业务正常运转。金融App移动端618专项测试包含App客户端专项测试和App链路服务端性能两部份内容，本文主要对App链路服务端性能进行简单说明。

 

京东金融App业务模拟示意图

根据架构特色和业务特色，将金融移动App链路服务端性能测试。共分为三个阶段，服务端基础能力测试、服务端相关业务链路测试、服务端全链路预演等三个阶段。

2.测试方案及实施要点

经过对移动端业务的特色和架构综合分析，将移动端链路分为三个阶段进行测试，每一个测试阶段侧重点和目标不一样，经过分阶段实施，一步步测试和验证金融App链路是否可以完成并知足618业务要求。

在本次618备战服务端测试主要分三个阶段，第一阶段主要进行服务端能力和故障模拟；第二阶段主要进行业务能力测试和业务链路性能测试。第三阶段主要进行全链路压测，模拟线上用户在高并发下服务端各业务的表现及业务升降级演练。

1）服务端能力及服务故障模拟阶段

服务端第一轮性能测试，涉及核心业务网关和乐高基础能力性能测试。

经过模拟正常业务、业务超时、应答错误，业务方无响应、业务数据包超大，业务数据包丢失，业务数据包不完整、接口限流等业务能力。DB不可用、链接数占满、硬盘，应用服务器硬盘沾满、应用服务器cpu太高、内存太高等系统资源问题，以及乐高或网管系统扩容和缩容测试。

经过模拟各类异常状况验证系统基础能力是否知足高峰期间业务流量。

 

基础能力测试

第一阶段性能测试难度较大，一则是由于基础能力测试和传统业务测试在思考方式上有较大差别；另外基础能力测试须要模拟各类异常状况，须要高度抽象各类业务状况，须要编写各类模拟代码，对传统测试能力要求较高。

2）基础能力业务测试和业务链路性能测试

服务端第二轮性能测试，包含两部份内容，一部分主要是对第一阶段测试基础能力（乐高、网关）系统接入真实的业务进行业务性能测试。在接入业务时测试时，网关系统接入下游业务策略是选择高峰时期top30的业务接口进行进行测试。乐高系统经过线上流量复制，按照线上调用业务模板的比例进行等比配置，覆盖全部模板实例，确保趋近于模拟线上真实业务模板实例和后台接口测试乐高系统。

在选择接入下游系统数据和接口时，选择的策略不一样，测试的结果差别较大，因此采用什么样的选择策略就显得尤其重要。

另一部分是App基础业务、高频和关键业务性能测试，这部分主要经过对单业务或者单业务链路的测试，验证该业务链路是否知足系统要求。这部分和大部分公司平常的性能测试方案和方法一致。在此再也不赘述。

另外在此阶段有一个很是重要测试演练，不断要测试集群的性能，还须要进行单机的性能，根据扩容行测试，评估和预测扩容机器。

3）测试服务端全链路预演

基于前面两个阶段对基础能力性能测试和基础业务、高频业务、基础业务、活动等业务的性能测试和评估，各业务根据618移动端链路流量预估，造成总体移动端链路压测方案。关于全链路压测网上的方案很是之多，本文不在赘述。

在第三个阶段，除了验证业务支撑能力，能不能知足预估流量；还须要重点关注高峰时段流量对App业务影响，并根据压测状况对业务实时升降级处理。若是超过预估流量或者发生意外时，那些业务能够进行降级，若是降级，会不会影响到其余业务等等。

此阶段重要的一个任务就是演练，模拟演练618洪峰流量对业务对App的影响，性能测试须要测试和评估出每一个业务升降级的临界数据，配合开发和运维同窗在测试过程当中进行故障模拟和演练。

3.总结

全链路压测和日常压测的一个很重要的区别是，全链路压测是证实容量规划的准确，流量控制策略得当。流量控制策略最核心的能够作到限流分流降级，限流分流降级提及来很容易，但须要开发、测试同窗在前期作好大量工做，业务是否作到解耦和具有升降级能力，测试同窗是否经过测试准确的验证容量规划的合理性，业务升降级的临界值是否合理得当等等。

4.感谢

整个任务完成之时，还惧怕哪块没准备好，有点担忧。但在6月1号写完此文，心里无比坚决的认为此次备战确定是成功的。写此文一则是为了总结经验，二则是为了感谢为这次备战准备了三个月身边的小伙伴。

感谢为保障此次测试任务的全部移动端测试同窗，在那么短的时间，那么少的人手，完成了几乎是日常工做量2倍的工做，大家是最棒的，感谢大家。

感谢移动端开发，帮忙一块梳理业务，每一个边边角角都帮咱们补充到。喜欢大家认真的样子。

感谢服务端的同窗，不厌其烦的配合咱们一次次调试差问题，和咱们一块儿加班，一块儿看星星，一块儿看日出，一块儿悲伤，一块儿欢乐。

固然必须再此感谢全部参与此次移动端链路功能专项测试，客户端专项性能测试，服务端的同窗。

写在后面的话：完美的遗憾

总体来讲本次移动端链路备战很是成功，但有个小小的遗憾，在618当天晚上八点活动中由于瞬间业务（5秒）访问新高，触发熔断机制，致使业务失败率较高。出现瞬间访问太高的缘由是由于活动结束后，用户瞬间返回主页面，致使主页面业务访问量太高。

建议后期在业务设计时必定要考虑业务完成的状况，尽量创建多层级的业务分流机制。避免业务完成时的瞬间访问量发生。同时也要创建自动降级的策略，防止业务瞬间访问量上升致使的降级策略失效的问题。

做者：土司阿哈连接：https://www.jianshu.com/p/2e79b546d321来源：简书