IM专题：服务化架构IM系统（5）— 优雅上线

在 IM 的服务化架构体系中，很多功能（如用户登录、状态同步、消息收发、联系人管理、系统消息等）逻辑的设计与实现，与分层架构 IM （见IM专题：分层架构系列合集）中的设计与实现非常类似，从技术研发角度讲，没有很多出彩的地方。

对 IM 的服务化架构的研究和学习，更多的是在 “服务治理” 方面。什么是 “服务治理”？通俗理解就是对众多服务的有效管理，包括服务的上线、服务的注册、服务的发现、服务的通信、服务的监控、服务的容错、服务的下线等对服务全生命周期的管理。

今天讨论一下服务的 “优雅上线”。

什么是 “优雅上线”？何为 “优雅”？不 “优雅” 是什么情况呢？见下图。

msg-logic 服务通过 RPC 调用 msg-das 服务，msg-das 服务集群由 4 个服务节点组成。对 msg-das 服务进行需求迭代后，通常会通过直接重启 msg-das 节点的方式来上线，这样做有什么影响呢？

如果有监控系统监测错误请求的数量，在监控图上会有一个瞬时的错误高峰，见下图；这就是 “不优雅” 的上线，也叫做突兀。

如何做到服务的优雅上线，避免突兀呢？也就是整个上线过程，很丝滑，不能因为进程重启导致异常请求的发生。

服务的优雅上线，属于 “服务治理” 的范畴，对于服务的治理更多需要借助于 “注册中心” 这一核心的组件；在整个微服务架构体系中，只有 “注册中心” 这唯一的组件能直接触达到所有的服务，这就为对服务的治理提供了一个通信的渠道；“注册中心” 是整个微服务架构的核心和枢纽。见下图。

那么借助于 “注册中心” ，如何对服务进行优雅上线呢？我们直接上方案，见下图。

msg-das 服务向注册中心进行 “服务注册” 的操作， msg-logic 服务向注册中心进行 “服务发现” 的操作，获取到 msg-das 服务集群有 4 个节点，然后 msg-logic 向这 4 个节点发起 RPC 远程调用的业务请求，这是通过注册中心进行服务调用前的普通流程。

对 msg-das 服务的第 1 个节点进行优雅上线的流程如下：

发布平台向注册中心下发一条 “权重指令”，该指令表示对 msg-das 服务的第一个节点的调用流量权重进行调整；
注册中心通过自身的基础能力（服务订阅）判断出 msg-logic 对 msg-das 服务的第 1 个节点有调用流量；
注册中心直接向 msg-logic （具体是向 msg-logic 服务集群中的所有节点）直接下发权重指令，将 msg-logic 调用 msg-das 服务第 1 个节点的流量权重降为 0；
发布平台对 msg-das 服务的第 1 个节点进行服务的上线发布和进程重启操作；
发布平台再次向注册中心下发 “权重指令”，注册中心将 “权重指令” 下发给 msg-logic 服务，将该服务对 msg-das 服务第 1 个节点的调用权重调整为 1%；
新上线的 msg-das 服务集群第 1 个节点，若没有发现任何异常，发布平台继续下发 “权重指令” ，将对第 1 个 msg-das 服务节点的调用权重调整为 2%，如此不断灰度，持续到上线之前的水平；
按上述流程对 msg-das 服务的第 2 个节点、第 3 个节点和第 4 个节点进行上线发布。

这就是 IM 服务化架构优雅上线的整体方案，其核心的关键技术是对 “注册中心” 和每个服务中注册中心的客户端进行改造，定制出注册中心与每个服务之间通信的指令通道，不过这是注册中心范畴的研发内容，在后续文章中会详细分析。

我们可以从上述服务优雅上线的实现方案中，抽象出基于注册中心的通用的服务治理模型，见下图。

需要注意：注册中心可以触达所有服务，提供的是下发指令的通道，而非采集数据的通道；采集数据对于注册中心来说，太重了，应该由服务治理平台承载。

有了这样的一个服务治理模型，指令可以无限扩展，对所有服务能干的事情就太多了，比如：流量路由、服务的熔断降级、AB测试等等，大家可以尽情发挥想象！

最后，总结文中关键：

服务治理包括服务上线、服务注册、服务发现、服务通信、服务监控、服务容错、服务下线等对服务全生命周期的管理内容；
突兀的服务上线方式，会导致服务内部队列中的请求、服务待接收的请求、服务上游待发送的请求丢失；
注册中心是微服务体系中唯一能触达到所有服务节点的组件，是微服务架构的核心和枢纽；
优雅的上线基本流程为：发布平台下发指令到注册中心，注册中心下发指令到服务消费方，服务消费方将流量权重降为 0，服务提供方节点上线，逐步恢复对该服务提供方的流量权重；
基于注册中心的服务治理模型包括服务治理平台、注册中心、服务提供方、服务消费方以及指令下发通道和获取数据通道。