共计 2898 个字符，预计需要花费 8 分钟才能阅读完成。
随着数据化和信息化浪潮的深刻，零碎的架构在一直地演变，实现了从“单线程”到“多线程、多组件”再到“分布式、微服务”的一个逾越。目前国内外中大型企业根本都采纳的是分布式系统架构，复杂程度高。
机器是异构的，不同的机器厂商，会呈现配置不同、运算、存储性能不同、网络提早、带宽不同的状况。业务零碎是分布式的，中间件也是分布式，网络也会有各种各样的节点，咱们没方法去保障每一个节点它都是相对可用的。这外面的任何一环呈现问题，都可能引发系统故障。2020 年，新冠疫情使得实体经济蒙受重创，倒逼各行业减速进行数字化转型降级。随着人们生产习惯的变更，数字经济开始锋芒毕露，一直扩张的宏大用户群体在一些特定的场景下同时涌入零碎，对分布式系统稳定性发动更高的挑战，导致故障频发。
国外亚马逊、谷歌云都曾挂机过，天猫双十一系统故障甚至上了微博热搜以及央视报道，就在 2021 年，滴滴早顶峰也呈现零碎问题，就连美联储也逃不开系统故障。这些事变都在阐明一个事实——目前大多数的企业和组织并没有找到适合的系统故障应答形式，少数仍旧采取被动进攻的形式，后果往往不尽如人意。那么到底该如何保障宏大简单的分布式系统的稳定性，走出故障频发的困局呢？
毛教师教你要学会“踊跃进攻”
毛教师对中国的影响源远流长，他“踊跃进攻”的战略思想，是领导中国革命战争全局与国家军事奋斗全局的基本战略思想，奠定了中国稳固长足发展的基石。这对于咱们来说有很强的指导意义，不同的是咱们的奋斗对象是系统故障，指标是保障系统稳固。
《矛盾论》和《实践论》是毛教师思维的精髓凝聚，先来回顾一下：矛盾论次要讲的是矛盾具备普遍性与特殊性、主次矛盾以及矛盾的主次方面；实践论次要讲的是实际是认知的起源与倒退能源，实际也是测验认知的规范。
分布式系统的稳定性保障自身就比拟难，再加上顶峰流量场景，比方常见的双 11 或者是突发疫情导致行程卡的拜访比平时多 20 倍的状况，咱们该怎么保证系统的稳定性？想要解决这个问题，首先要去辨认它的主要矛盾和次要矛盾，进而再去扭转不稳固的现状。那主要矛盾是什么？咱们又该怎么做到“踊跃进攻”呢？
笔者认为这个主要矛盾就是超大流量冲击超简单的零碎，仍旧靠单点去做评估，要晓得仅从单点去冲破，没有从全局去思考就没有把握能获得全局的稳定性。
“踊跃进攻”当然这不是嘴上说说就行的，具体还是要进行实际。咱们能够向平安行业取取经，“当初的平安是以合规作为测验规范，比方某个单位有没有安全设备，如果有了是不是代表有平安的能力？平安讲一百遍不如打一遍。”360 团体董事长兼 CEO 周鸿祎在某次国内论坛上示意实战应该作为检验能力的唯一标准，而他所说的打一遍就是要对线上零碎做攻防演练。同理零碎稳定性保障也是如此，被动进行峰值流量零碎全链路压测、容量演练是解决主要矛盾的要害一步。
用实际教你如何正确构建踊跃进攻体系
先来看一组数据，2017 年故障时长 1106min 到 2020 年的 0min，这是怎么做到的？
明天就借用物流行业的一家企业实践经验来通知大家如何构建踊跃进攻体系。该企业从 2017 年开始倒退快递业务，到 2021 年 Q3，支出从 70 亿快速增长三倍到当初的 200 亿，随着业务的一直扩张，企业的 IT 零碎也在经验着翻天覆地的变动，为了保障业务的稳固倒退，零碎的稳定性保障也逐步从被动进攻转向踊跃进攻。
测试环境压测
2017 年他们采纳的形式是搭建性能测试环境进行零碎压测，可消耗了大量的人力、硬件资源老本，最初失去的成果还是差强人意，当年双十一 0 点零碎还是呈现了故障，解体 2 小时导致无奈接单，损失惨重。因为测试环境的差异性，一些故障只有在线上才会浮现，当呈现故障后再进行排查定位修复这就是被动进攻，无奈保障系统继续稳固可用。
生产全链路压测
意识到问题所在，他们想要参考阿里双十一，采纳生产环境来做全链路压测，被动进行生产环境零碎稳定性验证。这里就遇到了一个外围难点——实现数据隔离，阿里采纳的是通过革新中间件实现压测数据的辨认和转发到影子区域的计划，可这并不适用于所有的企业。许多企业与该物流公司一样存在中间件不对立、人才储备稀缺、老本考量的问题。
最终他们采纳了市面上成熟的开源产品 Takin，利用 JavaAgent 字节码加强技术，无需革新业务零碎，从 JVM 层面来实现压测数据的辨认和转发。只有装了 Takin 的 Agent 探针，压测流量本人就会乖乖去到这个影子库外面。当然还有一个很重要的货色，如果我是一个领取申请，我不能把压测申请转发到支付宝或微信，Takin 的挡板性能就能帮忙拦挡。此外也有一些 job 或者 check job，只有装置了探针，也能够虚构出 job 的影子过程去做这个事件。
平台工具只是实现目标的一个伎俩，具体的施行过程其实十分重要，也会影响到最终的保障成果，生产环境全链路压测在施行中有 6 项关键性的工作。
压测是一个团队协同配合的工作，演练一方面是演练零碎，另一方面是演练整个组织的这个应急反馈的体系，所以基本上整个过程 IT 团队的每个角色基本上都要参加进来。
通过生产环境全链路压测该企业在硬件资源投入方面缩小了 63%，在人力投入方面缩小了 65%，也达成了双十一顶峰期间的零碎 0 故障的指标。
7*24H 生产巡检
后面始终在讲通过演练去确保双 11 流量顶峰零碎没有问题，解决了主要矛盾，接下来要解决的次要矛盾了。业务量大、业务流程简单，零碎每天都要做公布，那怎么确保公布之后零碎是没有问题的？或者说如果某个 laaS 层或者 pass 层的组件出了问题，怎么确保外围零碎都是 OK 的？快递公司零碎是 7 24 小时的运作的，并不是每一个外围服务都会继续有流量，以订单服务为例，白天流量会比拟高，但到早晨就不高了，因为下订单的人都睡觉去了，而像直达服务它早晨才是流量顶峰。曾有过这样的难堪，早晨零碎订单服务做了变更，到了第二天早上流量才 100 它就呈现故障。很多时候可能都是这种非 500 或者非 200 的报错，甚至个间接抛一些 error 来，它并不是业务逻辑的谬误。为了缩小公布之后的零碎意外，利用 Takin 中 Agent 的数据隔离能力，实现了实在流量在跑的时候同步进行巡检，此外利用测试流量进行 7 24 小时的业务巡检。通过设定响应工夫、成功率去做零碎监测，当理论响应工夫 / 成功率超过预设值时，巡检零碎就会收回揭示，服务飘红 / 飘黄。
总结一下，巡检就是把非业务逻辑的报错，通过技术相干的指标给间接反馈进去。起初该企业还基于巡检以及 TakinAgent 在生产环境实现了混沌工程，被动模仿注入故障来进一步测验零碎的稳定性。
平安畛域有个“零信赖”理念：永不信赖，继续验证。简略来说就是认为你每一次拜访都是不平安的，而后一直地验证你的行为。映射到零碎稳定性保障畛域，当企业具备这种被动验证零碎稳定性的能力，验证的次数越多，你播种的价值就越大。提前发现零碎问题并解决，能力无效地保障业务的连贯性，同时可能将更多的工夫投入到解决业务的问题上，踊跃进攻的效益可见一斑。
文中提及的 Takin 产品外围代码已在 Github 上开源，有趣味的能够自行理解。
开源地址：https://github.com/shulieTech…
