罗辑思维在全链路压测方面的实践和工作笔记

业务的知名度越高，其背后技术团队承受的压力就越大。一旦出现技术问题，就有可能被放大，尤其是当服务的是对知识获取体验要求颇高的用户群体。

众所周知，应用的服务状态除了会受到自身稳定性的影响，还会受到流量等环境因素的影响，并且影响面会继续传递到上下游，哪怕一个环节出现一点误差，误差在上下游经过几层累积后会造成什么影响谁都无法确定。

因此，在生产环境里建立起一套验证机制，来验证各个生产环节都是能经受住各类流量的访问，成为保障服务的可用性和稳定性的重中之重。最佳的验证方法就是让事件提前发生，即让真实的流量来访问生产环境，实现全方位的真实业务场景模拟，确保各个环节的性能、容量和稳定性均做到万无一失，这就是全链路压测的诞生背景，也是将性能测试进行全方位的升级，使其具备“预见能力”。

业务压测实施路径

可见，全链路压测做得好，遇到真实环境的流量，系统仅仅只是再经历一次已经被反复验证过的场景，再考一遍做“做过的考题”，不出问题在意料之中将成为可能。

实施完整的业务压测，路径很重要。

压测环境和压测基础数据

每一年，罗辑思维都会举办跨年演讲，第一年是在优酷，有200多万人的在线观看，第二年是在深圳卫视合作直播，并在优酷等视频网站同步，直播过程中当二维码放出来的时候，我们就遇到了大量的用户请求，在同一时刻。这就意味着，如果没有对这个期间的流量做好准确的预估，评估好性能瓶颈，那么在直播过程中就有可能出现大面积服务中断。

对整体系统进行全链路压测，从而有效保障每个流量入口的服务稳定性成为技术团队的当务之急。因此，我们在2017年，计划引入全链路压测。期间，也对系统做了服务化改造，对于服务化改造的内容之前在媒体上传播过，这次我们主要是讲下保障服务稳定性的核心-全链路压测。大致的构建过程如下：

商城核心业务和活动形态相对稳定，进入全面的压测&攻坚提升期，同时拉新、下单和支付改造开始，得到APP开始进入写改造，活动形态初具雏形，读写覆盖范围已经覆盖首页、听书、订阅、已购、拉新、知识账本，并启动用户中心侧用户部分的底层改造，包括短信等三方的业务挡板开发。

商城进行最后的支付改造补齐，然后是全链路压测&优化的整体迭代；得到APP全链路压测接入范围继续增加，覆盖全部首页范围和下侧5个tab，同时开始部分模块组合压测和性能调优的迭代；完成底层支付和用户中心配合改造，以及支付和短信所有外部调用的挡板改造；行了多轮次的全链路形态完整压测，并从中发现发现，给予问题定位，提升体系稳定性；梳理对焦了风险识别、预案和值班等等。

经过3个多月的集中实施，我们将全链路压测接入链路174个，创建44个场景，压测消耗VUM1.2亿，发现各类问题200多个。

如果说2017年全链路压测的设施在罗辑是从0到1，那么2018年就是从1到N了。

从2018年开始，全链路压测进入比较成熟的阶段，我们的测试团队基于PTS和之前的经验，迅速地将全链路压测应用于日常活动和跨年活动中，并应用于新推出的业务「少年得到」上。目前，全链路压测已经成为保障业务稳定性的核心基础设施之一。

A.流量模型的确定：

B.脏数据的问题：

无论是通过生产环境改造识别压测流量的方式还是在生产环境使用测试帐号的方式，都有可能出现产生脏数据的问题，最好的办法是：

C.监控：

由于是全链路压测，目的就是全面的识别和发现问题，所以要求监控的覆盖度很高。从网络接入到数据库，从网络4层到7层和业务的，随着压测的深入，你会发现监控总是不够用。

D.压测的扩展：

比如我们会用压测进行一些技术选型的比对，这个时候要确保是同样的流量模型和量级，可以通过全链路压测测试自动扩容或者是预案性质的手工扩容的速度和稳定性。在全链路压测的后期，也要进行重要的比如限流能力的检验和各种故障影响的实际检验和预案的演练。

E.网络接入：

如果网络接入的节点较多，可以分别做一些DIS再压测，逐个确定能力和排除问题，然后整体enable之后再一起压测确定整体的设置和搭配上是否有能力对不齐的情况。

另外负载不匀除了前面说的网络接入这块的，内部做硬负载的Nginx的负载也有可能出现不匀的现象，特别是在高并发流量下有可能出现，这也是全链路、高仿真压测的价值。

特别是一些重要活动的压测，建议要做一下业务中会真实出现的流量脉冲的情况。

阿里云PTS是具备这个能力的，可以在逐级递增满足容量的背景下再观察下峰值脉冲的系统表现，比如验证限流能力，以及看看峰值脉冲会不会被识别为DDOS。

F.参数调优：

G.缓存和数据库：

H.Mock服务：

一般在短信下发、支付环节上会依赖第三方，压测涉及到这里的时候一般需要做一些特殊处理，比如搭建单独的Mock服务，然后将压测流量路由过来。这个Mock服务涉及了第三方服务的模拟，所以需要尽量真实，比如模拟的延迟要接近真正的三方服务。当然这个Mock服务很可能会出现瓶颈，要确保其容量和高并发下的接口延时的稳定性，毕竟一些第三方支付和短信接口的容量、限流和稳定性都是比较好的。

I.压测时系统的CPU阈值和业务SLA

J.其他

当业务跑的快的时候，技术建设的路径和方式，是团队的基础调性决定的。