对于任何一个线上应用，在服务更新部署过程中，需要尽量保证客户端无感知，即从应用停止到重启恢复服务这个阶段不能影响正常的业务请求。在应用执行部署、停止、回滚、缩容、重置时，需要通过无损下线的配置来保证应用正常关闭。

视频教程

为什么需要无损下线

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

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

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

MSE治理中心无损下线的优势

开源Dubbo可以通过shutdownHook和QoS实现无损下线，不仅有一定的开发工作量，而且对Dubbo有版本要求，还有一些遗留问题，最终影响正常使用。

MSE治理中心将无损下线的流程整合在发布流程中，对ECS集群或K8s集群中的应用进行停止、部署、回滚、缩容、重置等操作时，无损下线会自动执行。您无需对应用或在MSE治理中心控制台进行任何关于无损下线的操作，而且没有流量损失。

如何验证无损下线是否生效

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

无损下线验证流程如下：

  1. 下载应用Demo（Provider和Consumer）。
  2. 将应用Demo部署到容器服务K8s集群。相关操作，请参见创建无状态工作负载Deployment。
    其中，Provider的实例个数为2，Consumer的实例个数为1。
  3. 查看应用调用现状。
    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）。

      注意 调用请求的响应窗口不要关闭，后续仍然会用到。
  4. 将Provider的实例缩容到1，模拟实例重启的场景。
  5. 再次查看调用请求的响应结果，验证无损下线。
    调用请求响应-无损下线

    一直观察客户端请求情况，可以看到无损下线的情况，同时观察客户端日志，不存在任何相关问题，客户端完全无感知。

    从响应中可以看到，Consumer会固定访问Provider剩余的一个实例（IP为172.20.0.221），而不会发生调用异常，避免影响Consumer。