怎么理解SAE 东西向流量优雅升级方案？

东西向流量，传统的发布流程中，服务 提供者停止再启动，服务消费者感知到服务提供者节点停止的流程如下： 服务发布前，消费者根据负载均衡规则调用服务提供者，业务正常。  服务提供者 B 需要发布新版本，先对其中的一个节点进行操作，首先是停止 java 进程。  服务停止过程，又分为主动注销和被动注销，主动注销是准实时的，被动注销的时间由 不同的注册中心决定，最差的情况会需要 1 分钟。  如果应用是正常停止，Spring Cloud 和 Dubbo 框架的 Shutdown Hook 能 正常被执行，这一步的耗时可以忽略不计。 如果应用是非正常停止，比如直接使用 kill -9 停止，或者 Docker 镜像构建的 时候 java 应用不是 1 号进程且没有把 kill 信号传递给应用。那么服务提供者不 会主动去注销服务节点，而是在超过一段时间后由于心跳超时而被动地被注册中心 摘除。  服务注册中心通知消费者，其中的一个服务提供者节点已下线。包含推送和轮询两种方 式，推送可以认为是准实时的，轮询的耗时由服务消费者轮询间隔决定，最差的情况下 需要 1 分钟。  服务消费者刷新服务列表，感知到服务提供者已经下线了一个节点，这一步对于 Dubbo 框架来说不存在，但是 Spring Cloud 的负载均衡组件 Ribbon 默认的刷新 时间是 30 秒 ，最差情况下需要耗时 30 秒。  服务消费者不再调用已经下线的节点。 从第 2 步到第 6 步的过程中，Eureka 在最差的情况下需要耗时 2 分钟，Nacos 在最差的情况下需要耗时 50 秒。在这段时间内，请求都有可能出现问题，所以发布时会 出现各种报错，同时还影响用户的体验，发布后又需要修复执行到一半的脏数据。最后不得 不每次发版都安排在凌晨两三点发布，心惊胆颤，睡眠不足，苦不堪言。2. 东西向流量优雅升级方案是指在传统发布流程中，客户端有一个服务调用报错期，原因就 是客户端没有及时感知到服务端下线的实例。在传统发布流程中，主要是借助注册中心通知 消费者来更新服务提供者列表，那能不能绕过注册中心，服务提供者直接通知服务消费者 呢？答案是肯定的，我们主要做了两件事情： 服务提供者应用在发布前后主动向注册中心注销应用，并将应用标记为已下线的状态； 将原来的停止进程阶段注销服务变成了 prestop 阶段注销服务。  在接收到服务消费者请求时，首先会正常处理本次调用，并通知服务消费者此节点已下 线，服务消费者会立即从调用列表删除此节点；在这之后，服务消费者不再调用已经下 线的节点。这是将原来的依赖于 注册中心推送，做到了服务提供者直接通知消费者从 调用列表中摘除自己。 通过上面这个方案，就使得下线感知的时间大大减短，从原来的分钟级别做到准实时， 确保应用在下线时能做到业务无损。