简介：在分布式场景下，微服务过程都是以容器的模式存在，在容器调度零碎例如 k8s 的反对下运行，容器组 Pod 是 K8S 的最小资源单位。随着服务的迭代和更新，当新版本上线后，须要针对线上正在运行的服务进行替换，从而公布新版本。
作者 | 李志信
起源 | 阿里技术公众号
一 背景
1 优雅高低线
在分布式场景下，微服务过程都是以容器的模式存在，在容器调度零碎例如 k8s 的反对下运行，容器组 Pod 是 K8S 的最小资源单位。随着服务的迭代和更新，当新版本上线后，须要针对线上正在运行的服务进行替换，从而公布新版本。
在稳固生产的过程中，容器调度齐全由 k8s 管控，微服务治理由服务框架或者运维人员进行保护和治理。而在公布新版本，或者扩缩容的场景下，会终止旧的容器实例，并应用新的容器实例进行替换，对于承载高流量的线上生产环境，这个替换过程的连接一但呈现问题，将在短时间内造成大量的谬误申请，触发报警甚至影响失常业务。对于体量较大的厂家，公布过程呈现问题所造成的损失会是微小的。
因而，优雅高低线的诉求被提出。这要求服务框架在领有稳固服务调用能力，传统服务治理能力的根底之上，该当提供服务高低线过程中稳固的保障，从而缩小运维老本，进步利用稳定性。
2 冀望成果
我认为，现实状态下优雅高低线的成果，是在一个承载大量流量的分布式系统内，所有组件实例都能够随便地扩容、缩容、滚动更新，在这种状况下须要保障更新过程中稳固的 tps（每秒申请数）和 rt（申请时延），并且保障不因为高低线造成申请谬误。再深一步，就是零碎的容灾能力，在一个或多个节点不可用的状况下，能保障流量的正当调度，从而尽最大能力缩小谬误申请的呈现。
Dubbo-go 的优雅高低线能力
Dubbo-go 对优雅高低线的探索能够追溯到三年前，早在 1.5 晚期版本，Dubbo-go 就曾经领有优雅下线能力。通过对终止信号量的监听，实现反注册、端口开释等善后工作，摘除流量，保障客户端申请的正确响应。
在前一段时间，随着 Dubbo-go 3.0 的正式发版，我在一条 proposal issue (dubbo-go issue 1685) [1] 中提到了一些生产用户比拟看重的问题，作为 3.x 版本的发力方向，并邀请大家议论对这些方向的认识，其中用户呼声最高的个性就是无损高低线的能力，再次感激社区的王晓伟同学的奉献。
通过不断完善和生产环境测试，目前 Dubbo-go 已领有该能力，将在后续版本中正式与大家见面。
二 Dubbo-go 优雅高低线实现思路
优雅高低线能够分为三个角度。服务端的上线，服务端的下线，和客户端的容灾策略。这三个角度，保障了生产实例在失常的公布迭代中，不呈现谬误申请。
1 客户端负载平衡机制
以 Apache 顶级我的项目 Dubbo 为榜样的微服务架构在这里就不进行赘述，在分布式场景下，即便在 K8S 内，大多数用户也会应用第三方注册组件提供的服务发现能力。站在运维老本、稳定性、以及分层解耦等角度，除非一些非凡状况，很少会间接应用原生 Service 进行服务发现和负载平衡，因而这些能力成为了微服务框架的标配能力。
相熟 Dubbo 的同学肯定理解过，Dubbo 反对多种负载平衡算法，通过可扩大机制集成到框架内。Dubbo-go 亦是如此，针对多实例场景下，能够反对多种负载平衡算法，例如 RR，随机数，柔性负载平衡等等。
下图摘自 Dubbo 官网
Dubbo-go 的负载平衡组件
Dubbo-go 服务框架领有一套接口级扩大机制，能够依据配置，加载同一组件接口的不同的实现。其中就有随机算法负载平衡策略，它是 Dubbo-go 默认的负载平衡算法。在应用这种算法进行负载平衡的状况下，所有 provider 都会依据肯定的权重策略被随机抉择。所有的 provider 实例都有可能成为上游。
这种较为传统的负载平衡算法会带来隐患，即不会因为之前调用的后果，影响到后续调用过程中对上游实例的抉择。因而如果有局部上游实例处在高低线阶段，造成短暂的服务不可用，所有随机到该实例的申请均会报错，在高流量的场景下，会造成巨大损失。
集群重试策略
下图摘自 Dubbo 官网
Dubbo-go 的集群重试策略是从 Dubbo 借鉴过去的，默认应用 Failover（故障转移）逻辑，当然也有 failback，fallfast 等策略，也是依附了组件可扩大能力集成进框架内。
无论是下面提到的负载平衡，还是重试逻辑，都是基于“面向切面编程“的思路，结构一个抽象化 invoker 的实现，从而将流量层层向上游传递。对于 Failover 策略，会在负载平衡抉择上游实例的根底上，减少对谬误申请的重试逻辑。一旦申请报错，会抉择下一个 invoker 进行尝试，直到申请胜利，或超过最大申请次数为止。
集群重试策略只是减少了尝试的次数，升高了错误率，但实质上还是无状态的，当上游服务不可用时，会造成灾难性的结果。
黑名单机制
黑名单机制是我去年实习，师兄安顿做的第一个需要，大抵思路很简略，将申请抛错的 invoker 对应实例的 ip 地址退出黑名单，后续不再将流量导入该实例，等过一段时间，尝试申请它，如果胜利就从黑名单中删除。
这个机制实现逻辑非常简单，但实质上是将无状态负载平衡算法降级为了有状态的。对于一个不可用的上游实例，一次申请会疾速将该实例拉黑，其余申请就会辨认出黑名单内存在该实例，从而防止了其余的流量。
对于这种策略，在黑名单中保留的超时、尝试从黑名单移除的策略等，这些变量都该当联合具体场景思考，实质上就是一个有状态的故障转移策略。普适性较强。
P2C 柔性负载平衡算法
柔性负载平衡算法是 Dubbo3 生态的一个重要个性，Dubbo-go 社区正在携手 Dubbo 一起摸索和实际。一些读者应该在之前 Dubbo-go 3.0 公布的文章中看过相干介绍。简略来说，是一个有状态的，不像黑名单那么“一刀切”的，思考变量更宽泛、更全面的一种负载平衡策略，会在 P2C 算法的根底之上，思考各个上游实例的申请时延、机器资源性能等变量，通过肯定策略来确定哪个上游实例最合适，而具体策略，将联合具体利用场景，交由感兴趣的社区成员来摸索，目前是来自字节的牛学蔚(github@justxuewei) 在负责。
上述诸多负载平衡策略，都是站在客户端的角度，尽最大能力让申请拜访至在衰弱的实例上。在无损高低线角度来思考，对于处于公布阶段的不失常工作的实例，能够由客户端通过正当的算法和策略，例如黑名单机制来过滤掉。
我认为客户端负载平衡是通用能力，对无损高低线场景的作用只是精益求精，并不是的外围因素。究其实质，还是要从被“高低线”的服务端实例来思考，从而解决基本问题。
2 服务端优雅上线逻辑
相较于客户端，服务端作为服务的提供者、用户业务逻辑的实体，在咱们探讨的场景下逻辑较为简单。在探讨服务端之前，咱们还是先重温一下根底的服务调用模型。
传统服务调用模型
参考 Dubbo 官网给出的架构图，实现一次服务调用，个别须要三个组件：注册核心，服务端，客户端。
- 服务端首先须要裸露服务，监听端口，从而具备承受申请的能力。
- 服务端将以后服务信息例如 ip 和端口，注册在中心化的注册核心上，例如 Nacos。
- 客户端拜访注册核心，获取要调用的服务 ip 和端口，实现服务发现。
- 服务调用，客户端针对对应 ip 和端口进行申请。
这简略的四个步骤，就是 Dubbo-go 优雅高低线策略的外围关注点。失常状况下，四个步骤依此执行下来十分顺利，逻辑也十分清晰。而放在一个大规模的生产集群内，在服务高低线时就会呈现很多值得考量的细节。
咱们要明确，高低线过程中的谬误是怎么产生的？咱们只须要关注两个谬误，就是：“一个申请被发送给了一个不衰弱的实例”，以及“正在解决申请的过程被杀死”，高低线过程中简直所有的谬误都是来自于他们。
服务优雅上线逻辑细节
服务上线时，依照上述的步骤，首先要裸露服务，监听端口。在保障服务提供者能够失常提供服务之后，再将本身信息注册在注册核心上，从而会有来自客户端的流量发送至本人的 ip。这个程序肯定不能乱，否则将会呈现服务没有筹备好，就收到了申请的状况，造成谬误。
下面所说的只是简略的状况。在实在场景下，咱们所说的一个服务端实例，往往蕴含一组相互依赖的客户端和服务端。在 Dubbo 生态的配置中，被称为 Service（服务）和 Reference（援用）。
举一个业务同学十分相熟的例子，在一个服务函数内，会执行一些业务逻辑，并且针对多个上游服务发动调用，这些上游可能蕴含数据库、缓存、或者其余服务提供者，执行结束后，返回取得的后果。这对应到 Dubbo 生态的概念中，其实现就是：Service 负责监听端口和承受申请，承受的申请会向下层转发至利用业务代码，而开发者编写的业务代码会通过客户端，也就是 Reference，申请上游对象。当然这里的上游协定有多种，咱们只思考 dubbo 协定栈。
由下面提到这种常见的服务模型，咱们能够认为 Service 是 依赖 Reference 的，一个 Service 的所有 Reference 必须都失常工作后，以后 Service 能力正确承受来自上游的服务。这也就推导出了，Service 应该在 Reference 之后加载，当加载实现所有 Reference 后，保障这些客户端都可用，再加载 Service，裸露能工作的服务，最初再注册到注册核心，喊上游来调用。如果反过来，Service 筹备好了而 Reference 没有，则会造成申请谬误。
因而，服务上线逻辑是 Consumer 加载 -> Provider 加载 -> Registry 服务注册。
有读者可能会纳闷，如果 Consumer 依赖以后 实例本人的 Provider 怎么办，Dubbo 的实现是能够不走网络间接发动函数调用，Go 这边也能够依照这种思路来解决，不过实现还待开发。这种状况绝对较少，更多的还是上述大家相熟的状况。
3 服务端优雅下线逻辑
相比于服务上线，服务下线须要思考的点更多一些。咱们从新回到上一节提到的服务调用模型四步骤：
- 服务端首先须要裸露服务，监听端口，从而具备承受申请的能力。
- 服务端将以后服务信息例如 ip 和端口，注册在中心化的注册核心上，例如 Nacos。
- 客户端拜访注册核心，获取要调用的服务 ip 和端口，实现服务发现。
- 服务调用，客户端针对对应 ip 和端口进行申请。
如果一个服务将要下线，则肯定要把相干的善后工作做好。当初的线上状况是这样：客户端正在源源不断地给以后实例申请，如果这个时候间接完结以后过程，一方面，将在一瞬间会有大量的 tcp 建设连贯失败，只能寄希望于第一章提到的客户端负载平衡策略了；另一方面，有大量正在解决的申请被强制抛弃。这很不优雅！所以当实例晓得本人要被终止后，首先要做的就是通知客户端：“我这个服务要被终止了，快把流量切走”。这体现在实现中，就是把本身的服务信息从注册核心删除。客户端拿不到以后实例 IP 后，不会再将申请发过来，这个时候再终止过程才优雅。
下面所说的，也只是简略的状况。在实在场景之下，客户端可能并没有那么快地把流量切走，并且以后服务手里还有一大批正在解决的工作，如果贸然终止过程，能够形象地了解成将端在手里的一盆水撒了一地。
有了这些铺垫，咱们来具体地聊一聊服务下线的步骤。
优雅下线的应用和触发
下面的小故事外面提到，过程首先要晓得本人“要被终止”了，从而触发优雅下线逻辑。这个音讯能够是信号量，当 k8s 要终止容器过程，会由 kubelet 向过程发送 SIGTERM 信号量。在 Dubbo-go 框架内预置了一系列终止信号量的监听逻辑，从而在收到终止信号后，仍然能由过程本人来管制本人的口头，也就是执行优雅下线逻辑。
不过有些利用会本人监听 SIGTERM 信号处理下线逻辑。比方，敞开 db 连贯、清理缓存等，尤其是充当接入层的网关类型利用，web 容器和 RPC 容器同时存在。这个时候先敞开 web 容器还是先敞开 RPC 容器就显得尤其最重要。所以 Dubbo-go 容许用户通过配置 internal.signal 来管制 signal 信号监听的机会，并通过 graceful_shutdown.BeforeShutdown()在适合的机会优雅敞开 rpc 容器。同样，Dubbo-go 也容许用户在配置中抉择是否启用新号监听。
反注册
下面提到，服务端须要通知客户端本人要终止了，这个过程就是通过注册核心进行反注册（Unregister）。常见的服务注册中间件，例如 Nacos、Zookeeper、Polaris 等都会反对服务反注册，并将删除动作以事件的模式告诉给上游客户端。客户端肯定是随时放弃对注册核心的监听的，是否胜利申请与否，很大水平取决于来自注册核心的音讯有没有被客户端及时监听和作出响应。
在 Dubbo-go 的实现中，客户端会第一工夫拿到删除事件，将该实例对应 invoker 从缓存中删除。从而保障后续的申请不会再流向该 invoker 对应的上游。
反注册过程尽管很快，但毕竟是逾越三个组件之间的事件，无奈保障霎时实现。因而便有了下一步：期待客户端更新。
和前面步骤有些关联的是，在以后阶段只进行反注册，而不能进行反订阅，因为在优雅下线执行的过程中，还会有来自本身客户端向上游的申请，如果反订阅，将会无奈接管到上游的更新信息，可能导致谬误。
期待客户端更新
服务端在优雅下线逻辑的反注册执行后，不能疾速杀死以后服务，而会阻塞以后优雅下线逻辑一小段时间，这段时间由开发人员配置，默认 3s，应该大于从反注册到客户端删除缓存的工夫。
通过了这段期待更新的工夫，服务端就能够认为，客户端曾经没有新的申请发送过去了，便能够亮起红灯，逻辑是回绝所有新的申请。
期待来自上游的申请实现
这里还是不能杀死以后过程，这就像本人的手里还端着那盆水，之前做的只是来到了注水的水龙头，但并没有把盆里的水倒洁净。因而要做的还是期待，期待以后实例正在解决的，所有来自上游的申请都实现。
服务端会在一层 filter 保护一个并发平安的计数器，记录所有进入以后实例但未返回的申请数目。优雅下线逻辑会在这时轮询计数器，一旦计数器归零，视为再也没有来自上游的申请了，手里端着的来自上游的水也就倒洁净了。
期待本人收回的申请失去响应
走到这一步，整条链路中，本人上游的申请都移除洁净了。但本人往上游收回的申请还是个未知数，此时此刻兴许有大量由以后实例收回，但未失去响应的申请。如果这时贸然终止以后过程，会造成不可预知的问题。
因而还是相似于上述的逻辑，服务在客户端 filter 保护一个线程平安的计数器，由优雅下线逻辑来轮询，期待所有申请都曾经返回，计数器归零，方可实现这一阶段的期待。
如果以后实例存在一个客户端，源源不断地主动向上游发动申请，计数器可能始终不归零，那就要依附这一阶段的超时配置，来强行完结这一阶段了。
销毁协定，开释端口
这时，就能够放心大胆地做最初的工作了，销毁协定、敞开监听，开释端口，反订阅注册核心。用户可能心愿在下线逻辑彻底完结后，端口开释后，执行一些本人的逻辑，所以能够提供给开发者一个回调接口。
三 优雅高低线的成果
依照上述的介绍，咱们在集群内进行了压测试验和模仿高低线试验。
应用一个 client 实例，5 个 proxy 实例，5 个 provider 实例，申请链路为：
client -> proxy -> provider
因为资源问题，咱们抉择让客户端保障 5000 tps 的压力，通过 dubbo-go 的 prometheus 可视化接口暴露出成功率和谬误申请计数，之后针对链路中游的 proxy 实例和链路上游的 provider 实例进行滚动公布、扩容、缩容、实例删除等一系列试验，模仿生产公布过程。
期间我记录了很多数据，能够把一个比拟显著的比照展现进去。
不应用优雅高低线逻辑：更新时成功率大幅升高，谬误数目继续升高，客户端被迫重启。
优雅高低线优化后：无谬误申请，成功率放弃在 100%
四 Dubbo-go 在服务治理能力的瞻望
Dubbo-go v3.0 从去年年底正式发版，到当初过了一个多月左右的工夫，3.0 公布对咱们而言不是功败垂成，而是踏上了展望未来的一个新阶梯。咱们行将公布 3.1 版本，这一版本将领有优雅高低线能力。
在 3.0 筹备阶段，我有想过如果一款服务框架从传统设计走向将来，须要一步一步走下来，须要有多个必经之路：从最根本的用户敌对性反对、配置重构、易用性、集成测试、文档建设；到实现传输协定（Dubbo3）Triple-go 的跨生态、稳固、高性能、可扩大、生产可用；再到咱们 3.0 发版之后的 服务治理能力、运维能力、可视化能力、稳定性，其中就包含了优雅高低线、流量治理、proxyless；再到造成生态，跨生态集成。这样走，能力一步一个脚印，一直积攒，一直迭代。
运维能力和服务治理的空虚和优化，将作为后续版本的重要 Feature，咱们将会进一步欠缺流量治理、路由、Proxyless Service Mesh、还有文中提到的柔性负载平衡算法等方面，这些都是往年社区工作的重点。
原文链接
本文为阿里云原创内容，未经容许不得转载。