数列科技杨德华：生产环境全链路压测为系统稳定性保驾护航
在疫情的影响下各行各业都开启了数字化转型加速模式，国家十四五规划中也多次提及数字化经济领域。数字化转型加速势必会带来业务需求的大爆发，随之而来的是系统自身的复杂度的不断攀升，这就带来了新的问题——系统稳定性无法得到有效保障。不禁引人深思：
各个行业稳定性故障频繁出现，是因为什么？
系统稳定性技术保障究竟该怎么进行？是否有可借鉴可复用的经验？
不同行业稳定性故障频现，除了系统复杂度提升这个原因，还有一个原因是缺乏有效的验证手段，无法提前进行故障的发现与处理。如果系统在峰值流量的冲击下还能保障稳定可用无故障，那么在日常运行中的稳定性就毋庸置疑了。作为较早成型的数字化产业，电商行业热衷于造节，为了保障峰值流量下系统稳定性，保障技术也是在持续不断地演进，生产环境全链路压测应运而生，这对于其他行业来说是有一定借鉴意义的。
稳定性故障频发，缺乏有效验证手段是一大原因
除了电商行业大家熟知的双十一、双十二大促峰值流量场景，各行各业都有自身独特的峰值流量场景，滴滴出行早晚高峰打车、保险缴费活动日、银行秒杀活动等等。在这些高峰流量场景下，系统稳定性故障频发，问题出在哪里？
以银行秒杀活动为例，虽然活动场景与电商类似，但银行业还停留在测试环境进行压测验证的阶段，当活动上线，真实流量涌入还是会产生各种各样的问题，比如容量不够、IDC资源不够导致系统出现问题。此外由于活动玩法和业务场景不固定，每次活动都要新增不同的代码，这些代码没有经过有效验证就上线对于系统稳定性来说就是不可控的“定时炸弹”，随时可能爆炸。
透过现象看问题，不难发现稳定性故障频发的一大原因是缺乏有效的验证手段。随着微服务架构的深入，线上系统架构的关系复杂程度不断攀升，SaaS层的微服务调用关系、PaaS层的组件和云原生相关组件容器一直都在不断变化。这些变量形成了新的挑战，可验证手段并没有与时俱进，很多企业还在使用传统的验证手段，在测试环境依赖流量、容量、DB、应用业务系统等单点验证来确认流量来临时的风险，这个过程是非常低效的。
生产全链路压测是稳定性保障的有效验证手段
电商行业在近10年前就已经意识到单点评估的验证手段无法解决系统稳定性故障频发的问题，某知名电商平台也是快速调整策略，开始了生产环境全链路压测的建设之路。在投入了近2000人日来改造中间件之后，实现了压测数据的识别与转发，最终达成生产压测，系统稳定性从3个9进阶到了4个9 。除此之外还带来了许多的附加价值，例如倒逼各个系统的限流、降级演练，而不是到大促才手忙脚乱应战。
生产环境全链路压测是系统稳定性保障的有效验证手段这点没有疑问，可与之不同的是，金融、能源、运营商行业等非互联网行业，数字化进程相对落后，想要实现生产全链路压测遇到的问题更多：
中间件不统一：系统语言都为JAVA，可中间件框架都不同，加起来甚至多达数百种；
人才储备不够：难以吸引众多的技术专家来进行中间件的优化工作；
时间成本高：真的要进行中间件改造周期太长，对于管理者来说，自研的ROI并不高；
那么没有时间、没有充足人力的企业，如何实现生产环境全链路压测呢？最好的方式就是有一种工具或者产品可以帮助企业在无需改造业务的情况下实现压测数据的识别和转发，通过生产环境全链路压测来进行系统稳定性保障目标的有效验证。数列科技推出主动防御式系统稳定性保障平台Takin，并且已在Github开源。
Takin利用JavaAgent来实现0侵入式接入。Java业务应用在启动的时候，只要加上JavaAgent参数，就能带动压测探针增强支持的中间件，实现压测标的识别和传递。在应用内，压测标存放在threadlocal里，当业务操作请求经过数据源的时候，会根据是否携带压测标来区分是业务流量还是压测流量，如果是压测流量就会转发到配置的影子区域里，避免影响业务。
基于Takin分四步走，就能完成系统稳定性目标的有效验证，具体如下：
在Takin的帮助下，生产环境全链路压测已经在众多企业落地实施，效果也是十分显著。从IT团队的工作状态转变中就能看出：在面对峰值流量场景时，摆脱了因为系统复杂单点验证而低效工作的状态，提前压测提前发现稳定性问题并解决，不再需要因为故障处理时间长、定责难而时时刻刻处在救火状态。
目前Takin产品的核心代码已在Github上开源，有兴趣的可以自行了解。
https://github.com/shulieTech/Takin