15 分钟实现企业级应用无损上下线

很多用户量大并发度高的应用系统为了避免发布过程中的流量有损，一般选择在流量较小的半夜发布，虽然这样做有效果，但不可控导致背后的研发运维成本对企业来说是一笔不小的负担。基于此，阿里云微服务引擎 MSE 在应用发布过程中，通过应用下线时进行自适应等待+主动通知，应用上线时就绪检查与微服务生命周期对齐+服务预热等技术手段所提供的微服务应用无损上下线功能，能有效帮助企业规避线上发布所出现的流量资损。

无损上下线功能设计

常见的流量有损现象出现的原因包括但不限于以下几种：

• 服务无法及时下线：服务消费者感知注册中心服务列表存在延时，导致应用下线后在一段时间内服务消费者仍然调用已下线应用造成请求报错。
• 初始化慢：应用刚启动接收线上流量进行资源初始化加载，由于流量太大，初始化过程慢，出现大量请求响应超时、阻塞、资源耗尽从而造成刚启动应用宕机。
• 注册太早：服务存在异步资源加载问题，当服务还未初始化完全就被注册到注册中心，导致调用时资源未加载完毕出现请求响应慢、调用超时报错等现象。
• 发布态与运行态未对齐：使用 Kubernetes 的滚动发布功能进行应用发布，由于Kubernetes 的滚动发布一般关联的就绪检查机制，是通过检查应用特定端口是否启动作为应用就绪的标志来触发下一批次的实例发布，但在微服务应用中只有当应用完成了服务注册才可对外提供服务调用。因此某些情况下会出现新应用还未注册到注册中心，老应用实例就被下线，导致无服务可用。

无损下线

其中的服务无法及时下线问题，如下图 1 所示：

图1. Spring Cloud 应用消费者无法及时感知提供者服务下线

对于 Spring Cloud 应用，当应用的两个实例 A’ 和 A 中的 A 下线时，由于 Spring Cloud 框架为了在可用性和性能方面做平衡，消费者默认是 30s 去注册中心拉取最新的服务列表，因此 A 实例的下线不能被实时感知，此时消费者继续通过本地缓存继续调用 A 就会出现调用已下线实例出现流量有损。

针对该问题，阿里云微服务引擎 MSE 基于 Java Agent 字节码技术设计实现的无损下线功能如下图 2 所示：

图2. 无损下线方案

在该套无损下线方案中，服务提供者应用仅需接入 MSE，相比一般的有损下线。应用在下线前会有一段自适应等待时期，该时期待下线应用会通过主动通知的方式，向其在自适应等待阶段发送了请求的服务消费者发送下线事件，消费者接收到下线事件后会主动拉取注册中心服务实例列表以便实时感知应用下线事件避免调用已下线实例造成应用下线流量有损。

无损上线

延迟加载是软件框架设计中最常见的一种策略，例如在 Spring Cloud 框架中 Ribbon 组件的拉取服务列表初始化时机默认是要等到服务的第 1 次调用时刻，例如下图 3 是 Spring Cloud 应用中第 1 次和第 2 次通过 RestTemplate 调用远程服务的请求耗时情况：

图3. 应用启动资源初始化与正常运行过程中耗时情况对比

由测试结果可见，第一次调用由于进行了一些资源初始化，耗时是正常情况的数倍之多。因此把新应用发布到线上直接处理大流量极易出现大量请求响应慢，资源阻塞，应用实例宕机的现象。针对该类大流量下应用资源初始化慢问题，MSE 提供的小流量预热功能通过调节刚上线应用所分配的流量帮助其在进行充分预热后再处理正常流量从而对新实例进行保护。小流量预热过程如下图 4 所示：

图4. 小流量服务预热过程 QPS 与启动时间关系图

除了针对上述应用第一次调用初始化慢所造成的有损上线问题，MSE 还提供了资源预建连接、延迟注册、确保 Kubernetes 就绪检查通过前完成服务注册和确保 Kubernetes 就绪检查通过前完成服务预热等一整套无损上线手段来满足各类不同应用的无损上线需求，整套方案如图 5 所示：

图5. MSE 无损上线方案

如何使用 MSE 的无损上下线

接下来将演示阿里云微服务引擎 MSE 在应用发布时提供的无损上下线和服务预热能力最佳实践。假设应用的架构由 Zuul 网关以及后端的微服务应用实例（Spring Cloud）构成。具体的后端调用链路有购物车应用 A，交易中心应用 B，库存中心应用 C，这些应用中的服务之间通过 Nacos 注册中心实现服务注册与发现。

前提条件

开启 MSE 微服务治理

• 已创建 Kubernetes 集群，请参见创建 Kubernetes 托管版集群[1]。
• 已开通 MSE 微服务治理专业版，请参见开通 MSE 微服务治理[2]。

准备工作

注意，本实践所使用的 Agent 目前还在灰度中，需要对应用 Agent 进行灰度升级，升级文档：