共计 2952 个字符，预计需要花费 8 分钟才能阅读完成。
作者 | 行松 阿里巴巴云原生团队
利用公布、服务降级始终是一个让开发和运维同学既兴奋又放心的事件。
兴奋的是有新性能上线，本人的产品能够对用户提供更多的能力和价值；放心的是上线的过程会不会出现意外状况影响业务的稳定性。的确，在利用公布和服务降级时，线上问题呈现的可能性更高，本文咱们将联合 Serverless 利用引擎（以下简称 SAE）就 Serverless 架构下，探讨如何保障上线过程中服务的优雅下线。
在平时的公布过程中，咱们是否遇到过以下问题：
- 公布过程中，呈现正在执行的申请被中断？
- 上游服务节点曾经下线，上游仍然持续调用曾经下线的节点导致申请报错，进而导致业务异样？
- 公布过程造成数据不统一，须要对脏数据进行修复。
有时候，咱们把发版安顿在凌晨两三点，赶在业务流量比拟小的时候，心惊胆颤、睡眠不足、苦不堪言。那如何解决下面的问题，如何保障利用公布过程稳固、高效，保障业务无损呢？首先，咱们来梳理下造成这些问题的起因。
场景剖析
上图形容了咱们应用微服务架构开发利用的一个常见场景，咱们先看下这个场景的服务调用关系：
- 服务 B、C 把服务注册到注册核心，服务 A、B 从注册核心发现须要调用的服务；
- 业务流量从负载平衡打到服务 A，在 SLB 上配置服务 A 实例的健康检查，当服务 A 有实例停机的时候，相应的实例从 SLB 摘掉；服务 A 调用服务 B，服务 B 再调用服务 C；
图中有两类流量，南北向流量（即通过 SLB 转发到后端服务器的业务流量，如业务流量 -> SLB -> A 的调用门路）和东西向流量（通过注册核心服务中心服务发现来调用的流量，如 A -> B 的调用门路），上面针对这两类流量别离进行剖析。
南北向流量
南北向流量存在问题
当服务 A 公布的时候，服务 A1 实例停机后，SLB 依据健康检查探测到服务 A1 下线，而后把实例从 SLB 摘掉。实例 A1 依赖 SLB 的健康检查从 SLB 上摘掉，个别须要几秒到十几秒的工夫，在这个过程中，如果 SLB 有继续的流量打入，就会造成一些申请持续路由到实例 A1，导致申请失败；
服务 A 在公布的过程中，如何保障通过 SLB 的流量不报错？咱们接着看下 SAE 是如何做的。
南北向流量优雅降级计划
如上文所提，申请失败的起因在于后端服务实例先进行掉，而后才从 SLB 摘掉，那咱们是不是能够先从 SLB 摘掉服务实例，而后再对实例进行降级呢？
依照这个思路，SAE 基于 K8S service 的能力给出了一种计划，当用户在通过 SAE 为利用绑定 SLB 时，SAE 会在集群中创立一个 service 资源，并把利用的实例和 service 关联，CCM 组件会负责 SLB 的购买、SLB 虚构服务器组的创立，并且把利用实例关联的 ENI 网卡增加到虚构服务器组中，用户能够通过 SLB 来拜访利用实例；当利用公布时，CCM 会先把实例对应的 ENI 从虚构服务器组中摘除，而后再对实例进行降级，从而保障流量不失落。
这就是 SAE 对于利用降级过程中对于南北向流量的保障计划。
东西向流量
东西向流量存在问题
在探讨完南北向流量的解决方案后，咱们再看下东西向流量，传统的公布流程中，服务提供者进行再启动，服务消费者感知到服务提供者节点进行的流程如下：
- 服务公布前，消费者依据负载平衡规定调用服务提供者，业务失常。
- 服务提供者 B 须要公布新版本，先对其中的一个节点进行操作，首先是进行 java 过程。
服务进行过程，又分为被动登记和被动登记，被动登记是准实时的，被动登记的工夫由不同的注册核心决定，最差的状况会须要 1 分钟。
- 如果利用是失常进行，Spring Cloud 和 Dubbo 框架的 Shutdown Hook 能失常被执行，这一步的耗时能够忽略不计。
- 如果利用是非正常进行，比方间接应用
kill -9进行，或者 Docker 镜像构建的时候 java 利用不是 1 号过程且没有把 kill 信号传递给利用。那么服务提供者不会被动去登记服务节点，而是在超过一段时间后因为心跳超时而被动地被注册核心摘除。
- 服务注册核心告诉消费者，其中的一个服务提供者节点已下线。蕴含推送和轮询两种形式，推送能够认为是准实时的，轮询的耗时由服务消费者轮询距离决定，最差的状况下须要 1 分钟。
- 服务消费者刷新服务列表，感知到服务提供者曾经下线了一个节点，这一步对于 Dubbo 框架来说不存在，然而 Spring Cloud 的负载平衡组件 Ribbon 默认的刷新工夫是 30 秒，最差状况下须要耗时 30 秒。
- 服务消费者不再调用曾经下线的节点。
从第 2 步到第 6 步的过程中，Eureka 在最差的状况下须要耗时 2 分钟，Nacos 在最差的状况下须要耗时 50 秒。在这段时间内，申请都有可能呈现问题，所以公布时会呈现各种报错，同时还影响用户的体验，公布后又须要修复执行到一半的脏数据。最初不得不每次发版都安顿在凌晨两三点公布，心惊胆颤，睡眠不足，苦不堪言。
东西向流量优雅降级计划
通过上文的剖析，咱们看，在传统公布流程中，客户端有一个服务调用报错期，起因就是客户端没有及时感知到服务端下线的实例。在传统公布流程中，次要是借助注册核心告诉消费者来更新服务提供者列表，那能不能绕过注册核心，服务提供者间接告诉服务消费者呢？答案是必定的，咱们次要做了两件事件：
- 服务提供者利用在公布前后被动向注册核心登记利用，并将利用标记为已下线的状态；将原来的进行过程阶段登记服务变成了 prestop 阶段登记服务。
- 在接管到服务消费者申请时，首先会失常解决本次调用，并告诉服务消费者此节点已下线，服务消费者会立刻从调用列表删除此节点；在这之后，服务消费者不再调用曾经下线的节点。这是将原来的依赖于 注册核心推送，做到了服务提供者间接告诉消费者从调用列表中摘除本人。
通过下面这个计划，就使得下线感知的工夫大大减短，从原来的分钟级别做到准实时，确保利用在下线时能做到业务无损。
分批公布和灰度公布
上文介绍的是 SAE 在解决优雅下线方面的一些能力，在利用降级的过程中，只有实例的优雅下线是不够的，还须要有一套配套的公布策略，保障咱们新业务是可用的，SAE 提供分批公布和灰度公布的能力，能够使得利用的公布过程更加省心省力；
咱们先介绍下灰度公布，某利用蕴含 10 个利用实例，每个利用实例的部署版本为 Ver.1 版本，现需将每个利用实例降级为 Ver.2 版本。
从图中能够看出，在公布的过程中先灰度 2 台实例，在确认业务失常后，再分批公布残余的实例，公布的过程中始终有实例处于运行状态，实例降级过程中按照下面的计划，每个实例都有优雅下线的过程，这就保障了业务无损。
再来看下分批公布，分批公布反对手动、主动分批；还是下面的 10 个利用实例，假如将所有利用实例分 3 批进行部署，依据分批公布策略，该公布流程如图所示，就不再具体介绍了。
最初针对在 SAE 上利用灰度公布的过程进行演示，点击即可观看演示过程：https://developer.aliyun.com/lesson_2026_19009
课程举荐
为了更多开发者可能享受到 Serverless 带来的红利，这一次，咱们集结了 10+ 位阿里巴巴 Serverless 畛域技术专家，打造出最适宜开发者入门的 Serverless 公开课，让你即学即用，轻松拥抱云计算的新范式——Serverless。点击即可收费观看课程：https://developer.aliyun.com/learning/roadmap/serverless
