测试技术（3）：全链路压测
昨天晚上无意中和朋友聊到全链路压测，发现全链路压测这个术语虽然“耳熟能详”，但具体的一些细节要讲通透（其实能讲明白就不错了），还是欠“火候”，所以抽空查了查资料，补习了下全链路压测的知识。
以下内容，且当是一次学习笔记。
相关链接：
PerfMa童庭坚：全链路压测体系建设方案的思考与实践
阿里巴巴的全链路压测
全链路压测经验谈
滴滴全链路压测解决之道
饿了么全链路压测的探索与实践
全链路压测平台（Quake）在美团中的实践
一、全链路压测的起源
在全链路压测体系建设方案的思考与实践中，PerfMa的童庭坚谈到：“随着压测技术和手段的不断演进，在2014年初，全链路压测的方法开始诞生，其目标是希望在大型促销活动来临前，可以在生产环境上模拟路演进行验证整体容量和稳定性。”
在阿里巴巴的全链路压测中，提到全链路压测的另外一个起点，“双十一从 2009 诞生到现在，2013 年绝对是一个分水岭。为什么这么说？因为 2013 有了全链路压测。”
到底哪个是正确的呢？
时间起点可能不是最重要的，最重要的是为什么会出现全链路压测这种方法，它是怎么来（出现）的，它解决了什么问题。
任何新事物的出现，都不是一蹴而就的，全链路压测的出现也符合这个规律。
根据相关资料的描述，性能测试的发展大体上是经历了三个阶段：由线下在测试环境的短链路测试（模拟测试），到线上生产环境的引流测试（半仿真测试），再到生成环境的线上全链路测试（全仿真测试）。
为什么需要生成环境的线上全链路测试呢？
因为线下的模拟测试和线上的半仿真测试均不能解决（或发现）线上真正峰值业务时可能出现的性能问题。
自从 2009 阿里诞生双11之后，每年的 11 月 11 日 凌晨零点零分零秒，阿里巴巴的系统都会在极短时间内出现海啸般涌入的超大规模流量。根据阿里巴巴的全链路压测的描述，“流量洪峰的杀伤力，曾在 2011 年和 2012 年给技术团队留下了午夜惊魂的难忘回忆。”为了应对高峰时的性能瓶颈问题，他们采取了单机压测、容量规划等方案，他们以为已经清楚的知道了什么时候应该加机器、什么时候应该减机器，双 11 等大促场景需要准备多少机器，既能保障系统稳定性、又能节约成本。但现实总是很残酷，真实场景并非模拟时的样子。当双 11 的零点到来的时候，真实的业务场景下，网关、前端、缓存、中间件、后端、数据库，整个交易链路和链路上的每个系统都会面临巨大的访问压力，而且系统之间是有相互依赖关系的，这个时候系统服务除了受自身的影响，还依赖于其他关联系统的情况，单点的影响会沿着链路蔓延，最后可能就会形成“雪崩”。
引用阿里巴巴的全链路压测中的一张图，如下
怎么样才能解决这个问题？
验证的最好办法就是让事件提前发生，通过全链路压测，全仿真测试就可以提早发现问题。
阿里的技术同学描述了这样一个故事：在 2013 年的双 11 备战过程当中，在很长一段时间内这都是他们面临的一个难题。在中国，学生通常都会有期末考试，为了在期末考试中取得比较好的成绩，老师通常会让学生们在考试前先做几套模拟题。双 11 对他们的系统来说就是一年一度的期末考试，所以他们冒出了这么一个想法：“如果能让双 11 提前发生，让系统提前经历双 11 的模拟考验，这个问题就解决了”。通过对双 11 零点的用户行为进行一次高仿真的模拟，验证整个站点的容量、性能和瓶颈点。为此阿里还研发了一套新的 “全链路压测” 平台。
由此可以明白，“全链路压测”的概念应该是始于2013年前后，起源于阿里的双 11的线上高仿真模拟测试。
基于以上信息，可以给全链路压测下个定义：“基于实际的生产业务场景、系统环境，模拟海量的用户请求和数据对整个业务链进行压力测试，并持续调优的过程”。（引自博客园的聊聊全链路压测）
在滴滴全链路压测解决之道中，提及滴滴的全链路压测，就是“在线上环境，针对全业务核心链路，以数据隔离的方式进行压测”。
在全链路压测平台（Quake）在美团中的实践中，对全链路压测的定义是“全链路压测是基于线上真实环境和实际业务场景，通过模拟海量的用户请求，来对整个系统进行压力测试” 。
由此可见，全链路压测都是基于生产环境，压测在线上环境进行，业务场景是生产环境上的场景（或者说系统功能），测试时生产环境上的正常业务不停止，只是使用的数据不是真实数据，而是模拟的高仿测试数据。
线上最大的优点就是环境真实，不需要担心配置不一致、结果是否可以同比例放大等问题，压测的结果自然也更为精确。
全链路压测解决了什么问题？
PerfMa的童庭坚说“可以在生产环境上模拟路演进行验证整体容量和稳定性”。我认为一语中的，归纳总结的很到位。
二、全链路压测面临的问题
全链路压测既然是在生产环境上测试，那么必将面临诸如这样一些迥异与在测试环境测试的问题：
1、如何不影响生产环境正常的业务？测试不能对生产造成影响，更不能搞垮线上系统。
2、全链路压测的测试数据如何构造、如何使用、如何管理？要避免在生产环境造成测试的脏数据。
3、全链路压测的测试活动如何不影响数据分析人员对正常业务的统计分析？
4、如何监控？压测期间，在系统出现单点故障前，要能够提前预警，万一真的出现故障，必须紧急停止压测，最短时间内进行恢复。
三、全链路压测的技术创新
如童庭坚在全链路压测体系建设方案的思考与实践中总结的，全链路压测创新的技术有“公网多地域流量模拟、全链路流量染色、全链路数据隔离、全链路日志隔离、全链路风险熔断等关键技术”。
n 公网多地域流量模拟技术是指通过全国各地CDN节点模拟向生产系统施加压力，并在压测过程中对生产系统健康度进行实时监控，快速识别压测对生产业务带来的风险，立即作出流量调节或熔断决策。
n 全链路流量染色，通过压测平台对输出的压力请求测试数据打上标识，在下游应用系统中提取压测标识，确保完整的程序上下文都持有该标识。
n 全链路数据隔离，当系统访问数据库时，在持久化层同样会根据压测标识进行路由访问压测数据表。数据隔离的手段有多种，比如影子库、影子表，或者影子数据。
n 全链路日志隔离，当系统向磁盘或外设输出日志时，若流量是被标记的压测流量，则将日志隔离输出，避免影响生产日志。
n 全链路风险熔断，当系统访问其他系统时，通过RPC协议延续压测标识到其他系统，两个系统之间服务通讯将会有白黑名单开关来控制流量流入许可。该方案设计可以一定程度上避免下游系统出现瓶颈或不支持压测所带来的风险。
四、全链路压测可以替代线下的压测吗？
引用童庭坚的话，“线下压测是无风险发现程序级问题，线上压测是低风险实现线下补足和评估生产的容量”。如果没有线下的压测，很多程序变更所引起的一些基本的程序级问题就不会得到验证，最终累积起来，可能就会导致生产压测过程中频繁出现故障。
全链路压测的目的包括：
Ø 测试环境差异补充
Ø 业务高峰提前预演
Ø 生产容量持续验证
Ø 生产变更影响演练
线下压测的目的包括：
Ø 迭代性能验证
Ø 低成本性能调优
Ø 多版本性能差异对比
Ø 高风险的可靠性演练
对于生产全链路压测的应用，童庭坚提醒说，“不能有了生产全链路压测就不做线下压测”、“不是有了生产影子表能力，就可以在生产随意实施压测。比如日志也需要隔离，如果生产日志和测试日志混为一体，将会影响大数据分析（如用户行为分析）。同时生产压测本身是高风险的行为，所以压测前中后的生产稳定性风险防控能力也至关重要。”
因此，全链路压测并不能替代线下的压测，正如UAT不能代替SIT、IT、UT一样。
2020-12-2