对于任何一个线上应用,如何在服务更新部署过程中保证客户端无感知是开发者必须要解决的问题,即从应用停止到重启恢复服务这个阶段不能影响正常的业务请求。在应用执行部署、停止、回滚、缩容、重置时,需要通过无损下线的配置来保证应用正常关闭。
为什么需要无损下线
无损下线是为了保证从应用停止到恢复服务期间不影响正常运行的消费者的业务请求。理想条件下,在整个服务没有请求时再进行更新是安全可靠的。但实际情况下,无法保证在服务下线的同时没有任何调用请求。
传统的解决方式是通过将应用更新流程划分为手工摘除流量、停应用、更新重启三个步骤,由人工操作实现客户端对更新无感知。
如果在容器或框架级别提供某种自动化机制,自动进行摘除流量并确保处理完已到达的请求,不仅能保证业务不受更新影响,还可以极大地提升更新应用时的运维效率。该机制就是无损下线。
EDAS无损下线的优势
开源Dubbo可以通过shutdownHook和QoS实现,不仅有一定的开发工作量,而且对Dubbo有版本要求,还有一些遗留问题,最终影响正常使用。
EDAS将无损下线的流程整合在发布流程中,对ECS集群或K8s集群中的应用进行停止、部署、回滚、缩容、重置等操作时,无损下线会自动执行。您无需对应用或在EDAS控制台进行任何关于无损下线的操作,而且没有流量损失。
如何验证无损下线是否生效
您可以直接根据实际业务验证应用的无损下线是否已经生效。另外,EDAS也提供了两个应用Demo,您可以使用这两个Demo在容器服务K8s集群中验证EDAS的无损下线。
无损下线验证流程如下:
将应用Demo部署到容器服务K8s集群。
其中,Provider的实例个数为2,Consumer的实例个数为1。部署的详细操作步骤,请参见创建和部署应用概述(K8s)。
查看应用调用现状。
登录部署Consumer的Pod,执行以下命令不停地访问服务端的服务。
#!/usr/bin/env bash while true do echo `curl -s -XGET http://localhost:18091/user/rest` done
查看调用请求的响应。
从响应中可以看到,Consumer随机访问Provider的两个实例(IP为172.20.0.221和172.20.0.223)。
重要调用请求的响应窗口不要关闭,后续仍然会用到。
将Provider的实例缩容到1,模拟实例重启的场景。详情请参见应用生命周期管理(K8s)。
再次查看调用请求的响应结果,验证无损下线。
一直观察客户端请求情况,可以看到无损下线的情况,同时观察客户端日志,不存在任何相关问题,客户端完全无感知。
从响应中可以看到,Consumer会固定访问Provider剩余的一个实例(IP为172.20.0.221),而不会发生调用异常,避免影响Consumer。