小编点评

**JSF1.7.6预热实践报告** **背景** 京东VOP平台(开放平台)适合于自建内网采购商城平台的企业客户。为了提升平台性能，京东为这类客户专门开发API接口，对接到客户内网的网上商城，将产品SKU直接推送到客户内网，客户内部采购人员可以直接在内网商城进行下单采购，订单信息通过API接口传递到京东后台，由京东安排物流配送服务。 **预热管理实践问题** 当应用启动后，部分接口的超时请求可能会导致系统出现“TP99/可用率”报警。为了解决这个问题，我们需要找到问题本质并找到问题通用性，进而解决问题，推广各平台，最终达到良性循环。 **解决方案** 通过针对地址应用及自产自销的JSF接口进行测试实践，并形成以下报告，我们解决了JSF1.7.6版本上线过程中出现“TP99/可用率”报警的问题。 **测试过程** 1. 使用压力机模拟调用接口，模拟上线流程。 2. 设置预热管理，配置地址和权重。 3. 监控性能变化，记录指标如CPU占用率、网络连接状态等。 **实验结果** * 未设置预热管理时，“TP99/可用率”报警出现，严重影响平台性能。 * 设置预热管理，配置地址和权重后，“TP99/可用率”报警消失。 * 实验结果表明，设置预热管理可以有效降低性能波动，提升平台性能。 **结论** 通过对JSF1.7.6版本的预热实践，我们成功解决了“TP99/可用率”报警问题，并提升了平台性能。

正文

作者：京东零售 李孟东

00 导读

企业前台研发部包含了企业业务大部分的对外前台系统，其中京东VOP平台(开放平台)适合于自建内网采购商城平台的企业客户。

京东为这类客户专门开发API接口，对接到客户内网的网上商城，将产品SKU直接推送到客户内网，客户内部采购人员可以直接在内网商城进行下单采购，订单信息通过API接口传递到京东后台，由京东安排物流配送服务。VOP模式下，客户内网的数据信息京东并不抓取，从而实现内部采购架构的独立搭建及数据的保密与安全。

随着业务的不断发展过程中，VOP截至目前已经服务于上千家企业Sass商城，其API接口的高并发、高可用、高可靠也就越发的重要。尽管我们如履薄冰的进行上线来尽可能的降低对接口的波动，但是发现，当下我们整个的上线流程中无损下线是没问题（NP层冷备机器直至无流量打进来，JSF层下线JSF服务），但是（自身&服务提供方）上线的瞬时波动都会或多或少引起我们系统的一阵报警。

这对于一个"夜黑风高" 即将回家的我们多大的伤害。毕竟每一次性能或者可用率的报警都牵动着我们作为技术的心血管（牵动着客户的投诉...）。

本文将从JSF1.7.6预热的实践测试报告中，真实的讲述预热给我们平台带来的体验和帮助，供大家参考。

01 背景

应用调用情况

场景一：对外服务，部分接口发布过程中出现了大量的 5xx 超时异常，根据和客户侧研发团队的沟通，大概确定在应用启动后的时间点，会有部分接口的超时请求。

场景二：服务提供者接口发布，机器启动后，会有调用JSF超时请求。

以上两种情况都会影响到服务的稳定性，进而引起我们系统的一阵（TP99/可用率）报警，如下所示：

【补充】这里同步一下检测工具：我们如何得知上下游是否存在部署事件。见：泰山平台故障分析模块，可以智能分析出上下游故障，或历史问题排查。

详细地址：
http://taishan.jd.com/faultAnalysis

帮助文档：
https://cf.jd.com/pages/viewpage.action?pageId=491274317

通过故障分析，我们发现我们所依赖的接口系统正在处于部署状态，也就是说其上线发布影响到了我们接口的稳定性。

02 预热管理实践

问题是显而易见的，那么如何发现问题本质，并找到问题通用性，进而解决问题，推广各平台，最终达到良性循环，是我们着重需要考虑的。

解决思路：JSF1.7.6版本特性三：预热策略动态下发，提升Provider实时治理能力通过服务器其负载均衡的能力，对于上线需要预热的接口进行流量权重的调整，做到刚上线的应用按照对应所配置的规则进行小流量预热，使用方只需指定预热规则即可按照预期对刚上线的节点进行小流量预热。

当然新功能的引入，小至工具包升级，大至基础服务升级，都需要足够的测试实践和验证回归，一方面测试该功能是否符合我们的诉求，另一方面避免直接引入导致的一些未知异常。因此我们通过针对地址应用及自产自销的JSF接口进行测试实践，并形成以下报告。

机器配置

共计5台服务器 规格：4c8g

四台提供者：11.94.2.225,11.94.13.242,11.94.65.31,11.94.65.45

一台消费者：11.38.181.175

考虑到篇幅的问题，本文主要描述其中一个接口的上线情况，具体实践报告见：
https://joyspace.jd.com/page/LxPqDgcSA3GVjSYQRb73

涉及接口

HTTP接口（消费者）：
https://bizapi.jd.com/api/area/getTown

JSF接口（提供者）：
com.jd.ka.vop.soa.address.sdk.provider.QueryAddressOpenProvider#queryJdAreaIdList

测试流程

采用压力机，模拟调用对应接口，流量稳定后，模拟上线流程，按照50%的比例发布两台机器进行测试。

未设置预热管理

如下为流量稳定调用的UMP监控：

提供者监控

消费者监控

未设置预热发布上线

发布周期（15:40——15:44）发布机器比例50%

提供者监控

消费者监控

通过上方监控图，我们可以清晰的看出：

• 无损下线过程符合预期，并且下线过程中并没有出现任何报错。
• 报错和性能下降期间处于服务端应用成功启动后且注册成功后。

设置预热管理（流程同未设置预热情况）

配置地址：
http://taishan.jd.com/jsf/protection/index

补充：

• 权重和周期指的是初始权重到目标权重100，在预热周期内线性增长，流量在新节点逐渐增长的过程。（即：小流量预热）
• 在泰山流量防护页面中新增的接口配置，必须是拥有该接口权限才可以直接进行配置。
• 在泰山平台配置后，则直接面向所有消费者有效。当然也可以使用JSF的标签配置进行预热，就仅对自身服务器有效。
• 预热周期最大2min

这里有个小插曲，最初我设置的权重为：预热权重：10 周期：30000ms，但是在测试结果中发现，效果并不明显，如下：

因此调整配置策略：预热权重1，周期60000ms。以此降低初始权重，增大预热周期。

设置预热发布上线

发布周期（17:36——17:40）发布机器比例50%

提供者监控

效果十分明显，如下：

03 总结

综上，性能波动影响，从直接发布的50%占比机器上看，配置预热后，其中一台影响下降了2.8——15倍左右；另一台机器上线性能波动几乎可以忽略（16ms）。（测试接口本身性能queryJdAreaIdList TP99 11ms左右）

故，经过评估：provider冷启动后的瞬时TP耗时高，调用波动大进而导致请求有损的问题，可以通过自动预热机制解决。

当然，根据目前行业的一些解决方案，无损上线功能远不止于此，期待JSF预热功能的能力与场景不断地大家的实践反馈中逐渐完善与丰富。