Serverless 国外代理服务器( 二 ) _云知道

开发态实践：端云联调

Serverless 应用引擎（SAE）基于 Alibaba CloudToolkit 插件+ 跳板机可以实现：
本地服务订阅并注册到云端 SAE内置的注册中心；本地服务可以和云端 SAE 服务互相调用。在实现的时候用户需要有一个 ECS 代理服务器，实际注册的是 ECS 代理服务器到 SAE 的注册中心，IDEA 在安装 Cloudtoolkit 插件以后，在启动进程时，会在本地拉起一个通道服务，这个通道服务会连上 ECS 代理服务器，本地所有的请求都会转到 ECS 代理服务器上，云端对服务的调用也会通过 ECS 代理转到本地，这样就可以以最新的代码在本地断点调试，这就是云端联调的实现。
发布态实践：无损下线在版本更换的过程中，SAE 是如何保证旧版本的微服务流量可以无损地下线掉？

上图是微服务注册和发行的整个流程，图中有服务消费者和服务提供者，服务提供者分别有 B1、B2 两台实例，服务消费者分别有 A1、A2 两台实例。
B1、B2 把自己注册到注册中心，消费者从注册中心刷新服务列表，发现服务提供者 B1、B2，正常情况下，消费者开始调用 B1 或者 B2，服务提供者 B 需要发布新版本，先对其中一个节点进行操作，如 B1，首先停止 Java 进程，服务停止过程又分为主动销毁和被动销毁，主动销毁是准实时的，被动销毁的时间由不同的注册中心决定，最差的情况可能需要一分钟。如果应用是正常停止，Spring Cloud 和 Dubbo 框架的 ShutdownHook 能正常被执行，这一步的耗时基本上是可以忽略不计的。
如果应用是非正常停止，比如说直接 Kill-9 的一个停止，或者是 Docker 镜像构建的时候，Java 进程不是一号进程，且没有把 Kill 信号传递给应用的话，那么服务提供者不会主动去注销节点，它会等待注册中心去发现、被动地去感知服务下线的过程。
当微服务注册中心感知到服务下线以后，会通知服务消费者其中一个服务节点已下线，这里有两种方式：注册中心的推送和消费者的轮巡。注册中心刷新服务列表，感知到提供者已经下线一个节点，这一步对于 Dubbo 框架来说不存在，但对于 Spring Cloud 来说，它最差的刷新时间是 30 秒。等消费者的服务列表更新以后，就不再调用下线节点 B 。从第 2 步到第 6 步的过程中，注册中心如果是 Eureka，最差的情况需要消耗两分钟；如果是 Nacos，最差的情况需要消耗 50 秒。
在这个时间内请求都有可能出现问题，所以发布的时候会出现各种报错。

经过上面的分析，在传统的发布流程中，客户端有一个服务端调用报错期，这是由于客户端没有及时感知到服务端下线的实例造成的，这种情况主要是因为服务提供者借助微服务，通知消费者来更新服务提供的列表造成的。

那能否绕过注册中心，服务提供者直接通知服务消费者？答案是肯定的。SAE 做了两件事情，第一，服务提供者在应用发布前，会主动向服务注册中心注销应用，并将应用标记为已下线状态，将原来停止进程阶段的注销变成了 preStop 阶段注销进程。
在接收到服务消费者的请求时，首先会正常处理本次请求，并且通知服务消费者此节点已经下线，在此之后消费者收到通知后，会立即刷新自己的服务列表，在此之后服务消费者就不会再把请求发到服务提供者 B1 的实例上。