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

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

提供知识服务的罗辑思惟主张“省时间的获取知识”，那么其技术团队在技术实践方面是如何践行省时间的理念的呢？本文将还原罗辑思惟技术团队在全链路压测上的构建过程，为您一探究竟。

全链路压测知多少

保障服务的可用性和稳定性是技术团队面临的首要任务，也是技术难题之一。例如，罗辑思惟提供的是知识服务，服务的是在高铁、地铁和公交车等场所利用碎片时间进行学习，在凌晨、深夜都有可能打开App，以及分布在海外的全球用户。这就须要获得App提供7*24的稳定高性能的服务和体验。

在实际生产环境中，用户的访问行为一旦发生，从CDN到接入层、前端应用、后端服务、缓存、存储、中间件整个链路都面临着不肯定的流量，不管是公有云、专有云、混合云仍是自建IDC，全局的瓶颈识别、业务总体容量摸底和规划都须要高仿真的全链路压测来检验。这里的不肯定的流量指的是某个大促活动、常规高并发时间段以及其余规划外的场景引发的不规则、大小未知的流量。

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

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

 

业务压测实施路径

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

压测的核心要素

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

要达成精准衡量业务承接能力的目标，业务压测就须要作到同样的线上环境、同样的用户规模、同样的业务场景、同样的业务量级和同样的流量来源，让系统提早进行“模拟考”，从而达到精准衡量业务模型实际处理能力的目标，其核心要素是：压测环境、压测基础数据、压测流量（模型、数据）、流量发起、掌控和问题定位。

 

压测环境和压测基础数据

生产环境上基础数据基本分为两种方式，一种是数据库层面不须要作改造，直接基于基础表里的测试帐户（相关的数据完整性也要具有）进行，压测以后将相关的测试产生的流水数据清除（清除的方式能够固化SQL脚本或者落在系统上）；另外一种就是压测流量单独打标（如单独定义的Header），而后业务处理过程当中识别这个标并传递下去，包括异步消息和中间件，最终落到数据库的影子表或者影子库中。这种方式详见阿里的全链路压测实践，咱们也是选用了这种方式。此外，生产环境的压测尽可能在业务低峰期进行从而避免影响生产的业务。

全链路压测的构建过程

目前，罗辑思惟已经提供了获得APP、少年获得、和微信公众号获得里的获得商城等多个流量入口。

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

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

• 2017年10月

启动全链路压测项目，完成商城的首页、详情、购物车、下单的改造方案设计、落地、基础数据准备和接入，以及获得APP首页和核心功能相关的全部读接口接入，并在进行了获得APP的第一次读接口的全链路压测。

• 2017年11月

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

• 2017年12月

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

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

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

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

全链路压测的构建与其说是一个项目，不如说是一项工程。仅凭咱们本身的技术积累和人员配置是没法完成的，在此特别感谢阿里云PTS及其余技术团队提供的支持，帮助咱们将全链路压测在罗辑思惟进行落地。下面咱们将落地过程当中积累的经验以工做笔记的方式分享给你们。

工做笔记

A. 流量模型的肯定：

流量较大的时候能够经过日志和监控快速肯定。可是每每可能平常的峰值没有那么高，可是要应对的一个活动却有很大的流量，有个方法是能够基于业务峰值的一个时间段内统计各接口的峰值，最后拼装成压测的流量模型。

B. 脏数据的问题：

不管是经过生产环境改造识别压测流量的方式仍是在生产环境使用测试账号的方式，都有可能出现产生脏数据的问题，最好的办法是：

• 在仿真环境或者性能环境多校验多测试：
  有个仿真环境很是重要，不少问题的跟进、复现和debug不须要再上生产环境，下降风险。

• 有多重机制保障：
  好比对了压测流量单独打标还须要UID有较强的区分度，关键数据及时作好备份等等。

C. 监控：

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

D. 压测的扩展：

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

E. 网络接入：

若是网络接入的节点较多，能够分别作一些DIS再压测，逐个肯定能力和排除问题，而后总体enable以后再一块儿压测肯定总体的设置和搭配上是否有能力对不齐的状况。

好比，网络上使用了CDN动态加速、WAF、高防、SLB等等，若是总体压测效果不理想的时候建议屏蔽掉一些环节进行压测，收敛问题，常见的好比WAF和SLB之间的会话保持可能带来负载不匀的问题。固然这些产品自己的容量和规格也是须要压测和验证的，如SLB的CPS、QPS、带宽、链接数都有可能成为瓶颈，经过在PTS的压测场景中集成相关SLB监控能够方便地一站式查看，结合压测也能够更好的选择成本最低的使用方式。

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

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

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

F. 参数调优：

压测以后确定会发现大量的参数设置不合理，咱们的调优主要涉及到了这些：内核网络参数调整（好比快速回收链接）、Nginx的常见参数调优、PHP-FPM的参数调整等等，这些网上相关的资料很是多。

G. 缓存和数据库：

• 重要业务是否有缓存；
• Redis CPU太高能够重点看下是否有模糊匹配、短链接的不合理使用、高时间复杂度的指令的使用、实时或准实时持久化操做等等。同时，能够考虑升级Redis到集群版，另外对于热点数据考虑Local Cache的优化机制（活动形态因为K-V不多，适合考虑Local Cache）；
• 重要数据库随着压测的进行和问题的发现，可能会有索引不全的状况；

H. Mock服务：

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

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

咱们的经验是CPU的建议阈值在50到70%之间，主要是考虑到容器的环境的因素。而后因为是互联网性质的业务，因此响应时间也是将1秒做为上限，同时压测的时候也会进行同步的手工体感的实际测试检查体验。（详细的指标的解读和阈值能够点击阅读原文）

J. 其余

• 限流即便生效了，也须要在主要客户端版本上的check是否限流以后的提示和体验是否符合预期，这个很重要；
• 全链路压测主要覆盖核心的各类接口，除此之外的接口也要有必定的保护机制，好比有默认的限流阈值，确保不会出现非核心接口因为预期外流量或者评估不足的流量致使核心系统容量不足（若是是Java技术栈能够了解下开源的Sentinel或者阿里云上免费的限流工具 AHAS）
• 核心的应用在物理机层面要分开部署；

省时间的技术理念

目前，全链路压测已成为罗辑思惟的核心技术设施之一，大幅提高了业务的稳定性。借助阿里云PTS，全链路压测的自动化程度得以进一步提升，加速了构建进程、下降了人力投入。咱们很是关注技术团队的效率和专一度，不只是全链路压测体系的构建，还包括其余不少业务层面的系统建设，咱们都借助了合做伙伴的技术力量，在可控时间内支撑起业务的快速发展。

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

 

 

原文连接 更多技术干货 请关注阿里云云栖社区微信号 ：yunqiinsight