共计 6853 个字符，预计需要花费 18 分钟才能阅读完成。
简介：在阿里淘宝双 11 的过程中，长期以来都是在生产环节做全链路压测的，通过实际咱们发现在生产环境中做压测，实际上会和一个 IT 组织的构造、成熟度、流程等严密相干，所以咱们把全链路压测从简略的制作范畴内脱离进去，变成整个业务连续性的计划。
在阿里淘宝双 11 的过程中，长期以来都是在生产环节做全链路压测的，通过实际咱们发现在生产环境中做压测，实际上会和一个 IT 组织的构造、成熟度、流程等严密相干，所以咱们把全链路压测从简略的制作范畴内脱离进去，变成整个业务连续性的计划。
本文分四个方面为大家论述：第一，整个全链路压测的意义，为什么要在生产环节上做全链路压测；第二，对于落地的技术点和解决方案；第三，生产过程中做全链路压测流程上的倡议，思考到每个组织的承受度不一样，给大家提供一些倡议；第四，如何在第三方实现整个在生产环境中做业务连续性包含压测的后果。
全链路压测的意义
上图显示了三个问题，实际上是不同的 IT 组织在和测试交换的时候，这三个问题是比拟有代表性的。
- 很多测试同行说他们线下也做过性能测试，然而到了线上之后还是存在很多问题，因为不太可能会在线下模仿一个跟线上 1：1 的环境。在有很多第三方接口的状况下，大家也很少会去模仿线上整个场景。因而咱们在线下做了很多测试工作后，总结出了为什么很多从线下容量推导到线上容量的公司却最终成果不是很好，就是这样的起因。
- 当初所有的 IT 组织都在搞 DevOps，咱们的性能从一个月迭代一次到当初一周迭代一次，留给测试的工夫越来越短。功能测试工夫从之前的一周、两周缩短到当初三四天、两三天的工夫，那性能测试就没有方法按时上线，很有可能会呈现各种各样的性能问题，这会间接影响到企业的品牌影响力。
- 平时线上水位比拟低，很少达到高峰期，然而会呈现一些突发状况。比方像去年的疫情使得很多公司的业务变成在线业务。比方教育行业，之前是课堂上老师面对面的教育，当初抉择线上在线平台来做，这类突发的状况会使测试工程师，包含开发运维团队受到很大的困扰。在这之前我先介绍一个概念，这个概念是由《黑天鹅》的原作者 Nassim Nicholas Taleb 提出，概念核心是 软弱与反软弱。
什么是软弱？软弱就像玻璃，大家晓得玻璃很脆易碎。软弱的反义词是什么？不是强韧也不是坚韧，可能是反软弱。什么是反软弱呢？比方乒乓球，大家晓得乒乓球在地上不必很大的力就能够毁坏掉，踩一脚就毁坏掉了，然而高速静止的状况下，乒乓球咱们施加的力度越大，它的反弹力度越大，阐明乒乓球在静止过程中有反软弱的个性。
咱们的 IT 零碎实际上也是这样的。不论什么代码都不能保障是齐全没有问题的，咱们的基础设施可能也是软弱的，像服务器、数据库等总会有局限。咱们的框架也总是软弱的，将这些问题综合在一起，咱们心愿通过某些伎俩，比方通过预案、危险的辨认，或者通过一些熔断的伎俩，最终把这些货色组合在一起，让整个 IT 零碎有反软弱的个性。总之，咱们心愿通过一些伎俩使得 IT 零碎有足够的冗余，而且有足够多的预案应答突发的不确定性危险。
如何打造 IT 零碎反软弱能力呢？咱们心愿通过一些伎俩，比如说像线上的压测能力，提供不确定的因素，接着通过在这个过程中实时监控，包含预案的能力，最终把这些不确定性的因素辨认进去，并且在线上生产压测过程中对它做一些解决，更多可能会通过预先复盘等形式，做到对不确定性因素的辨认。接着咱们可能会在生产环境中通过之前的伎俩，在生产环境上做一个稳定性的常态化压测，实现长期稳固的场景，最终咱们可能达到反软弱能力所须要的整体监控的能力、经营防护能力，以及管控路由能力，这会让整个 IT 零碎具备反软弱的个性。
全链路压测解决方案
如何在生产环境上做全链路压测？它须要用到哪些技术手段？
压测过程演变
个别状况下，测试是怎么样从线下一点点往线上演变的？我把它分为四个阶段：
- 目前绝大多数 IT 能够做到的是线下单零碎压测，即针对单个接口或者单个场景做压测，同时也会做系统分析和性能剖析。但在简单的业务场景之下，咱们可能没方法去充沛发现问题，很多都是由开发或者测试同学自发进行的流动。
- 咱们成立了一个相似于测试实验室或者测试组织的机构，这样一个大的部门可能会结构出一批相似于生产环境的性能测试环境，在这下面咱们可能会做更多的事件，比如说做一个线下环境的全链路压测，并且咱们能够依据之前积攒的教训在下面做一些线下的回归，包含性能的诊断等。其实这一步相当于整个测试往前再走一步，对测试环境中的链路做一些剖析，在下面演变一些能力，比如说危险的管制等等。
- 目前绝大部分 IT 企业和互联网企业违心尝试线上生产环境的业务压测。这部分实际上和之前的第二阶段相差不多，然而在这个过程中人为的把它分为了两层：第一层是单纯的做全链路压测，很多 IT 公司曾经在非生产环节中做了只读业务的压测，因为这样不会对数据造成净化。而再往下一层，有些组织可能会在失常生产时段中做进一步的全链路压测，这种状况下咱们就会要求这个组织领有更高的能力。
比如说咱们须要对整个压测流量做一些染色，可能辨别进去失常的业务数据，失常的流量和非正常的压测流量，可能有的会做一些环境的隔离，而在业务生产期间内咱们做生产的压测，须要思考到整个流量的偏移、限流，包含熔断机制等。不管怎样做业务，可能都会对最终的生产业务造成肯定的影响，真正呈现问题的时候可能须要有疾速的熔断机制。
- 做到压缩熔断渲染，包含对熔断的机制——有了这样的能力之后，最初一个阶段就是整个生产链路的全链路压测，包含读写，它就具备了根本能力。这个方面咱们其实更多的是通过引入库表，加上技术手段，在这个生产上做全链路压测，包含读业务、写业务等，同时咱们有系统故障演练和生产变更演练的能力，在这种状况下咱们可能最终具备了数据隔离能力、监控隔离能力和日志隔离能力。
全链路压测关键技术
对于整个全链路压测来说，咱们须要几个要害的技术：
- 全链路流量染色
可能通过在压缩机上做一些标识，比方加一个后缀，或者通过一些标识伎俩把流量读出来，扩散到相干的表里去。同时在全链路流量展现过程中咱们还须要做流量的辨认，对于压测流量通过的每一个中间件，每一个服务咱们都心愿可能精确的辨认进去，这个流量是来自于压测机还是来自于失常流量，这是第一步。
- 全链路的数据隔离
咱们须要通过哪些伎俩，比方通过影子库，通过运维的同学做一个和生产下面同样的影子库，而后切到影子库上，或者在生产库上做一个雷同的影子表，来做数据隔离。第一种形式平安度高一些，然而毛病在于咱们用影子库的时候整个生产环境是不可用的。生产影子库不能齐全模拟出整个线上的状况，因为影子表须要咱们有更高的技术水平，可能保障整个链路可追踪，包含整个数据如果一旦出错数据恢复能力等等。
- 全链路危险管控机制
也就是危险熔断机制，一旦真的发现生产环境的线上压测对咱们的业务造成了影响，咱们须要通过一些规定或者其余的指标来主动触发危险熔断，包含管控等等这样的伎俩，不论是提供施压机的流量，还是把生产零碎损坏的局部做业务隔离，这样的伎俩都是咱们做生产过程中全链路压测的必要伎俩。
- 全链路日志日志隔离
其实日志自身不会对全链路造成太大的影响，然而因为做数字化程度的晋升，日志基本上是 BI 同学包含经营的同学对整个业务剖析最重要的数据起源，如果咱们不做日志隔离很有可能会对 BI 决策造成肯定的影响，比方压测过程中咱们会大量采纳某个地区的流量对生产环境做拜访，BI 的同学可能会通过日志剖析发现某一个地区做大，导致他谬误的经营决策，所以说对于生产过程中的全链路压测来说，咱们须要在整个生产过程中做肯定的日志隔离，辨别进去失常的生产流量和压测流量之间的存储。
全链路压测和业务连续性平台外围性能
这部分是真正想作为全链路压测和业务连续性平台所须要的性能。
- 首先是有来自于全地区的压测流量工具，这个流量工具具备的性能包含全地区流量开掘、流量革新相干的性能。
- 整个压测辨认，包含影子存储一部分的性能。黄色的局部是失常流量，蓝色的局部是压测的流量，咱们可能通过施压机的革新让蓝色的局部退出一些标识，通过 Agent 的技术，它能够标识出带有的流量，通过底层的 Agent 技术将这些落到相应的影子库或者影子表里去，或者是缓存的影子区里。
- 做熔断的规定治理，所以须要有正当的控制台，这里可能会做一些装置探针治理，包含整个架构的治理、库表的保护、规定的保护、熔断机制的保护等。
- 最初是真正的施压局部。这里可能会装置一些探针或者是 Agent，这些 Agent 的作用是可能让这些流量落到相应的影子表里去，还有是通过相应的监控指标，比如说咱们的谬误达到 1%，或者是查看工夫超过了肯定的阈值之后，Agent 会及时上报，通过规定配置起到限流的作用。
通过这套架构，咱们当初能够做到目前比依照整体环境大概节省成本是 40% 左右，基本上对整个生产业务没有任何切入。
全链路压测危险防控能力
上面来具体谈一谈如何做一个影子数据库，包含整个流量辨认。
橙色的局部是真正的压测流量，这部分咱们会在施压机上做一个标识，当初是会加一个后缀。另外还会在服务器做 filter，它其实是拦截器，咱们会拦挡到流量外面相干的标识，而后把它做辨别、做染色，并且做跟踪，每一个申请基本上能够真正做到在任何中间件以及我的项目堆里都是通明可见的。
真正在压测过程中通过 Agent 字节码完结将它间接改写，将字节的条件替换成压缩的条件。当然要先把影子库建好，通过底层的追踪咱们能够把相应的流量，如果数据库就会走得比拟明确，之后咱们会做流量的测试，看看是否比拟明确，而且咱们能够做到整个测试数据带有标识，一旦真的没有走到诊断外面去，咱们也能够在失常的表里做删除，并且每一个通过的区域对咱们来说都是可见的。
通过这样的形式，目前绝大部分 IT 组织是分三个阶段，当然有一些十分成熟的是分为两个阶段：
- 在上线之前发现问题，大多是由线下的开发或者测试调试过程中发现问题，而后做到整个接口的优化，确保最初没有代码的问题，包含 DNS 问题。这类问题基本上是在线下的环境，开发的环境解决掉。
- 在部署过程中，咱们会做第三方插件比方平安等等问题，然而目前随着容器的倒退，开发部署环境会被逐步淡化掉。
- 在线上真正做生产环境的压测，这部分可能会做容量布局或者是压测，其余像整个大环境，比如说 CDN 或者 DNS 问题，或者是整个线上零碎容量评估等等问题。
这些是咱们目前在整个测试生命周期里心愿在各个阶段实现的目标。
压测流程的倡议
思考到各个组织的成熟度不一样，咱们提供的这些倡议不肯定实用于所有的 IT 组织，但大家能够依据本身状况参考一下。
咱们个别为第三方施行全链路压测，线上生产压测，会经验五个阶段：
首先是和第三方一起梳理业务的阶段，咱们会做以下几件事件：
1. 依据过往零碎应用状况评估业务零碎的性能指标、容量指标；
2. 对现有信息系统做零碎架构的梳理，确定整个被染色流量的门路路径；
3. 对压测时长，包含距离等做沟通，确认相干的压测场景设计；
4. 生产数据脱敏，如果有一部分波及到生产数据可能会做生产数据的脱敏等相干工作。
这部分做完是做第二局部，对某些利用进行革新。比如说做流量打标工作，通过监控的流量确定业务零碎，可能在业务零碎里会做相干监控的接入，相干的第三方组件会进行 Mock，整个压测场景的创立会和第三方沟通好。包含流量表建设和预案等等接入。
三是整个压测的过程，整个生产状态下的全链路压测，会对整个零碎进行性能优化及容量评估。
四是将线上全链路压测常态化，这外面会有一些事件，比如说限流、降级、混沌工程验收，包含生产公布的事件。
五是对于整个流动做复盘，看应急预案是否失效，还有哪些地方须要优化，这是生产环节全链路压测的生命周期。
咱们当初做一些更深刻的货色，整个开发过程中，目前大家都应用 DevOps，可能单接口的性能测试在过程中就曾经用到了，目前咱们给企业打造的都蕴含了接口级别的单机性能测试，应用单机测试工具，在公布过程中开始验收单接口的性能问题，保障这个接口发到线上不会有代码级别谬误，最终会省掉集成压测包含测试环境中压测的步骤，间接走到线上压测这个过程。单接口阶段咱们会反对相应支流的框架压测，目前咱们也在一直做测试环境集群的压测反对，还是心愿间接用户跳过这个步骤开始在线上间接做流量隔离的压测。
上图是咱们认为一个残缺的业务连续性平台须要的性能。
1. 压测流量发动的控制台，流量发动端，这块实际上是治理整个压测流量和场景设计；
2. 流量隔离控制台，这部分心愿可能做到对立切流，当呈现问题的时候能够一下把压测流量切掉，对立路由；
3. 压测过程中有整个流量监控包含系统监控；压测过程中对于整个利用的性能监控平台，包含链路监控、JVM 监控、组件监控等等；
4. 真正的混沌工程，包含流控规定、隔离规定、降级规定等等平台，这里会保护相应的规定。
最终咱们心愿这个平台可能达到的目标是：随时随地以低成本实现全链路压测；对于运维平台能够进行周期性的故障演练，并把这种能力给运维团队，让他们随时随地发动变更；为整个上线流动包含大促做一些兜底，能够防止突发流动击穿。因为长期固化生产压测会为咱们带来容量和水位的极限，在演练过程中进行预案的施行，突发过程中会有更好的伎俩去防止，去做防护。
以阿里为例，当初基本上能够做到以按月为主，因为大家晓得淘宝每个月都有流动，每年有三个大流动：6.18、双 11、双 12。咱们目前能够做小的演练，以周为施行单位做 双 11、双 12 或者 6.18 的大促，而且咱们能够很清晰的组织 BU 内或者跨 BU 的压测流动，并可能很明确扩容计划。
客户案例
上面是咱们给第三方的施行案例。
案例一
“四通一达”的案例接入，咱们对他们的零碎进行了利用的合成，最开始确认的压缩场景大略有 4 个，起初通过流量渲染、流量染色、流量跟踪发现整个染色大略有 23 个，通过线上建设影子表的形式，建完影子表之后通过小规模的流量染色，顺着把整个影子库、影子表的计划接入生产环境，并且在生产压测过程中没有造成任何影响，并且通过咱们压测的 23 个场景，在去年的 双 11 里没有呈现任何问题，包含爆仓或者是超单的景象呈现。
他们前年做这个事的时候，大略有 50 多集体破费了四个月工夫，他们保护了一套独自环境，这个环境还是有肯定的差异，上线之后还是呈现了订单积压的景象，通过咱们做全链路压测了之后，当初基本上一个月工夫用了 5 个外围骨干做了全链路压测，基本上曾经具备了随时上线利用，本人复制，做流量利用、流量染色，测试的周期也是以天为单位，一个比拟小的迭代上线基本上一天到两天就能够实现整个线上的性能回归。对于大的流量，双 11、双 12 大促流动基本上一周工夫就能够实现整个主链路的性能回归，并且齐全能够评估出目前生产环境的容量，包含扩容、生产环境变更等等这样的性能。
案例二
某美妆行业客户，所有的零碎基本上是由第三方开发的，没有做过性能评估，根本什么都不晓得，最要害的问题在于更换的几次第三方导致整个利用比较复杂，呈现的问题是下线一个性能导致整个零碎解体不能用。咱们评估了一下，每一单成交之后硬件老本大略是 0.18 元，正好我在 2012 年就在淘宝做压测，他们这个指标大略是 2014 年淘宝破费的 9-10 倍，最要害的问题在于他们还有很多未知的危险，比如说他们上线了一个新利用，想做一个推广，后果间接出了故障，导致秒杀零碎解体了，基本上那个推广流动没有起到任何成果。
咱们大略用一个多月的工夫帮他们做线上环境，给他们梳理了 22 个外围链路，22 个零碎，大略 600 多台服务器，咱们破费的工夫，第一个生产链路建设的工夫比拟长，大略花了半个月左右的工夫，后续是他们本人施行的，总共 22 条链路花了 55 天工夫，把整个操作系统线上的容量全副厘清，在整个过程中咱们没有对生产环节的数据做净化，包含整个日志做了日志的隔离。在整个过程中咱们本着共建的态度，帮忙客户建设了日常线上压测的回归机制。
从短期收益来看，可能咱们对利用的服务器数量做了一些调整，把有些服务器从收益比拟低的链路调整到收益比拟高的链路上，最终把他们整个资源的消耗率降到了 20% 左右，并且咱们做了全链路压测之后，给他们做了一个基线，他们每次以这个基线为根底做性能的迭代。
目前他们曾经齐全把握了整个生产环境压测的流程，每次上线基本上都能够依照本人的布局来做。他们往年的指标是要把整个服务器的资源升高 至多 50% 左右，当初也正在为此而致力。
解决方案征询技术交换群：搜寻钉钉群号 31704055 退出钉钉群，可获取云原生具体解决方案材料与专家答疑。
版权申明：本文内容由阿里云实名注册用户自发奉献，版权归原作者所有，阿里云开发者社区不领有其著作权，亦不承当相应法律责任。具体规定请查看《阿里云开发者社区用户服务协定》和《阿里云开发者社区知识产权爱护指引》。如果您发现本社区中有涉嫌剽窃的内容，填写侵权投诉表单进行举报，一经查实，本社区将立即删除涉嫌侵权内容。