蚂蚁集团分布式注册中心建设分享-技术圈

- 前言 -

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

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

- 注册中心是什么 -

一、服务发现 & 服务注册

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

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

一般来说，分为两个点：

服务发现可以有一个中心化的组件或者说是存储，它承载了所有服务的地址，同时提供出来一个可供查询和订阅的能力，服务的消费方可以通过和这个中心化的存储交互，获取服务提供方的地址列表。
服务注册：同样是上文中中心化的组件，但是，这个时候的服务信息可以有两种措施：

服务连接注册中心，同时上报自身的服务以及元数据（也是今天本文讲述的重点）
有一个集中的控制面（control plane）将用户定义的服务和 IP 的映射写入注册中心，例如 AWS 的 CloudMap。

- 调用流程 -

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

服务 A，服务 B 通过 SDK 或者 REST 将自身的服务信息上报给注册中心；
服务 A 需要调用服务 B 的时候，就对注册中心发起请求，拉取和服务 B 相关的服务 IP 列表以及信息；
在获取到服务 B 的列表之后，就可以通过自身定义的负载均衡算法访问服务 B。

- 心跳 -

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

服务 B 的一个节点断网或是 hang 住，引发心跳超时；或是宕机、断链直接引发心跳失败；
注册中心把问题节点从自身的存储中拉出（这里拉出根据具体实现：有的是直接删除，有的是标记为不健康）；
服务 A 收到注册中心的通知，获取到服务 B 最新的列表。

- Dubbo 注册中心 -

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

Dubbo-2.7

Dubbo-3.0

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

protocol（协议类型）比如，zookeeper；
host；
port。

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

服务的生产方通过 Dubbo 客户端向注册中心（Registry）发起注册行为（register）;
服务的消费方通过 Dubbo 客户端订阅信息（subscribe）;
注册中心通过通知的方式，下发服务列表给服务消费方。

- 注册中心的本质 -

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

“存储” + “可运维”

一方面，注册中心需要存储能力去记录服务的信息，比如应用列表；
另一方面，注册中心在实践过程中，需要提供必需的运维手段，比如关闭某一服务流量。

- 蚂蚁注册中心编年史 -

一、史前时代

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

二、硬负载时代

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

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

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

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

单点的问题（所有调用都走 F5 的话，F5 一旦挂了，很多服务会不可用）；
容量问题（F5 承载的流量太高，本身会到一个性能瓶颈）。

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

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

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

单点风险（注册中心本身是单机应用）；
容量瓶颈（单台注册中心的连接数和存储数据的容量是有限的）。

解决的方式有两种：

scale-up（淘宝）：通过增加机器的配置，来增强容量以及扛链接能力；同时，通过主-备这样的架构，来保障可用性；
scale-out（蚂蚁）：通过分片机制，将数据和链接均匀分布在多个节点上，做到水平拓展；通过分片之后的备份，做到高可用。

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

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

Session 节点，专门用来抗链接使用，本身无状态可以快速扩展，单机对资源的占用很小；
Data 节点，专门用来存储数据，通过分片的方式降低单个节点的存储量，控制资源占用。

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

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

所有 Data 都是分布式的，Data 之间的服务发现需要通过启动时给定一个配置文件，这样就和标准运维脱钩；
Data 节点的上下线需要去及时修改配置文件，否则集群重启会受到影响；
分布式存储一致性问题，每次迭代发布，需要锁定 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 对比，我们在金融级和分布式（存储量级）上具有很大优势，易用性和云原生方面，目前还在追赶。

- 共同建设 -

SOFARegistry 是一个开源项目，也是开源社区 SOFA 重要的一环，我们希望用社区的力量推动 SOFARegistry 的前进，而不是只有蚂蚁的工程师去开发。我们在今年也启动了两个项目，用于支持更多的开发者参与进来：

Trun-Key Project （开箱即用计划）：

https://github.com/sofastack/sofa-registry/projects/5

Deep-Dive Project（深入浅出计划）：

https://github.com/sofastack/sofa-registry/projects/4

计划目前还处在初期阶段，欢迎大家加入进来，可以帮助我们解决一个 issue，或是写一篇文档，都可以更好地帮助社区，帮助自己去成长。