共计 5209 个字符，预计需要花费 14 分钟才能阅读完成。
作者：十眠
“从一次常见的公布说起，在云上某个零碎利用公布时，重启阶段会导致较大数量的 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 中配置 curl http://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
