后端服务之应用预热

一 背景

   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    

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