共计 926 个字符，预计需要花费 3 分钟才能阅读完成。
一 背景
C 端服务利用降级和重启，导致耗时刹时抖动，业务超时，利用监控报警，上游感知显著，导致用户体验变差。
二 利用降级重启导致抖动的起因
1 C 端服务利用降级和重启的冷启动阶段，它须要从新加载和初始化各种资源，例如数据库连贯、缓存数据等，导致耗时刹时飙升。
2 利用重启后，本地缓存生效，利用须要从新加载数据，导致耗时变长。
3 利用重启后，有大量申请沉积，导致系统负载减少，线程解决不及时，导致系统响应变慢。
三 解决方案
1 停服时，先下线 JSF 接口，再降级利用，待利用启动胜利后，JSF 服务接口提早注册到注册核心。
2 JSF 开启预热性能，是服务提供者重启后，JSF 上线后，消费者与服务者建设链接后，调用方客户端先放设置比例的小局部流量过去到降级重启的实例，在预热周期内，逐渐到 100%
3 在利用降级流程编排中，联合流量回放，编排流程，在流量回放后再操作 JSF 上线，实现略简单，依赖根底运维
计划 1，计划 2 实现简略，预热成果也比拟好，应用的是 JSF 的预热性能，以下成果比照的实现来自计划 2 的 JSF 预热性能。
四 采纳 JSF 开启预热性能成果比照
1 服务提供者配置预热周期
预热初始权重：consumer 连贯到 provider 后，provider 的初始权重（provider 端权重会在预热周期内会逐步复原到失常权重，个别是 100）
2 未开启预热容器实例整体降级重启监控：
利用部署在 3 个机房，所以看到 3 次抖动，能够看到 TP999 最高的机房达到了近 25s。
开启预热后整体实例降级重启成果：
利用部署在 3 个机房，所以看到 3 次抖动，能够看到 TP999 最高的机房降到了 2.5s，降幅达 10 倍。
3 未开启预热，单实例利用重启监控
max 达到了 20s,TP999 达到了 18s
开启预热后，单实例利用重启监控
max 降到了 2s,TP999 将到了 1.5s 左右，降幅达 10 倍，TPS 在配置的预热周期内（60s）出现线性增长
五 注意事项
依赖服务调用方降级 JSF 到 1.7.6 版本及以上，推动所有调用方降级 JSF
可依据利用的启动工夫和个性，调整利用匹配的预热周期，达到绝对预热成果最好的状态。至于是否有必要联合流量回放和流程编排实现预热，需联合本人的业务状况和实现老本思考。
作者：京东科技 张石磊
起源：京东云开发者社区 转载请注明起源
