文档

如何实现无损发布或无损上下线

更新时间:

本文介绍如何通过微服务实现无损发布或无损上下线。

问题现象

您的应用在发布、重启等操作时,上游服务(发起调用的服务)可能会请求到正在停止的下游服务(被调用的服务),导致出现业务流量的错误(例如链接超时、业务报错等)。

问题原因

  • 下游服务在请求发起后才开始停止,导致请求不被响应。

  • 下游服务停止时,由于应用本身逻辑复杂,停止较慢,导致从注册中心注销服务较晚。

  • 下游服务正常停止,但上游服务因其他原因(例如网络故障、资源不足、处理逻辑异常等),没有及时处理和使用注册中心给予的新下游服务地址列表。

  • 使用了旧版本的客户端,由于机制问题移除下线的地址列表时效性较低。

解决方案

最佳方式为接入微服务治理的无损发布功能。无损发布功能提供一站式的无损发布及上下线服务,免去复杂的排查及解决过程。更多信息,请参见配置无损滚动发布

如果无法接入微服务治理的无损发布功能,则需要查看上游服务的Nacos客户端日志,在日志中检索下游服务的名字及关键字current ips,并比较下游服务的变更时间Nacos客户端日志信息的时间上游服务报错的时间

  • 若三者基本一致(即发起下游服务变更后,上游服务开始报错,但Nacos客户端日志信息出现后,上游服务报错停止),则说明程序正常,可使用下文的通用解决方案。更多信息,请参见通用解决方案

  • 下游服务的变更时间Nacos客户端日志信息的时间基本一致,但上游服务报错的时间始终未恢复,说明Nacos服务端正确推送了地址,且Nacos客户端也接收到了地址,但应用程序未使用。您可以按照如下方法进行排查。

    • 非开源框架使用者请检查应用自身逻辑,查看是否存在缓存机制且缓存更新出错。

    • 开源框架使用者可以到对应社区寻求帮助。

  • 下游服务的变更时间Nacos客户端日志信息的时间基本一致,但上游服务报错的时间恢复很慢,说明Nacos服务端正确推送了地址且Nacos客户端也接收到了地址,但应用程序未立刻使用,可以按照以下方法排查。

    1. 非开源框架使用者,请检查应用自身是否有缓存机制并且缓存更新存在延迟问题。

    2. 请检查是否使用ribbonfeignloadbalance等辅助框架,此类框架存在地址列表缓存且更新时间较慢,请根据对应框架修改缓存刷新配置。

    3. 其他开源框架使用者可以到对应社区寻求帮助。

    4. 若排查后仍无法解决,可使用下文的通用解决方案。更多信息,请参见通用解决方案

  • 下游服务的变更时间Nacos客户端日志信息的时间上游服务报错的时间相差较大,说明下游服务变更未被Nacos客户端感知到,可以按照以下方法排查。

    1. 将上游服务和下游服务的Nacos客户端升级至2.X及以上版本。

    2. 查看上游服务是否存在网络故障资源不足等问题。

    3. 排查下游服务停止时是否存在阻塞逻辑,导致应用无法响应请求但注册中心仍旧存在。

    4. 若排查后仍无法解决,可使用下文的通用解决方案。更多信息,请参见通用解决方案

通用解决方案

  1. 下游服务停止前, 需要使用Nacos更新实例OpenAPI修改enabled=false或在MSE控制台下线实例。随后通过监控、日志等手段,确认该下游服务节点已没有请求。更多信息,请参见OpenAPI下线应用实例

  2. 停止下游服务节点,执行变更。

  3. 确认变更下游服务节点完成,下游服务节点能够正确提供服务后,需要使用Nacos更新实例openAPI修改enabled=true或在MSE控制台上线实例。更多信息,请参见OpenAPI上线应用实例