物流中台架构升级之快递全链路压测与优化-京东云开发者社区

# 1  项目简介
随着公司在业务、技术、组织的不断发展，公司销售业绩日渐增长，业务需求不断增多，在以客户为中心的理念下， 我们在产品和技术层面，始终没有形成统一接入标准，造成客户接入效率较低，接入时间长，对接团队职责变换等问题和挑战。
为满足各种渠道用户的需求， 为更好的处理以下问题、痛点及公司长远发展的考虑，构建一个渠道接入简单高效、渠道管理安全可控、渠道灵活定制、高效稳定的统一渠道接入平台的需求势在必行。搭建快递渠道接入专项团队（业务、产研测），整合C2C/B2C/C2B渠道，统一标准与架构，提升渠道接入体验。
本次项目由快递快运提供标准接口，聚合200+渠道的接入能力，预计达到日单量千万级，涉及到的链路较长，需要保证全链路的性能达标。
渠道接入能力示意图:

![](//img1.jcloudcs.com/developer.jdcloud.com/8b30b71a-f2a8-406b-8284-0863dc8f66ad20221205165334.png)
<center>图1.渠道接入能力示意图</center>

# 2  下单全链路压测过程简介
## 2.1 压测链路调用梳理
本次压测交易为B2C下单场景，涉及的核心服务为快递渠道接入平台服务和订单中心服务。订单中心服务会同步调用下游多个服务（见图2交易层的绿色服务，均为订单中心调用的下游服务），同时订单中心下游也有异步服务。
压测过程中，压测平台模拟下单场景调用渠道接入平台，渠道接入平台同步调用订单中心服务（渠道接入平台同时还会调用其他服务，主要是调用订单中心服务），订单中心服务调用下游服务对数据加工处理成功后下发MQ，写入MQ后，回传上游B2C下单成功，下游系统异步消费MQ处理后续业务逻辑。所以影响下单体验的核心服务为渠道接入平台和订单中心服务，本轮压测重点关注的服务也是这两个服务（快递渠道接入平台服务、订单中心服务）。
压测链路调用示意图如下：

![](//img1.jcloudcs.com/developer.jdcloud.com/6a20c9d9-a0a3-43ee-a4f4-50810c0fc06520221205165427.png)
<center>图2.压测链路示意图</center>

本压测链路调用示意图只包括正向下单流程。通过梳理压测链路，可以明确测试范围，根据范围找到对应的1号位人员，以便压测过程中做好上下游联动沟通和监控，规避线上压测风险。

## 2.2 ump监控面板梳理
因为压测链路比较长，跨多个系统调用，为了能及时发现压测过程中的性能问题，对核心系统的核心接口ump做了梳理并形成ump面板。
为什么这么强依赖ump监控（ump监控面板如图3）？如果整个调用链路服务都接入能够全采的性能监控工具，问题定位会方便一些，但是实际情况是，要么是监控工具不能够全采；要么是工具能全采，但是有部分服务没有接入，造成调用链路终断。这两种数据采集场景都会造成监控到的调用链路数据不是你想要的数据。所以本次压测问题定位主要靠ump监控、服务日志监控和优秀的工程师，半刀工火种时代。

![](//img1.jcloudcs.com/developer.jdcloud.com/7736640e-c69e-4430-b85b-25575b6e7cea20221205165508.png)
<center>图3.链路核心接口ump监控面板</center>

## 2.3 全链路压测技术方案制定
通过压测链路的梳理总结，压测涉及到外围服务比较多，且服务间调用存在跨集团的情况，线下准备压测环境变的异常复杂，更准确一点说，是不存在线下准备压测环境的可行性，所以本次压测必须在生产环境进行。
考虑到压测结果的精准性，本次压测采用生产环境集群压测方案（因为调用的链路比较长，等比例下线服务器进行压测也比较困难，同时等比例下线服务器进行压测，最后得到的压测结果也存在不精准的问题，所以采用生产环境集群压测方案）。本次压测是写交易压测，为了不污染线上生产数据，本次压测采用数据打标方式，快递渠道接入平台服务解析压测报文中的remark字段属性值，把该值写入线程的threadLocals中，订单中心分流层服务解析该值，如果是压测流量，则把流量分流到压测分组进行落库。
压测技术方案示意图如下：

![](//img1.jcloudcs.com/developer.jdcloud.com/49fae481-6f38-4083-8c68-e0283cd3772820221205165602.png)
<center>图4.全链路压测技术方案示意图</center>

风险规避：压测环境准备过程中，为了规避风险，不影响生产，主要为以下几个策略。
订单中心落库走AB环境（压测分组），承接写流量。
产品中心提供压测分组（压测分组下游调用生产环境，提供单独分组防止产品中心服务被打挂，影响生产）。
预分拣服务提供压测分组（压测分组下游调用生产环境，提供单独f分组防止预分拣服务被打挂，影响生产）。

## 2.4 核心非功能指标梳理
渠道标准下单接口TPS（下单链路最前端服务）：大于600笔/s。
渠道标准下单接口TP99（下单链路最前端服务）：小于500ms。
渠道标准下单服务CPU%（下单链路最前端服务）: 小于60%。
渠道标准下单服务可用率（下单链路最前端服务）:等于100%。

# 3  下单全链路第一轮优化——日志治理
## 3.1 性能问题表象
第一轮全链路压测过程中，随着并发线程数增加，下单业业务吞吐量开始有线性提升，但当吞吐量在达到某个量级后，再增加线程数时，压测链路最前端的快递渠道接入平台服务的渠道标准下单接口，出现TP99飙升现象，见图5(tp99从700ms左右飙升到1500ms左右)。

![](//img1.jcloudcs.com/developer.jdcloud.com/8d015d36-cf2e-4c29-a9e1-81cfade2af5c20221205165657.png)
<center>图5.渠道标准下单接口ump监控</center>

通过ump监控面板，发现订单中心分流层接口的ump波动情况和渠道标准下单接口ump监控波动趋势基本一致，如下图6。通过ump监控，可以确定渠道侧tp99飙升是由订单中心分流层接口TP99飙升造成的，所以需要重点关注订单中心分流层服务的性能。

![](//img1.jcloudcs.com/developer.jdcloud.com/50307b1c-21ee-4550-ae19-75d30b44e97c20221205165757.png)
<center>图6.订单中心服务分流层接口ump监控</center>

通过比较图5和图6，可以确定造成链路tp99飙升的原因，是由订单中心分流层接口造成。

## 3.2 性能问题原因及优化方案
第一轮压测过程中，通过ump监控整个压测链路的核心节点，最先出现瓶颈点的服务为订单中心分流层服务。所以需重点关注订单中心分流层服务的硬件资源使用情况和服务内部耗时情况。
问题分析过程：当链路吞吐量达到350笔/s时，订单中心分流层服务的cpu使用率偏高、响应时间飙升（打印日志过多导致线程Blocked），怀疑是日志打印过多造成，对该服务进行日志降级后，响应时间下降明显。所以订单中心分流层接口的tp99飙升是由日志打印造成。
分析是否是日志阻塞造成tp99飙升的常用方法：使用jstack命令打印线程堆栈（或者其他工具），查看Blocked状态的线程是否由日志打印引起。如下图7，该Blocked状态的线程是由日志打印引起。

![](//img1.jcloudcs.com/developer.jdcloud.com/87c4e1ce-7deb-4fc7-9924-6a41cb79c3bb20221205165833.png)
<center>图7.jstack命令打印线程堆栈信息</center>

优化方案：
当日志打印造成线程阻塞时，常见的优化方案如精简业务日志，异步日志打印，应用服务器扩容，业务高峰期日志降级等。

## 3.3 优化后效果
订单中心分流层服务日志降级后，下单调用链路最前端的服务（快递渠道接入平台服务）的渠道标准下单接口TP99响应时间下降明显（从1500ms左右降到700ms左右），见图8。

![](//img1.jcloudcs.com/developer.jdcloud.com/712df7d1-9ef3-42a1-8f23-229cf75482c420221205165915.png)
<center>图8.渠道标准下单接口ump监控</center>

订单中心分流层服务日志降级后，订单中心服务的分流层接口TP99响应时间下降明显（从1400ms左右降到400ms左右），见图9。

![](//img1.jcloudcs.com/developer.jdcloud.com/1f9c274f-0b4f-407f-b769-9f8cebf89a0520221205165945.png)
<center>图9.订单中心服务分流层接口ump监控</center>

经过第一轮优化后，响应时间有明显下降，但是下单链路的TP99仍在700ms左右，不满足预期TP99小于500ms需求，需要继续优化。
根据图8和图9分析，700ms左右的链路的响应时间，渠道标准下单接口耗时300ms左右，订单中心分流层接口耗时400ms左右。因为整个B2C下单链路耗时不满足预期需求，所以需要下单链路联动优化，才能有效降低响应时间（主要是渠道接入平台和订单中心服务优化）。

# 4  下单全链路第二轮优化——重复调用治理
## 4.1 性能问题表象
经过第一轮优化后，整个下单链路的TP99响应时间在700ms左右（渠道接入平台服务的渠道标准下单接口耗时300ms左右，订单中心耗时400ms左右），不满足预期TP99小于500ms需求，需要继续优化。

![](//img1.jcloudcs.com/developer.jdcloud.com/b765bb65-1cc9-4689-94e0-56b7d1d8e2f620221205170027.png)
<center>图10.渠道标准下单接口ump监控（第一轮优化后）</center>

## 4.2 性能问题原因及优化方案
通过监控和梳理压测链路的主要耗时节点（渠道接入平台300ms左右，订单中心耗时400ms左右），发现渠道接入平台服务的渠道标准下单接口业务和订单中心服务的接单业务均会调用京标解析服务（GIS）。一次下单过程中存在重复调用下游服务情况，上下游服务的相关人员联动沟通，确定可以减少一次京标解析服务调用。
优化方案如下图11:

![](//img1.jcloudcs.com/developer.jdcloud.com/b29b98e2-935d-43fc-b096-7f54be5cb51720221205170102.png)
<center>图11.重复调用优化方案示意图</center>

优化后，渠道标准下单服务调用京标解析服务（gis），下传京标解析服务的返回值给订单中心服务，同时下传授信标识给订单中心服务，订单中心获取授标识后不再调用京标解析服务，这样整个下单链路可以减少1次京标解析服务调用，整个调用链路耗时可以节约100ms左右。

## 4.3 优化后效果
经过第二轮优化后，下单链路的tp99在610ms左右，如下图12。链路整体耗时比第一轮优化后降低100ms左右），仍不满足预期TP99小于500ms需求，需要继续优化。

![](//img1.jcloudcs.com/developer.jdcloud.com/88a8307a-1580-4306-8cc1-c7a11c4c4a9320221205170234.png)
<center>图12.渠道标准下单接口ump监控（第二轮优化后）</center>

# 5  下单全链路第三轮优化——无效调用治理
## 5.1 性能问题表象
第二轮全链路压测过程中，开启ump秒级监控，发现渠道标准下单接口的TP99毛刺现象比较严重，有部分毛刺点超过1000ms，如图13。

![](//img1.jcloudcs.com/developer.jdcloud.com/97bddd92-5fc1-4ebb-8752-cf49ed2d068a20221205170310.png)
<center>图13.渠道标准下单接口ump监控（秒级监控）</center>

## 5.2 性能问题原因及优化方案
通过日志分析TP99毛刺点的耗时分布（渠道下单服务做了日志切面，选其中一个毛刺点分析日志，其它毛刺点也都是同类原因），下单耗时的毛刺点均是调用简单站点匹配服务造成(该服务耗时占用毛刺点80%以上)。日志响应报文如下：
2022-07-04 20:26:31.518[ Eca_TaskExecutor-1498:7670240 ] - [INFO ] cn.jdl.jecap.base.config.jsf.JsfLogFilter-invoke:130 - 1465509.55649.16569375906914906 - [eecbc016-51a5-4df0-ade1-55b19e0f8270]eca.for_yace-jdl-eca-standard-ability.com.jd.bluedragon.preseparate.jsf.StationMatchServiceApi.stationMatchByAddress.response={"code":200,"data":{"roadCode":"002","separateType":61,"stationId":1480,"stationName":"武汉黄陂营业部"},"message":"OK"}, taskmillseconds=827ms
通过日志分析分析耗时分布比较尴尬（pfinder不能全采；SGM可以全采，但是生产环境没有接入，只能靠日志分析，吐槽一下哈）。
确认该接口造成毛刺现象后，上下游服务相关人员联动沟通，讨论优化方案时发现渠道侧不需要调用简单站点匹配服务，并且如果渠道侧使用该接口回传的数据下发给下游系统，可能会造成生产环境系统bug。
优化方案如下图14：

![](//img1.jcloudcs.com/developer.jdcloud.com/54ebf864-88ca-401d-a758-8c9c4072ede420221205170357.png)
<center>图14.无效调用优化方案示意图</center>

优化后，渠道侧不调用简单站点匹配服务，减少一次无效的服务调用，可以减少100ms左右耗时。

## 5.3 优化后效果
经过第三轮优化后，因为去掉了无效的调用逻辑，下单链路的tp99在530ms左右（链路整体耗时比第二轮优化后降低100ms左右），如下图15。仍不满足预期TP99小于500ms需求，需要继续优化。

![](//img1.jcloudcs.com/developer.jdcloud.com/469cfc89-812c-4ba7-9311-790e0e0600f420221205170431.png)
<center>图15.渠道标准下单接口ump监控（第三轮优化后）</center>

经过第三轮优化后，毛刺现象明显减少，如下图16。但是仍存在部分超过500ms的毛刺，需要继续优化。

![](//img1.jcloudcs.com/developer.jdcloud.com/6dcdd1ae-4093-445c-81d5-75d9cb2b9de720221205170505.png)
<center>图16.渠道标准下单接口ump监控（秒级，第二轮优化后）</center>

# 6  下单全链路第四轮优化——串行调用治理
## 6.1 性能问题表象
第三轮优化后，下单链路整体TP99仍超过500ms（分钟级监控），如图17。秒级监控仍有部分毛刺点tp99超过500ms。

![](//img1.jcloudcs.com/developer.jdcloud.com/779d34e9-4536-4315-a2f5-e9e55ac474e020221205170542.png)
<center>图17.渠道标准下单接口ump监控（第三轮优化后）</center>

## 6.2 性能问题原因及优化方案
通过日志分析TP99毛刺点的耗时分布（渠道下单服务做了日志切面），下单耗时的毛刺点大部分都是渠道侧调用下游时间分片接口引起，具体的日志分析过程如第三轮优化，不再详细展示分析日志过程。查看时间分片接口的ump监控显示，正常情况下该接口的TP99在100ms左右。
为了对齐渠道侧调用时间分片的逻辑是否有优化空间，上下游服务相关人员联动沟通后，明确下单过程中，B2C业务可以后置获取时间分片（揽收时间相关）。B2C下单不需要像C2C和C2B的业务逻辑，必须前置时间分片接口获取返回值。
渠道侧下单逻辑最外层代码会顺序调用异步任务执行的时间分片接口获取返回值和订单中心创建订单接口。渠道侧调用时间分片接口进行业务逻辑计算过程是异步任务，下单过程中会有类似future.get()操作获取异步任务的返回值，执行get()方法同样会造成线程等待，所以后置future.get()可以节约部分时间。
为什么后置异步任务结果获取会节约部分响应时间：在下单流程中，获取时间分片的接口会被异步逻辑先调用，异步任务执行完，如果下单的业务逻辑还没执行到get()方法，异步任务的返回值会存在内存里，等到执行get()方法时直接从内存里面获取结果，相当于获取时间分片逻辑和调用订单中心的逻辑并行执行，可以节约部分响应时间。
优化方案如下图18：

![](//img1.jcloudcs.com/developer.jdcloud.com/7bfed484-b971-4e3b-8b26-5ba3a3f60e6720221205170653.png)
<center>图18.串行调用优化方案示意图</center>

后置执行获取时间分片返回值的future.get()方法，相当于获取时间分片逻辑和调用订单中心的逻辑并行执行，可以节约部分响应时间（串行执行变并行执行）。
## 6.3 优化后效果
经过第四轮优化后，下单链路的tp99在460ms左右，满足预期TP99小于500ms的需求，同时吞吐量和硬件资源利用率也满足预期需求。

![](//img1.jcloudcs.com/developer.jdcloud.com/28644d02-22df-4ed0-801f-331d28bb687020221205170734.png)
<center>图19.渠道标准下单接口ump监控（第四轮优化后）</center>

# 7  总结
经过几轮优化后，B2C下单链路的tp99从1500ms左右降到460ms左右。优化过程中，有些优化点看似是某个服务的优化改造行为，实际需要上下游服务相关人员联动沟通才能确定最终优化方案，完成整个链路的优化。所以沟通协调能力是全链路压测优化的重要保障。
生产环境全链路压测需要有高度的风险意识，由其是调用链路较长且有写操作的压测，需要对链路中的每个风险点沟通确认，需要有成熟的数据隔离方案，最终闭环风险。所以闭环风险能力是全链路压测的关键环节。
优化过程中借助监控工具更容易发现潜在的问题，全链路压测执行前，上下游服务接入统一的可以全采的链路调用跟踪工具，可以更好的定位问题。所以选型好用的工具可以让优化工作达到事半功倍效果。

------------
自猿其说Tech-JDL京东物流技术与数据智能部
**作者：张航舰 彭越**