问题现象
当应用处于发布、重启等过程时，上游服务发起的请求可能转给正在停止的下游服务，导致出现业务报错（例如链接超时、业务报错等）。
问题原因
请求发起后下游服务处于停止过程中，导致请求不被响应。
下游服务停止耗时较长，导致从注册中心无法及时注销服务。
下游服务停止完毕后，但上游服务因某些原因没有及时接受和处理下游服务地址更新后的列表。
使用了旧版本的客户端，由于机制问题移除下线的地址列表时效性较低。
解决方案
（1） 最佳方式是接入服务治理的无损发布功能。
（2） 查看上游服务的Nacos客户端日志，在日志中检索下游服务的名字及关键字current ips，并比较下游服务的变更时间、Nacos客户端日志信息的时间及上游服务报错的时间。若三者基本一致（即发起下游服务变更后，上游服务开始报错，但Nacos客户端日志信息出现后，上游服务报错停止），则说明程序正常，可使用下文的通用解决方案。
（3） 如果下游服务的变更时间、Nacos客户端日志信息的时间基本一致，但上游服务报错的时间始终未恢复，说明Nacos服务端正确推送了地址，且Nacos客户端也接收到了地址，但应用程序未使用。您可以按照如下方法进行排查：
查看是否存在缓存机制且缓存更新出错。
开源框架使用者可以到对应社区寻求帮助。
（4） 若下游服务的变更时间、Nacos客户端日志信息的时间基本一致，但上游服务报错的时间恢复很慢，说明Nacos服务端正确推送了地址且Nacos客户端也接收到了地址，但应用程序未立刻使用，可以按照以下方法排查。
检查应用自身是否有缓存机制并且缓存更新存在延迟问题。
检查是否使用ribbon、feign、loadbalance等辅助框架，此类框架存在地址列表缓存且更新时间较慢，请根据对应框架修改缓存刷新配置。
若排查后仍无法解决，可使用下文的通用解决方案。更多信息，请参见通用解决方案。
（5） 若下游服务的若下游服务的下若下游服务的变更时间与Nacos客户端日志信息的时间、上游服务报错的时间相差较大，说明下游服务变更未被Nacos客户端感知到，可以按照以下方法排查。
将上游服务和下游服务的Nacos客户端升级至2.X及以上版本。
查看上游服务是否存在网络故障、资源不足等问题。
排查下游服务停止时是否存在阻塞逻辑，导致应用无法响应请求但注册中心仍旧存在。
若排查后仍无法解决，可使用下文的通用解决方案。更多信息，请参见通用解决方案。
通用解决方案
下游服务停止前， 需要使用Nacos更新实例OpenAPI修改enabled=false或在MSE控制台下线实例。随后通过监控、日志等手段，确认该下游服务节点已没有请求。。
停止下游服务节点，执行变更。
确认变更下游服务节点完成，下游服务节点能够正确提供服务后，需要使用Nacos更新实例openAPI修改enabled=true或在MSE控制台上线实例。更多信息，请参见OpenAPI和上线应用实例。