全链路压测体系建设方案的思考与实践

简介：在阿里淘宝双11 的过程当中，长期以来都是在生产环节作全链路压测的，经过实践咱们发如今生产环境中作压测，实际上会和一个 IT 组织的结构、成熟度、流程等紧密相关，因此咱们把全链路压测从简单的制做范围内脱离出来，变成整个业务连续性的方案。

​

在阿里淘宝双11 的过程当中，长期以来都是在生产环节作全链路压测的，经过实践咱们发如今生产环境中作压测，实际上会和一个 IT 组织的结构、成熟度、流程等紧密相关，因此咱们把全链路压测从简单的制做范围内脱离出来，变成整个业务连续性的方案。
​
本文分四个方面为你们阐述：第一，整个全链路压测的意义，为何要在生产环节上作全链路压测；第二，关于落地的技术点和解决方案；第三，生产过程当中作全链路压测流程上的建议，考虑到每一个组织的承受度不同，给你们提供一些建议；第四，如何在第三方实现整个在生产环境中作业务连续性包括压测的结果。
​

全链路压测的意义

​

上图显示了三个问题，其实是不一样的 IT 组织在和测试交流的时候，这三个问题是比较有表明性的。
​

1. 不少测试同行说他们线下也作过性能测试，可是到了线上以后仍是存在不少问题，由于不太可能会在线下模拟一个跟线上 1：1 的环境。在有不少第三方接口的状况下，你们也不多会去模拟线上整个场景。所以咱们在线下作了不少测试工做后，总结出了为何不少从线下容量推导到线上容量的公司却最终效果不是很好，就是这样的缘由。

​

1. 如今全部的 IT 组织都在搞 DevOps，咱们的功能从一个月迭代一次到如今一周迭代一次，留给测试的时间愈来愈短。功能测试时间从以前的一周、两周缩短到如今三四天、两三天的时间，那性能测试就没有办法按时上线，颇有可能会出现各类各样的性能问题，这会直接影响到企业的品牌影响力。

​

1. 平时线上水位比较低，不多达到高峰期，可是会出现一些突发状况。好比像去年的疫情使得不少公司的业务变成在线业务。好比教育行业，以前是课堂上老师面对面的教育，如今选择线上在线平台来作，这类突发的状况会使测试工程师，包括开发运维团队受到很大的困扰。在这以前我先介绍一个概念，这个概念是由《黑天鹅》的原做者 Nassim Nicholas Taleb 提出，概念中心是脆弱与反脆弱。

​

什么是脆弱？脆弱就像玻璃，你们知道玻璃很脆易碎。脆弱的反义词是什么？不是强韧也不是坚韧，多是反脆弱。什么是反脆弱呢？好比乒乓球，你们知道乒乓球在地上不用很大的力就能够破坏掉，踩一脚就破坏掉了，可是高速运动的状况下，乒乓球咱们施加的力度越大，它的反弹力度越大，说明乒乓球在运动过程当中有反脆弱的特性。
​
咱们的 IT 系统实际上也是这样的。无论什么代码都不能保证是彻底没有问题的，咱们的基础设施可能也是脆弱的，像服务器、数据库等总会有局限。咱们的框架也老是脆弱的，将这些问题综合在一块儿，咱们但愿经过某些手段，好比经过预案、风险的识别，或者经过一些熔断的手段，最终把这些东西组合在一块儿，让整个 IT 系统有反脆弱的特性。总之，咱们但愿经过一些手段使得 IT 系统有足够的冗余，并且有足够多的预案应对突发的不肯定性风险。
​

如何打造 IT 系统反脆弱能力呢？咱们但愿经过一些手段，好比说像线上的压测能力，提供不肯定的因素，接着经过在这个过程当中实时监控，包括预案的能力，最终把这些不肯定性的因素识别出来，而且在线上生产压测过程当中对它作一些处理，更多可能会经过过后复盘等方式，作到对不肯定性因素的识别。接着咱们可能会在生产环境中经过以前的手段，在生产环境上作一个稳定性的常态化压测，实现长期稳定的场景，最终咱们可能达到反脆弱能力所须要的总体监控的能力、运营防御能力，以及管控路由能力，这会让整个 IT 系统具有反脆弱的特性。
​

全链路压测解决方案

​
如何在生产环境上作全链路压测？它须要用到哪些技术手段？
​

压测进程演变

通常状况下，测试是怎么样从线下一点点往线上演变的？我把它分为四个阶段：
​

1. 目前绝大多数 IT 能够作到的是线下单系统压测，即针对单个接口或者单个场景作压测，同时也会作系统分析和性能分析。但在复杂的业务场景之下，咱们可能没办法去充分发现问题，不少都是由开发或者测试同窗自发进行的活动。

​

1. 咱们成立了一个相似于测试实验室或者测试组织的机构，这样一个大的部门可能会构造出一批相似于生产环境的性能测试环境，在这上面咱们可能会作更多的事情，好比说作一个线下环境的全链路压测，而且咱们能够根据以前积累的经验在上面作一些线下的回归，包括性能的诊断等。其实这一步至关于整个测试往前再走一步，对测试环境中的链路作一些分析，在上面演变一些能力，好比说风险的控制等等。

​

1. 目前绝大部分 IT 企业和互联网企业愿意尝试线上生产环境的业务压测。这部分实际上和以前的第二阶段相差很少，可是在这个过程当中人为的把它分为了两层：第一层是单纯的作全链路压测，不少 IT 公司已经在非生产环节中作了只读业务的压测，由于这样不会对数据形成污染。而再往下一层 ，有些组织可能会在正常生产时段中作进一步的全链路压测，这种状况下咱们就会要求这个组织拥有更高的能力。

​
好比说咱们须要对整个压测流量作一些染色，可以区分出来正常的业务数据，正常的流量和非正常的压测流量，可能有的会作一些环境的隔离，而在业务生产期间内咱们作生产的压测，须要考虑到整个流量的偏移、限流，包括熔断机制等。无论怎样作业务，可能都会对最终的生产业务形成必定的影响，真正出现问题的时候可能须要有快速的熔断机制。
​

1. 作到压缩熔断渲染，包括对熔断的机制——有了这样的能力以后，最后一个阶段就是整个生产链路的全链路压测，包括读写，它就具有了基本能力。这个方面咱们其实更多的是经过引入库表，加上技术手段，在这个生产上作全链路压测，包括读业务、写业务等，同时咱们有系统故障演练和生产变动演练的能力，在这种状况下咱们可能最终具有了数据隔离能力、监控隔离能力和日志隔离能力。

​

全链路压测关键技术

对于整个全链路压测来讲，咱们须要几个关键的技术：
​

• 全链路流量染色

可能经过在压缩机上作一些标识，好比加一个后缀，或者经过一些标识手段把流量读出来，分散到相关的表里去。同时在全链路流量展现过程当中咱们还须要作流量的识别，对于压测流量通过的每个中间件，每个服务咱们都但愿可以准确的识别出来，这个流量是来自于压测机仍是来自于正常流量，这是第一步。
​

• 全链路的数据隔离

咱们须要经过哪些手段，好比经过影子库，经过运维的同窗作一个和生产上面一样的影子库，而后切到影子库上，或者在生产库上作一个相同的影子表，来作数据隔离。第一种方式安全度高一些，可是缺点在于咱们用影子库的时候整个生产环境是不可用的。生产影子库不能彻底模拟出整个线上的状况，由于影子表须要咱们有更高的技术水平，可以保障整个链路可追踪，包括整个数据若是一旦出错数据恢复能力等等。
​

• 全链路风险管控机制

也就是风险熔断机制，一旦真的发现生产环境的线上压测对咱们的业务形成了影响，咱们须要经过一些规则或者其余的指标来自动触发风险熔断，包括管控等等这样的手段，无论是提供施压机的流量，仍是把生产系统损坏的部分作业务隔离，这样的手段都是咱们作生产过程当中全链路压测的必要手段。
​

• 全链路日志日志隔离

其实日志自己不会对全链路形成太大的影响，可是由于作数字化水平的提高，日志基本上是BI同窗包括运营的同窗对整个业务分析最重要的数据来源，若是咱们不作日志隔离颇有可能会对 BI 决策形成必定的影响，好比压测过程当中咱们会大量采用某个地域的流量对生产环境作访问，BI 的同窗可能会经过日志分析发现某一个地区作大，致使他错误的运营决策，因此说对于生产过程当中的全链路压测来讲，咱们须要在整个生产过程当中作必定的日志隔离，区分出来正常的生产流量和压测流量之间的存储。
​

全链路压测和业务连续性平台核心功能

​

这部分是真正想做为全链路压测和业务连续性平台所须要的功能。
​

1. 首先是有来自于全地域的压测流量工具，这个流量工具具有的功能包括全地域流量挖掘、流量改造相关的功能。
2. 整个压测识别，包括影子存储一部分的功能。黄色的部分是正常流量，蓝色的部分是压测的流量，咱们可能经过施压机的改造让蓝色的部分加入一些标识，经过 Agent 的技术，它能够标识出带有的流量，经过底层的 Agent 技术将这些落到相应的影子库或者影子表里去，或者是缓存的影子区里。
3. 作熔断的规则管理，因此须要有合理的控制台，这里可能会作一些安装探针管理，包括整个架构的管理、库表的维护、规则的维护、熔断机制的维护等。
4. 最后是真正的施压部分。这里可能会安装一些探针或者是 Agent，这些 Agent 的做用是可以让这些流量落到相应的影子表里去，还有是经过相应的监控指标，好比说咱们的错误达到 1%，或者是检查时间超过了必定的阈值以后，Agent 会及时上报，经过规则配置起到限流的做用。

​
经过这套架构，咱们如今能够作到目前比按照总体环境大约节省成本是 40%左右，基本上对整个生产业务没有任何切入。
​

全链路压测风险防控能力

下面来具体谈一谈如何作一个影子数据库，包括整个流量识别。
​
橙色的部分是真正的压测流量，这部分咱们会在施压机上作一个标识，如今是会加一个后缀。另外还会在服务器作 filter，它实际上是拦截器，咱们会拦截到流量里面相关的标识，而后把它作区分、作染色，而且作跟踪，每个请求基本上能够真正作到在任何中间件以及项目堆里都是透明可见的。
​
真正在压测过程当中经过 Agent 字节码结束将它直接改写，将字节的条件替换成压缩的条件。固然要先把影子库建好，经过底层的追踪咱们能够把相应的流量，若是数据库就会走得比较明确，以后咱们会作流量的测试，看看是否比较明确，并且咱们能够作到整个测试数据带有标识，一旦真的没有走到诊断里面去，咱们也能够在正常的表里作删除，而且每个通过的区域对咱们来讲都是可见的。
​
经过这样的方式，目前绝大部分 IT 组织是分三个阶段，固然有一些很是成熟的是分为两个阶段：
​

1. 在上线以前发现问题，大可能是由线下的开发或者测试调试过程当中发现问题，而后作到整个接口的优化，确保最后没有代码的问题，包括 DNS 问题。这类问题基本上是在线下的环境，开发的环境解决掉。
2. 在部署过程当中，咱们会作第三方插件好比安全等等问题，可是目前随着容器的发展，开发部署环境会被逐渐淡化掉。
3. 在线上真正作生产环境的压测，这部分可能会作容量规划或者是压测，其余像整个大环境，好比说 CDN 或者 DNS 问题，或者是整个线上系统容量评估等等问题。

​
这些是咱们目前在整个测试生命周期里但愿在各个阶段实现的目的。
​

压测流程的建议

​
考虑到各个组织的成熟度不同，咱们提供的这些建议不必定适用于全部的 IT 组织，但你们能够根据自身状况参考一下。
​
咱们通常为第三方实施全链路压测，线上生产压测，会经历五个阶段：
​
首先是和第三方一块儿梳理业务的阶段，咱们会作如下几件事情：
​
1.根据过往系统使用状况评估业务系统的性能指标、容量指标；
2.对现有信息系统作系统架构的梳理，肯定整个被染色流量的路径途径；
3.对压测时长，包括间隔等作沟通，确认相关的压测场景设计；
4.生产数据脱敏，若是有一部分涉及到生产数据可能会作生产数据的脱敏等相关工做。
​
这部分作完是作第二部分，对某些应用进行改造。好比说作流量打标工做，经过监控的流量肯定业务系统，可能在业务系统里会作相关监控的接入，相关的第三方组件会进行 Mock，整个压测场景的建立会和第三方沟通好。包括流量表建设和预案等等接入。
​
三是整个压测的过程，整个生产状态下的全链路压测，会对整个系统进行性能优化及容量评估。
​
四是将线上全链路压测常态化，这里面会有一些事情，好比说限流、降级、混沌工程验收，包括生产发布的事情。
​
五是对于整个活动作复盘，看应急预案是否生效，还有哪些地方须要优化，这是生产环节全链路压测的生命周期。
​
咱们如今作一些更深刻的东西，整个开发过程当中，目前你们都使用 DevOps，可能单接口的性能测试在过程当中就已经用到了，目前咱们给企业打造的都包含了接口级别的单机性能测试，使用单机测试工具，在发布过程当中开始验收单接口的性能问题，保证这个接口发到线上不会有代码级别错误，最终会省掉集成压测包括测试环境中压测的步骤，直接走到线上压测这个过程。单接口阶段咱们会支持相应主流的框架压测，目前咱们也在不断作测试环境集群的压测支持，仍是但愿直接用户跳过这个步骤开始在线上直接作流量隔离的压测。
​

上图是咱们认为一个完整的业务连续性平台须要的功能。
​
1.压测流量发起的控制台，流量发起端，这块其实是管理整个压测流量和场景设计；
2.流量隔离控制台，这部分但愿可以作到统一切流，当出现问题的时候能够一下把压测流量切掉，统一路由；
3.压测过程当中有整个流量监控包括系统监控；压测过程当中对于整个应用的性能监控平台，包括链路监控、JVM 监控、组件监控等等；
4.真正的混沌工程，包括流控规则、隔离规则、降级规则等等平台，这里会维护相应的规则。
​
最终咱们但愿这个平台可以达到的目的是：随时随地以低成本实现全链路压测；对于运维平台能够进行周期性的故障演练，并把这种能力给运维团队，让他们随时随地发起变动；为整个上线活动包括大促作一些兜底，能够避免突发活动击穿。由于长期固化生产压测会为咱们带来容量和水位的极限，在演练过程当中进行预案的实施，突发过程当中会有更好的手段去避免，去作防御。
​
以阿里为例，如今基本上能够作到以按月为主，由于你们知道淘宝每月都有活动，每一年有三个大活动：6.1八、双十一、双12。咱们目前能够作小的演练，以周为实施单位作 双十一、双12 或者 6.18 的大促，并且咱们能够很清晰的组织 BU 内或者跨 BU 的压测活动，并可以很明确扩容方案。
​

客户案例

​
下面是咱们给第三方的实施案例。
​

案例一

“四通一达”的案例接入，咱们对他们的系统进行了应用的分解，最开始确认的压缩场景大概有 4 个，后来经过流量渲染、流量染色、流量跟踪发现整个染色大概有 23 个，经过线上创建影子表的方式，建完影子表以后经过小规模的流量染色，顺着把整个影子库、影子表的方案接入生产环境，而且在生产压测过程当中没有形成任何影响，而且经过咱们压测的 23 个场景，在去年的 双11 里没有出现任何问题，包括爆仓或者是超单的现象出现。
​

他们前年作这个事的时候，大概有 50 多我的花费了四个月时间，他们维护了一套单独环境，这个环境仍是有必定的差异，上线以后仍是出现了订单积压的现象，经过咱们作全链路压测了以后，如今基本上一个月时间用了 5 个核心骨干作了全链路压测，基本上已经具有了随时上线应用，本身复制，作流量应用、流量染色，测试的周期也是以天为单位，一个比较小的迭代上线基本上一天到两天就能够完成整个线上的性能回归。对于大的流量，双十一、双12 大促活动基本上一周时间就能够完成整个主链路的性能回归，而且彻底能够评估出目前生产环境的容量，包括扩容、生产环境变动等等这样的功能。
​

案例二

某美妆行业客户，全部的系统基本上是由第三方开发的，没有作过性能评估，基本什么都不知道，最关键的问题在于更换的几回第三方致使整个应用比较复杂，出现的问题是下线一个功能致使整个系统崩溃不能用。咱们评估了一下，每一单成交以后硬件成本大概是 0.18 元，正好我在 2012 年就在淘宝作压测，他们这个指标大概是 2014 年淘宝花费的 9-10 倍，最关键的问题在于他们还有不少未知的风险，好比说他们上线了一个新应用，想作一个推广，结果直接出了故障，致使秒杀系统崩溃了，基本上那个推广活动没有起到任何效果。
​
咱们大概用一个多月的时间帮他们作线上环境，给他们梳理了 22 个核心链路，22 个系统，大概 600 多台服务器，咱们花费的时间，第一个生产链路建设的时间比较长，大概花了半个月左右的时间，后续是他们本身实施的，总共 22 条链路花了 55 天时间，把整个操做系统线上的容量所有厘清，在整个过程当中咱们没有对生产环节的数据作污染，包括整个日志作了日志的隔离。在整个过程当中咱们本着共建的态度，帮助客户创建了平常线上压测的回归机制。
​

从短时间收益来看，可能咱们对应用的服务器数量作了一些调整，把有些服务器从收益比较低的链路调整到收益比较高的链路上，最终把他们整个资源的消耗率降到了 20% 左右，而且咱们作了全链路压测以后，给他们作了一个基线，他们每次以这个基线为基础作性能的迭代。

目前他们已经彻底掌握了整个生产环境压测的流程，每次上线基本上均可以按照本身的规划来作。他们今年的目标是要把整个服务器的资源下降至少 50% 左右，如今也正在为此而努力。

解决方案咨询技术交流群：搜索钉钉群号 31704055 加入钉钉群，可获取云原生详细解决方案资料与专家答疑。

本文内容由阿里云实名注册用户自发贡献，版权归原做者全部，阿里云开发者社区不拥有其著做权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。若是您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将马上删除涉嫌侵权内容。