生产环境全链路压测建设历程 21：某快递 A 股上市公司的生产压测案例之彩蛋 2 中篇

上一篇写到，D 公司在生产环境实施了全链路压测后，性能问题得到大幅收敛，但在日程的稳定性这块，仍然有不少的痛点。

前几篇有提到，我们给 D 公司实施全链路压测的核心点在于一个 javaagent 来做流量隔离。而 D 公司的所有核心系统，都带着我们的 javaagent 在运行着。

D 公司的架构师突发奇想，对于核心链路、API 来说，保障可用和保障逻辑完全正确，是不同维度的事情，既然能结合我们的 javaagent 对核心链路做高压力的测试，也可以用低流量、小流量来对核心链路做可用性的巡检。

D 公司的全链路读写巡检实施方案举例

订单

1.菜鸟渠道的下单链路（4 个 API，2 个写 API、2 个读 API）

2.VIP 客户渠道下单链路 （5 个 API，1 个读 API，4 个写 API）

3.微信渠道下单（15 个 API，涉及 6 个写 API，9 个读 API）

中转链路

共 25 个 API，其中写入的 API 有 15 个，读的 API 有 10 个。

实施前后的效果

实施前：

此前 IT 团队主要依赖普罗米修斯、zabbix，业务指标等监控手段，但在出现系统问题的时候，往往都是业务人员更快的发现了系统的不可用情况，更有甚者，因为响应机制、排查机制联动起来比较费时费力，大部分的重大故障，都是因为处理和排查时间过长导致故障升级，影响了更多用户的使用。

实施后：

订单和中转链路，对于 D 公司来说是非常核心的链路。

实施了全链路读写巡检后，D 公司太特意搞了一个大屏幕来展示核心链路的读写巡检状态。

有两大变化点：

1.能够从业务的角度来做模拟巡检，往往在用户发现问题之前，就已经被巡检出来，很多时候有一小部分用户刚报了故障上来，IT 团队已经做好处理。

2.排查速度更快了，探测流量出发 API 的操作，javaagent 本身也能采集很多 APM 的数据，所以在 API 返回为 false 或者 500 等错误代码的时候，会把相关的错误信息也带出来，方便了排查