作者：十眠
“从一次常见的发布说起，在云上某个体系运用发布时，重启阶段会导致较大数量的 OpenAPI、上游事务的恳求响应时刻明显添加甚至超时失败。随着事务的开展，用户数和调用数越来越多，该体系又一向保持一周发布二次的高效迭代频率，发布期间对事务的影响越来越无法承受，微服务下线的管理也就越来越紧迫。”
云原生架构的开展给咱们微服务体系带来了自动的弹性弹性、翻滚晋级、分批发布等原生才能，让咱们享用到了资源、本钱、稳定性的最优解，但是在运用的缩容、发布等进程中，由于实例下线处理得不行优雅，将会导致短暂的服务不可用，短时刻内事务监控会呈现很多 io 异常报错；如果事务没做好事务，那么还会引起数据不一致的问题，那么需求紧迫手动修订过错数据；甚至每次发布，都需求发告示停机发布，咱们的用户会呈现一段时刻服务不可用。
微服务下线有损问题剖析
削减不必要的 API 报错，是最好的用户体会，也是最好的微服务开发体会。怎么处理这个在微服务领域内让人头疼的问题呢？在这之前咱们先来了解一下为什么咱们的微服务在下线的进程中会有或许呈现流量丢失。
如上图所示，是一个微服务节点下线的正常流程
- 下线前，顾客根据负载均衡规则调用服务供给者，事务正常。
- 服务供给者节点 A 准备下线，先对其中的一个节点进行操作，首先是触发中止 Java 进程信号。
- 节点中止进程中，服务供给者节点会向注册中心发送服务节点刊出的动作。
- 服务注册中心接收到服务供给者节点列表变更的信号后会，告诉顾客服务供给者列表中的节点已下线。
- 服务顾客收到新的服务供给者节点列表后，会改写客户端的地址列表缓存，然后根据新的地址列表从头核算路由与负载均衡。
- 终究，服务顾客不再调用已经下线的节点
微服务下线的流程虽然比较复杂，但整个流程仍是非常契合逻辑的，微服务架构是经过服务注册与发现完结的节点感知，天然也是经过这条路子完结节点下线变化的感知，整个流程没有什么问题。
参阅咱们这边给出的一些简单的实践数据，我想你的看法或许就会变得不同。从第 2 步到第 6 步的进程中，Eureka 在最差的情况下需求耗时 2 分钟，即便是 Nacos 在最差的情况下需求耗时 50 秒；在第 3 步中，Dubbo 3.0 之前的一切版别都是运用的是服务级别的注册与发现模型，意味着当事务量过大时，会引起注册中心压力大，假设每次注册/刊出动作需求花费 20～30ms，五六百个服务则需求注册/刊出花费掉近 15s 的时刻；在第 5 步中， Spring Cloud 运用的 Ribbon 负载均衡默许的地址缓存改写时刻是 30 秒一次，那么意味着及时客户端实时地从注册中心获取到下线节点的信号，仍旧会有一段时刻客户端会将恳求负载均衡至老的节点中。
如上图所示，只有到客户端感知到服务端下线而且运用最新的地址列表进行路由与负载均衡时，恳求才不会被负载均衡至下线的节点上。那么在节点开端下线的开端到恳求不再被打到下线的节点上的这段时刻内，事务恳求都有或许呈现问题，这段时刻咱们能够称之为服务调用报错期。
在微服务架构下，面临每秒上万次恳求的流量洪峰，即便服务调用报错期只有短短几秒，关于企业来说都是非常痛的影响。在一些更极端的情况下，服务调用报错期或许会恶化到数分钟，导致许多企业不敢发布，最后不得不每次发版都安排在凌晨两三点。关于研发来说每次发版都是心惊胆颤，苦不堪言。
无损下线技能
经过对微服务下线的流程剖析，咱们了解了处理微服务下线问题的关键便是：确保每一次微服务下线进程中，尽或许缩短服务调用报错期，一起确保待下线节点处理完任何发往该节点的恳求之后再下线。
那么怎么缩短服务调用报错期呢？咱们想到了一些战略：
- 将过程 3 即节点向注册中心履行服务下线的进程提前到过程 2 之前，即让服务刊出的告诉行为在运用下线前履行，考虑到 K8s 供给了 Prestop 接口，那么咱们就能够将该流程抽象出来，放到 K8s 的 Prestop 中进行触发。
- 如果注册中心才能不行，那么咱们是否有或许服务端在下线之前绕过注册中心直接告知客户端当时服务端节点下线的信号，该动作也能够放在 K8s 的 Prestop 接口中触发。
- 客户端在收到服务端告诉后，是否能够自动改写客户端的地址列表缓存。
怎么尽或许得确保服务端节点在处理完任何发往该节点的恳求之后再下线？站在服务端视角考虑，在告知了客户端下线的信号后，是否能够供给一种等候机制，确保一切的在途恳求以及服务端正在处理的恳求被处理完结之后再进行下线流程。
如上图所示，咱们经过以上这些战略能够确保服务顾客端尽或许早实时地感知到服务供给者节点下线的行为，一起服务供给者会确保一切在途恳求以及处理中的恳求处理完结之后，再进行服务下线。这些主意看起来没什么问题，接下来看一下咱们是怎么在 Spring Cloud 跟 Dubbo 服务结构中完结的。
首先咱们需求在服务供给者进程中内置一个 HttpServer 向外暴露 /offline 接口，用于承受自动刊出的告诉。咱们能够在 K8s 的 Prestop 中装备 curlhttp://localhost:20001/offline触发自动刊出接口。该接口收到 offline 指令后，经过触发调用注册中心中下线实例的接口或者经过调用微服务程序中的 ServiceRegistration.stop 接口履行服务刊出动作，使得咱们在中止微服务之前完结向注册中心进行节点地址的下线动作。
咱们在 Prestop 接口中还要完结一个才能便是自动告诉的才能。在 Dubbo 结构中是比较好完结的，由于 Dubbo 自身便是长衔接的模型，咱们能够发现 Dubbo 在服务供给者中保护了与一切服务顾客衔接的 Channel 调集，在收到 offline 指令后，向一切保护中的 Channel 发送一个 ReadOnly 信号，标记该 Channel 为只读状况，Dubbo 的顾客收到 ReadOnly 信号后，将不再往该服务供给者发送恳求，然后完结自动告诉的作用。关于 Spring Cloud 结构而言完结思路也是类似的，由于 Spring Cloud 调用的恳求是没有 Channel 的模型，因此咱们在收到 offline 指令后，咱们在恳求的 Response Header 中带上 ReadOnly 标签，服务顾客收到 ReadOnly 标签后，会自动改写负载均衡 Ribbon 缓存，确保不再有新的恳求拜访下线进程中的服务供给者。
咱们服务供给者端需求等候一切在途恳求处理完结之后，再进行运用中止流程。由于事务的不确定性，恳求处理时长是不确定的，那么服务供给者端需求等候多久才能够等到一切在途恳求处理完结呢？为了处理这个问题，咱们设计了一种自适应等候的战略。咱们让运用在下线前会有一段自适应等候的时期，咱们对一切进入服务供给者以及调用完结的流量进行计算与核算。在这个进程中运用会一向等候，直到运用处理完结一切流向当时运用的流量之后再进行停机下线流程。
经过服务提前刊出、自动告诉以及自适应等候这三种战略，咱们完结了微服务无损下线的才能。然后避免微服务节点下线进程中存在较长的服务报错期，处理了发布进程中事务流量丢失的问题。
大规模下无损下线实践
到目前为止，以上的一系列处理思路与战略都看起来非常的完美，但是当咱们面临云上客户时，特别是在面临大规模的微服务场景下，无损下线计划在落地的进程中仍旧碰到了许多问题。云上某客户生产环境的 Spring Cloud 运用在接入咱们的计划之后，发布的进程中仍旧呈现了很多的过错ErrorCode: ServiceUnavailable。咱们跟客户一起剖析排查之后，咱们定位到问题的根因是有些 Consumer 没能及时收到 Provider 的下线告诉，即便服务端节点已经下线了，仍旧有流量拜访下线的服务端节点。在大规模之下，注册中心的告诉及时性是不能确保的，咱们还意识到 “在收到 offline 指令后，咱们能够在收到恳求的返回值中带上 ReadOnly 标签” 这个方法的及时性也不能确保，特别是在QPS不大、RT较长、运用的节点数量过多的情况下，有许多 Consumer 是没能收到 Provider 下线告诉的。咱们排查了各个 Consumer 节点收到 ReadOnly 标签的日志，发现确实有不少 Consumer 没有日志记录，证明了咱们的怀疑。
自动告诉
为了处理大规模实践中的问题，咱们必须有一种愈加实时牢靠的自动告诉计划。考虑到 Spring Cloud 调用的恳求是没有 Channel 的模型，那么咱们就需求在 Spring Cloud 服务供给者端保护最近一段时刻内调用过该实例的服务顾客地址列表。在收到 offline 指令后，服务供给者将会遍历缓存在内存中的服务顾客地址列表，并对每一个 Consumer 建议一次 GoAway 的 Http 调用。当然咱们需求在服务顾客对外暴露的 HttpServer 中添加接收 GoAway 告诉的接口。当服务顾客收到调用后，服务顾客会自动改写当时节点的负载均衡 Ribbon 缓存，而且在流量路由的进程中隔离掉发送 GoAway 恳求的 Provider 节点，这样当时服务顾客就不会再向对应的 Provider 节点建议恳求。当 Provider 对每一个 Consumer 节点进行 GoAway 调用后，则表示该服务供给者已经将“下线中”的信号告诉至一切活泼的顾客，经过这个方法咱们完结了大规模下相对牢靠的自动告诉的才能。
可观测性建造
无损下线的流程非常复杂，一起还涉及到多个节点之间的告诉机制，特别是在大规模之下，下线流程的完整性以及牢靠性的承认变得非常复杂与繁琐。咱们需求一种完善的可观测才能，协助咱们观测下线的流程有无任何问题。当呈现问题的时候，需求可观测才能协助咱们快速定位问题以及根因。
怎么判断咱们每次发布运用的无损下线是否生效？
最直观的方法那便是看事务的流量，咱们需求站在 Provider 视角上看事务流量是否在 Provider 下线前中止，而且在这个进程中事务流量没有丢失。想到这一块，那咱们就应该供给 Provider 节点的流量情况，而且需求相关无损下线的事情。这样就能够直观地看到先是触发了无损下线，在没有事务流量之后再中止运用的完整无损下线流程。
- Metrics 流量视图
咱们凭借可观测 Metrics 才能，关于每个 Pod 的事务流量进行计算与展示，一起在流量履行的进程中相关无损下线事情，这样就能够直观地看到到微服务节点下线进程有无问题，一望而知。
怎么判断无损下线的流程履行契合咱们的预期？
依照咱们自动告诉的逻辑，咱们微服务节点下线进程中，需求对每一个 Consumer 节点进行 GoAway 调用。设想一下，在大规模场景下，假设当时运用有 5 个顾客运用，且每个运用有 50 个节点，那么咱们怎么确保 GoAway 告诉到了这 250 个 Consumer 中的每一个 Consumer ？无损下线流程自身就非常复杂，特别在大规模场景下，无损下线可观测问题的复杂度急剧上升。咱们想到能够凭借 Tracing 才能提高无损下线的可观测才能。
- 依赖 Tracing 的无损下线可观测新思路
如上图该场景，咱们对 108 节点进行缩容操作，咱们就能够得到一条 Tracing 链路，其中包括自动告诉、服务刊出、运用中止等几个过程，而且咱们能够在每个过程中看到所需的信息。
在自动告诉环节咱们能够看到当时 Provider 节点对哪些 Consumer 进行 GoAway 恳求的调用，如下图所示咱们将自动告诉 10.0.0.90、10.0.0.176 两个 Consumer 节点。
当 Consumer 收到 GoAway 调用后，会进行负载均衡列表的改写以及路由的隔离，咱们将在负载均衡地址列表中显现最新抓到的当时 Consumer 关于当时服务缓存的最新地址列表，咱们能够在下图中看到，地址列表中只剩下 10.0.0.204 这个服务供给者节点的调用地址。
咱们也能够看到 Spring Cloud 向 Nacos（注册中心）履行服务下线的调用成果，刊出成功。
咱们发现经过将无损下线的 workflow 抽象成 Tracing 结构的战略，能够协助咱们下降大规模场景、复杂链路下无损下线问题的排查本钱，协助咱们更好地处理大规模下微服务下线时流量无损的问题。
总结
软件迭代进程中，除了风险控制，在微服务领域还有一个常见的问题便是运用上下线进程中的流量管理，目的也比较明确，确保运用在发布、扩缩容、重启等场景时，不会丢失任何事务流量丢失。无损下线技能正是在这样的布景下应运而生的，他处理了变更进程中的事务流量丢失问题，也是流量管理体系中非常重要的一个环节。无损下线功用有效地确保咱们事务流量的平滑，提高了微服务开发的幸福度。
MSE 无损下线功用也随着客户场景的丰富在不断演进与完善。值得一提的是，咱们在实践微服务管理的进程中开源了 OpenSergo 这个项目，旨在推进微服务管理从生产实践走向标准。欢迎感兴趣的同学们一起参与讨论与共建，一起来界说微服务管理的未来。
怎么联络咱们，欢迎参加 OpenSergo 钉钉交流群：34826335
