一 背景

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

可根据应用的启动时间和特性，调整应用匹配的预热周期，达到相对预热效果最好的状态。至于是否有必要结合流量回放和流程编排实现预热，需结合自己的业务情况和实现成本考虑。

作者：京东科技 张石磊

来源：京东云开发者社区 转载请注明来源