第六代注册中心 面向运维的注册中心

我们做出了一个分布式注册中心 https://mp.weixin.qq.com/s/y371tkAXXEOCdCMOBl2tBA

我们做出了一个分布式注册中心

原创 祝辰（忘禅） 金融级分布式架构 2021-07-27

 

这篇文章是基于 SOFA Meetup 合肥站的分享总结，主要针对于注册中心的定位以及功能介绍，通过对蚂蚁注册中心发展史的分析，带领大家了解，蚂蚁的注册中心是如何一步一步演变为现在的规模和特性的。

更多深入的技术细节，欢迎大家加入到 SOFA 和 SOFARegistry 的社区中，探寻结果。

注册中心是什么

一、服务发现 & 服务注册

注册中心简单来说，是为了解决分布式场景下，服务之间互相发现的问题。

如下图所示，服务 A 想要调用服务 B 的时候，需要知道 B 的地址在哪里，如何解决这个问题？

一般来说，分为两个点：

1. 服务发现可以有一个中心化的组件或者说是存储，它承载了所有服务的地址，同时提供出来一个可供查询和订阅的能力，服务的消费方可以通过和这个中心化的存储交互，获取服务提供方的地址列表。

2. 服务注册：同样是上文中中心化的组件，但是，这个时候的服务信息可以有两种措施：

• 服务连接注册中心，同时上报自身的服务以及元数据（也是今天本文讲述的重点）

• 有一个集中的控制面（control plane）将用户定义的服务和 IP 的映射写入注册中心，例如 AWS 的 CloudMap。

二、调用流程

如上图所示，就是目前一种主流的注册中心模式，SOFARegistry 和 Nacos 都是这种模式。

1. 服务 A，服务 B 通过 SDK 或者 REST 将自身的服务信息上报给注册中心；

2. 服务 A 需要调用服务 B 的时候，就对注册中心发起请求，拉取和服务 B 相关的服务 IP 列表以及信息；

3. 在获取到服务 B 的列表之后，就可以通过自身定义的负载均衡算法访问服务 B。

三、心跳

心跳是注册中心用于解决服务不可用时，及时拉出服务降低影响的默认方式，如下图所示。

1. 服务 B 的一个节点断网或是 hang 住，引发心跳超时；或是宕机、断链直接引发心跳失败；

2. 注册中心把问题节点从自身的存储中拉出（这里拉出根据具体实现：有的是直接删除，有的是标记为不健康）；

3. 服务 A 收到注册中心的通知，获取到服务 B 最新的列表。

四、Dubbo 注册中心

下面通过 Dubbo 的例子，我们来看一下注册中心是如何使用的，以及流程：首先，Dubbo 在 2.7 和 3.0 中的配置略有不同，但是都是简单易懂的，这里都放上来。

Dubbo-2.7

Dubbo-3.0

在 RPC 客户端只需要配置一个注册中心的地址即可，地址中包含了基础三元素：

1. protocol（协议类型）比如，zookeeper；

2. host；

3. port。

基于此，Dubbo 的注册流程如下图所示：

1. 服务的生产方通过 Dubbo 客户端向注册中心（Registry）发起注册行为（register）;

2. 服务的消费方通过 Dubbo 客户端订阅信息（subscribe）;

3. 注册中心通过通知的方式，下发服务列表给服务消费方。

五、注册中心的本质

通过前文的讲解，以及 Dubbo 组件的具体例子，我们大概可以归纳注册中心的本质。

“存储” + “可运维”

1. 一方面，注册中心需要存储能力去记录服务的信息，比如应用列表；

2. 另一方面，注册中心在实践过程中，需要提供必需的运维手段，比如关闭某一服务流量。

蚂蚁注册中心编年史

一、史前时代

史前时代的蚂蚁是相当久远的架构，当时所有的服务部署在同一台物理机上或者 JVM 上，服务之间不存在有跨机器调用的场景，这里略过不表述。

二、硬负载时代

后来，为了解决应用之间的耦合带来的部署难，运维难问题，我们对服务进行了拆分，拆分后的服务，遇到了一个问题，就是如何处理服务之间的调用关系，这个时候，蚂蚁用了两种硬负载 F5 或是 LVS。

通过简单的 4 层代理，我们可以把服务部署在代理的后面，服务与服务之间通过代理互相访问，达到了跨机调用的目的。

三、第一代注册中心 -- 硬负载到软负载的演变

通过硬负载访问的方式，一方面解决了服务之间互相调用的问题，部署架构也简单易懂；另一方面，在业务快速增长之后，却带来了一定的问题：

1. 单点的问题（所有调用都走 F5 的话，F5 一旦挂了，很多服务会不可用）；

2. 容量问题（F5 承载的流量太高，本身会到一个性能瓶颈）。

这个时候，蚂蚁引进了阿里集团的一款产品叫 ConfigServer，作为注册中心进行使用，这个注册中心的架构就和开头提到的架构很像了，服务之间可以通过 IP 直接访问，而降低了对负载均衡产品的强依赖，减少了单点风险。

四、第二代注册中心 -- ScaleUp？ScaleOut？It's a problem

但是，问题还在持续，那就是注册中心，本身是一个单点，那么，他就会继续遇到上文中所说的两个问题：

1. 单点风险（注册中心本身是单机应用）；

2. 容量瓶颈（单台注册中心的连接数和存储数据的容量是有限的）。

解决的方式有两种：

1. scale-up（淘宝）：通过增加机器的配置，来增强容量以及扛链接能力；同时，通过主-备这样的架构，来保障可用性；

2. scale-out（蚂蚁）：通过分片机制，将数据和链接均匀分布在多个节点上，做到水平拓展；通过分片之后的备份，做到高可用。

蚂蚁和淘宝走了两条不同的路，也推进了蚂蚁后面演进出一套独立的生态系统。

蚂蚁的演进架构如下，产生了两种不同的应用节点：

1. Session 节点，专门用来抗链接使用，本身无状态可以快速扩展，单机对资源的占用很小；

2. Data 节点，专门用来存储数据，通过分片的方式降低单个节点的存储量，控制资源占用。

五、第五代注册中心 -- Meta 节点的诞生

上面的架构已经很符合目前主流的分布式架构了，但是在运维过程中，产生了一系列问题，比如：

1. 所有 Data 都是分布式的，Data 之间的服务发现需要通过启动时给定一个配置文件，这样就和标准运维脱钩；

2. Data 节点的上下线需要去及时修改配置文件，否则集群重启会受到影响；

3. 分布式存储一致性问题，每次迭代发布，需要锁定 paas 平台，防止节点变动带来的不一致。

所有这些问题的产生，我们发现可以引入一个元数据管理中心（Meta）节点来，解决对 Data 和 Session 管理的问题，Data 和 Session 通过 4 层负载或是 7 层负载对 Meta 访问即可。

对比业界的解决方案，都有类似的模型，比如 HDFS 的 Name Node、Kafka 依赖于 ZK，Oceanbase 依赖于 RootServer 或者配置中心 Apollo 依赖于 Euraka。

Meta 节点的出现，缓解了手工运维注册中心的瓶颈，但是，依然没有从根本上解决问题，那么问题在哪里？详见下文分析。

六、第六代注册中心 -- 面向运维的注册中心

上文说道，Meta 节点的出现，承接了 Data 以及 Session 之间服务发现的问题，但是，丛云未测来讲，还是有很多问题解决不了，比如：

1. Data 节点的发布在数据量大的前提下，依然是个痛点；

2. Session 节点的新加节点上，可能很久都没有流量。

等等，对于这些问题，在 SOFARegistry 5.x 的基础上，我们快速迭代了 6.0 版本，主要是面向运维的注册中心。

Data 节点发布难的问题，说到底是一个影响范围的问题，如何控制单一 Data 节点发布或者挂掉对数据的影响面，是解决问题的本源，这里我们采用了两个措施：

1. 改进数据存储算法（consistent-hash -> hash-slot）；

2. 应用级服务发现。

（1）存储算法的演进

之前我们使用了一致性 hash 的算法，如下图所示，每一个节点承载一部分数据，通过是存储进行 hash 运算，算出存储内容的 hash 值，再计算出 hash 值落在哪一个 Data 所负责的存储区间，来存储数据。

当 Data 节点宕机或者重启时，由下一个 Data 节点接收宕机节点的数据以及数据的访问支持。

这样依赖，数据迁移的粒度只能以单个 Data 节点所存储的数据为单位，在数据量较大（单节点 8G）的情况下，对数据的重建有一定的影响，而且，在 Data 连续宕机的情况下，可能存在数据丢失或是不一致的场景。

改进后的算法，我们参考了 Redis Cluster 的算法机制，使用 hash slot 进行数据分片；

这样，在 Data 发布过程中，可以控制数据的迁移以 slot 为单位（单个 Data 节点多个 slot，可配置）

同时，为了解决迁移或是宕机期间，数据写入不一致的场景，我们引入了数据回放的补偿机制，Data 在 promotion 为 slot 的 master 之后，会主动地去和所有的 Session 完成一次数据比对/校验，增量同步新增数据。

（2）应用级服务发现

应用级服务发现是为了解决数据存储量大的问题，因为篇幅原因，这里略过不表述。

开源

SOFARegistry 从项目早期就开始了开源的进程，与目前主流的注册中心的对比如下：

我们认为，注册中心首先需要解决的是可用性的问题，所以，在分布式一致性的问题上，我们选择了 AP 的模型，这点也和主流的注册中心，例如 Euraka 以及 Nacos 保持一致的观点。

其次，在性能方面，基于长连接的 SOFARegistry 拥有更短的推送延迟，相较于 Nacos 1.0 的推送时延更短（Nacos 1.0 基于 Long Polling 的模型，Nacos 2.0 也使用了长连接的模型）。

在协议方面，SOFARegistry 使用了蚂蚁开源协议栈：BOLT 协议（类似于 HTTP 2.0）的流式协议，更加轻量级，同时协议本身的全双工模式：无阻塞，大大提升了资源利用率。

和大家所熟知的 Nacos 对比，我们在金融级和分布式（存储量级）上具有很大优势，易用性和云原生方面，目前还在追赶。

欢迎加入我们