如何验证无损下线生效 - 企业级分布式应用服务 EDAS

对于任何一个线上应用，重启、下线等操作不可避免，无损下线能够实现服务消费者无感知，保持业务连续无损。您无需对应用进行任何配置、也无需在EDAS控制台进行任何操作，EDAS默认支持Spring Cloud应用无损下线。

为什么需要无损下线

无损下线是为了保证从应用停止到恢复服务期间不影响正常运行的消费者的业务请求。理想条件下，在整个服务没有请求时再进行更新是安全可靠的。但实际情况下，无法保证在服务下线的同时没有任何调用请求。

传统的解决方式是通过将应用更新流程划分为手工摘除流量、停应用、更新重启三个步骤，由人工操作实现客户端对更新无感知。

如果在容器或框架级别提供某种自动化机制，自动进行摘除流量并确保处理完已到达的请求，不仅能保证业务不受更新影响，还可以极大地提升更新应用时的运维效率。该机制就是无损下线。

开源Spring Cloud可以通过shutdownHook、Spring Boot Actuator和Ribbon实现，不仅有一定的开发工作量，而且部分注册中心会导致短暂的流量损失。

EDAS将无损下线的流程整合在发布流程中，对应用进行停止、部署、回滚、缩容、重置等操作时，无损下线会自动执行。相对于开源的方案，EDAS无损下线具有以下优势：

分类	开源Spring Cloud	EDAS
版本	使用ServiceRegistryEndpoint，需要依赖Actuator组件，且需要升级到适配的版本。	无需任何操作，无侵入地支持Spring Cloud Dalston及以上版本。
注册中心和流量损失	依赖注册中心，有些注册中心会导致流量损失。 ZooKeeper不存在流量损失。 Eureka存在3s流量损失。 Nacos存在客户端缓存，会造成最长10s的流量损失。	无需依赖任何注册中心，对于任何注册均不存在流量损失。
场景	ECS场景需结合变更详情。 K8s场景可以配合prestop接口，但是prestop接口只能配置一个动作。	ECS和K8s全部覆盖，且不影响对应用的任何操作与配置。
客户端缓存	需要权衡利弊配置合理的Ribbon缓存的刷新时间，过长会导致下线有流量损失，过短会影响性能。	增强Ribbon下线刷新机制，通过反应式响应方式主动刷新Ribbon缓存。您无需关心缓存刷新。

您可以直接根据实际业务验证应用的无损下线是否已经生效。另外，EDAS也提供了两个应用Demo，您可以使用这两个Demo在容器服务K8s集群中验证EDAS的无损下线。

无损下线验证流程如下：

下载应用Demo（Provider和Consumer）。
将应用Demo部署到容器服务K8s集群。
其中，Provider的实例个数为2，Consumer的实例个数为1。部署的详细操作步骤，请参见创建和部署应用概述（K8s）。
查看应用调用现状。
1. 登录部署Consumer的Pod，执行以下命令不停地访问服务端的服务。
```
#!/usr/bin/env bash
while true
do
    echo `curl -s -XGET http://localhost:18091/user/rest`
done
```
2. 查看调用请求的响应。
  从响应中可以看到，Consumer随机访问Provider的两个实例（IP为172.20.0.221和172.20.0.223）。
  重要
  调用请求的响应窗口不要关闭，后续仍然会用到。
将Provider的实例缩容到1，模拟实例重启的场景。详情请参见应用生命周期管理（K8s）。
再次查看调用请求的响应结果，验证无损下线。
一直观察客户端请求情况，可以看到无损下线的情况，同时观察客户端日志，不存在任何相关问题，客户端完全无感知。
从响应中可以看到，Consumer会固定访问Provider剩余的一个实例（IP为172.20.0.221），而不会发生调用异常，避免影响Consumer。