记一次服务发布不平滑问题

背景

微服务在发布时每次都会出现下游服务接口调用超时现象，导致在服务发布时产生报警，影响用户体验和服务可靠性

目标

能随时发布微服务，新旧机器平滑切换，中间不产生异常现象

问题分析及解决方案

问题分析

通过分析可能会有以下几种情况会产生不平滑问题：

1. 机器配置低
2. QPS/并发高
3. 接口耗时长
4. eureka注册表未及时摘除下线机器IP

解决方案

1. 机器配置低

这种情况一般需要看监控cpu、load、内存情况，如果真存在一直很高，当发布或服务运行当中时会影响机器处理速度，会产生线程运行超时情况，直接升配置即可

2. QPS/并发高

其实和机器配置低也有一些关系，也是要看cpu处理能力，还有机器配置调优linux打开句柄数，还有tomcat并发数量，这里不写具体调优方法了，网上能随便找到调整资料

3. 接口耗时过长

可以通过监控skywalking相关统计工具、接口中增加stopwatch分析具体耗时长位置
可以通过以下方式进行解决：

• 实例类做成单例，需要关注是否有并发安全问题
• 接口预热，因为Spring的servelet是懒加载模式，所以在刚启动首次访问会产生比较多的类初始化，会增加整体耗时，预热方式如下
  ⅰ. 在spring boot提供的启动完成事件内http请求
  ⅱ. 在服务健康检查中做接口请求
  ⅲ. 网站说的配置severlt配置（本人试后效果不明显）
• 数据预热，对固定数据进行缓存，或提前缓存，达到缩短整体耗时目的
• 池化技术，可以通过common-pool2进行对一些数据进行提前初始化，用时拿，用完还。文章后面会给demo

4. eureka注册表未及时摘除下线机器IP

• 熟悉下eureka注册机制
  
  当机器上线或下线，客户端能移除对应上下线机器ip时间为：
  如果说一个服务的正常下线，极端的情况这个时间应该就是 30+30+30+30 差不多 120 秒的时间了。
  如果服务非正常下线，还需要靠每 60 秒执行一次的清理线程去剔除超过 90 秒没有心跳的服务，那么这里的极端情况可能需要 3 次 60秒才能检测出来，就是 180 秒的时间。
• 解决方案：
  按照以下配置客户端最大感应时间为2+5+10=17s，很大程度上减少服务之间平滑切换，可根据实际情况调整

# 服务调用方的ribbon缓存时间 单位毫秒
ribbon.ServerListRefreshInterval = 2000
#向注册中心更新实例时间间隔
eureka.client.registry-fetch-interval-seconds = 5
#心跳时间
eureka.instance.lease-renewal-interval-in-seconds = 10

# eureka禁用读取只读注册表
eureka.server.use-read-only-response-cache = false

5.其他解决方案

• 运维层面
  如果k8s部署，可以延长下线机器的存过时长，在可伸缩时间内完成流量的切换，防止流量继续打到下线机器
  如果虚拟机/物理机部署和上方方案一直，只不过相同ip在服务器需要先kill掉原服务才能起新服务，所以下kill之前要处理好流量问题