JSF预热功能在企业前台的实践与探索
Tech 导读 企业前台包含了企业业务大部分的对外前台系统，其中京东VOP平台(开放平台)适合于自建内网采购商城平台的企业客户。京东为这类客户专门开发API接口，对接到客户内网的网上商城，将产品SKU直接推送到客户内网，客户内部采购人员可以直接在内网商城进行下单采购，订单信息通过API接口传递到京东后台，由京东安排物流配送服务。VOP模式下，客户内网的数据信息京东并不抓取，从而实现内部采购架构的独立搭建及数据的保密与安全。 随着业务的不断发展过程中，VOP截至目前已经服务于上千家企业SaaS商城，其API接口的高并发、高可用、高可靠也就越发的重要。尽管上线时尽可能的降低对接口的波动，整个上线流程中无损下线是没问题（NP层冷备机器直至无流量打进来，JSF层下线JSF服务），但是（自身&服务提供方）上线的瞬时波动或多或少会引起系统的一阵报警，每一次性能或者可用率的报警都可能带来客诉。 JSF1.7.6对于预热策略动态下发特性的升级公告吸引了作者，所以本文也将从JSF1.7.6预热的实践测试报告中，真实的讲述预热给前台带来的体验和帮助，希望对读者有参考作用。
01
背景
在今年的敏捷团队建设中，我通过Suite执行器实现了一键自动化单元测试。Juint除了Suite执行器还有哪些执行器呢？由此我的Runner探索之旅开始了！
1.1 应用调用情况
场景一：对外服务，部分接口发布过程中出现了大量的 5xx 超时异常，根据和客户侧研发团队的沟通，大概确定在应用启动后的时间点，会有部分接口的超时请求。
场景二：服务提供者接口发布，机器启动后，会有调用JSF超时请求。
以上两种情况都会影响到服务的稳定性，进而引起系统的一阵（TP99/可用率）报警，如下所示：
同步检测工具：如何得知上下游是否存在部署事件。内部泰山平台故障分析模块，可以智能分析出上下游故障，或历史问题排查。
通过故障分析，发现所依赖的接口系统正处于部署状态，即上线发布影响到了接口的稳定性。
02
预热管理实践
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。
问题是显而易见的，那么如何发现问题本质，并找到问题通用性，进而解决问题，推广各平台，最终达到良性循环，是着重需要考虑的。
解决思路：JSF1.7.6版本特性三：预热策略动态下发，提升Provider实时治理能力。通过服务器其负载均衡的能力，对于上线需要预热的接口进行流量权重的调整，做到刚上线的应用按照对应所配置的规则进行小流量预热，使用方只需指定预热规则即可按照预期对刚上线的节点进行小流量预热。
当然新功能的引入，小至工具包升级，大致基础服务升级，都需要足够的测试实践和验证回归，一方面测试该功能是否符合诉求，另一方面避免直接引入导致的一些未知异常。因此通过针对地址应用及自产自销的JSF接口进行测试实践，并形成以下报告。
2.1 机器配置
共计5台服务器 规格：4c8g
四台提供者：
11.94.2.225,11.94.13.242,11.94.65.31,11.94.65.45
一台消费者：11.38.181.175
考虑到篇幅，本文主要描述其中一个接口的上线情况。
2.2 涉及接口
HTTP接口（消费者）：
https://bizapi.jd.com/api/area/getTown
JSF接口（提供者）：com.jd.ka.vop.soa.address.sdk.provider.QueryAddressOpenProvider#queryJdAreaIdList
2.3 测试流程
采用压力机，模拟调用对应接口，流量稳定后，模拟上线流程，按照50%的比例发布两台机器进行测试。
2.4 未设置预热管理
如下为流量稳定调用的UMP监控：
提供者监控
消费者监控
2.5 未设置预热发布上线
发布周期（15:40——15:44）发布机器比例50%。
提供者监控
消费者监控
通过上方监控图，可以清晰的看出：
无损下线过程符合预期，并且下线过程中并没有出现任何报错。
报错和性能下降期间处于服务端应用成功启动后且注册成功后。
2.6 设置预热管理
补充：
权重和周期指的是初始权重到目标权重100，在预热周期内线性增长，流量在新节点逐渐增长的过程（即：小流量预热）。
在泰山流量防护页面中新增的接口配置，必须是拥有该接口权限才可以直接进行配置。
在泰山平台配置后，则直接面向所有消费者有效。当然也可以使用JSF的标签配置进行预热，就仅对自身服务器有效。
预热周期最大2min
这里有个小插曲，最初设置的权重为：预热权重：10 周期：30000ms，但是在测试结果中发现，效果并不明显，如下：
因此调整配置策略：预热权重1，周期60000ms。以此降低初始权重，增大预热周期。
2.7 设置预热发布上线
发布周期（17:36——17:40）发布机器比例50%。
提供者监控
效果十分明显，如下：
03
总结
理解，首先 MCube 会依据模板缓存状态判断是否需要网络获取最新模板，当获取到模板后进行模板加载，加载阶段会将产物转换为视图树的结构，转换完成后将通过表达式引擎解析表达式并取得正确的值，通过事件解析引擎解析用户自定义事件并完成事件的绑定，完成解析赋值以及事件绑定后进行视图的渲染，最终将目标页面展示到屏幕。
综上，性能波动影响，从直接发布的50%占比机器上看，配置预热后，其中一台影响下降了2.8——15倍左右；另一台机器上线性能波动几乎可以忽略（16ms）（测试接口本身性能queryJdAreaIdList TP99 11ms左右）。
故，经过评估：provider冷启动后的瞬时TP耗时高，调用波动大进而导致请求有损的问题，可以通过自动预热机制解决。
当然，根据目前行业的一些解决方案，无损上线功能远不止于此，期待JSF预热功能的能力与场景不断从实践反馈中完善与丰富。
打造SAAS化服务的会员徽章体系，可以作为标准的产品化方案统一对外输出。结合现有平台的通用能力，实现会员行为全路径覆盖，并能结合企业自身业务特点，规划相应的会员精准营销活动，提升会员忠诚度和业务的持续增长。