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

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秒）访问新高，触发熔断机制，导致业务失败率较高。出现瞬间访问过高的原因是因为活动结束后，用户瞬间返回主页面，导致主页面业务访问量过高。

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