解决微服务架构下流量有损问题的实践和探索

绝⼤多数的软件应⽤⽣产安全事故发⽣在应⽤上下线发布阶段，尽管通过遵守业界约定俗成的可灰度、可观测和可滚回的安全⽣产三板斧，可以最⼤限度的规避发布过程中由于应⽤⾃身代码问题对⽤户造成的影响。但对于⾼并发⼤流量情况下的短时间流量有损问题却仍然⽆法解决。因此，本文将围绕发布过程中如何解决流量有损问题实现应⽤发布过程中的⽆损上下线效果相关内容展开⽅案介绍。

无损上下线背景

据统计，应⽤的事故⼤多发⽣在应⽤上下线过程中，有时是应⽤本身代码问题导致。但有时我们也会发现尽管代码本身没有问题，但在应⽤上下线发布过程中仍然会出现短时间的服务调⽤报错，⽐如调⽤时出现Connection refused和No instance等现象。相关问题的原因有相关发布经历的同学或多或少可能有⼀定了解，⽽且⼤家发现该类问题⼀般在流量⾼峰时刻尤为明显，半夜流量少的时候就⽐较少见，于是很多⼈便选择半夜三更进⾏应⽤发布希望以此来规避线上发布事故。本节将就这些问题出现的背后真实原因以及业界对应的设计⽅案展开介绍。常见的流量有损现象出现的原因包括但不限于以下⼏种：

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

接下来，将就具体的下线和上线过程中如何避免流量损耗问题进⾏分别介绍。

无损下线

由于微服务应用自身调用特点，在高并发下，服务提供端应用实例的直接下线，会导致服务消费端应用实例无法实时感知下游实例的实时状态因而出现继续将请求转发到已下线的实例从而出现请求报错，流量有损。

例如对于Spring Cloud应⽤如上图1所示，当应⽤的两个实例A’和A中的A下线时，由于
Spring Cloud框架为了在可⽤性和性能⽅⾯做平衡，消费者默认是30s去注册中⼼拉取最新的服务列表，因此A实例的下线不能被实时感知，流量较⼤时，消费者会继续通过本地缓存调⽤已下线的A实例导致出现流量有损。基于上述背景，业界提出了相应的⽆损下线（也叫优雅下线&#x