阿里忘禅：蚂蚁集团分布式注册中心建设分享

-     前言    -

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

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

-     注册中心是什么    -

一、服务发现 & 服务注册

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

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

一般来说&＃xff0c;分为两个点&＃xff1a;

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

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

• 服务连接注册中心&＃xff0c;同时上报自身的服务以及元数据&＃xff08;也是今天本文讲述的重点&＃xff09;

• 有一个集中的控制面&＃xff08;control plane&＃xff09;将用户定义的服务和 IP 的映射写入注册中心&＃xff0c;例如 AWS 的 CloudMap。

-     调用流程    -

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

1. 服务 A&＃xff0c;服务 B 通过 SDK 或者 REST 将自身的服务信息上报给注册中心&＃xff1b;

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

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

-     心跳    -

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

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

2. 注册中心把问题节点从自身的存储中拉出&＃xff08;这里拉出根据具体实现&＃xff1a;有的是直接删除&＃xff0c;有的是标记为不健康&＃xff09;&＃xff1b;

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

-     Dubbo 注册中心    -

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

Dubbo-2.7

Dubbo-3.0

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

1. protocol&＃xff08;协议类型&＃xff09;比如&＃xff0c;zookeeper&＃xff1b;

2. host&＃xff1b;

3. port。

基于此&＃xff0c;Dubbo 的注册流程如下图所示&＃xff1a;

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

2. 服务的消费方通过 Dubbo 客户端订阅信息&＃xff08;subscribe&＃xff09;;

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

-     注册中心的本质    -

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

“存储” &＃43; “可运维”

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

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

-     蚂蚁注册中心编年史    -

一、史前时代

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

二、硬负载时代

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

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

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

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

1. 单点的问题&＃xff08;所有调用都走 F5 的话&＃xff0c;F5 一旦挂了&＃xff0c;很多服务会不可用&＃xff09;&＃xff1b;

2. 容量问题&＃xff08;F5 承载的流量太高&＃xff0c;本身会到一个性能瓶颈&＃xff09;。

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

四、第二代注册中心 -- ScaleUp&＃xff1f;ScaleOut&＃xff1f;It&＃39;s a problem

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

1. 单点风险&＃xff08;注册中心本身是单机应用&＃xff09;&＃xff1b;

2. 容量瓶颈&＃xff08;单台注册中心的连接数和存储数据的容量是有限的&＃xff09;。

解决的方式有两种&＃xff1a;

1. scale-up&＃xff08;淘宝&＃xff09;&＃xff1a;通过增加机器的配置&＃xff0c;来增强容量以及扛链接能力&＃xff1b;同时&＃xff0c;通过主-备这样的架构&＃xff0c;来保障可用性&＃xff1b;

2. scale-out&＃xff08;蚂蚁&＃xff09;&＃xff1a;通过分片机制&＃xff0c;将数据和链接均匀分布在多个节点上&＃xff0c;做到水平拓展&＃xff1b;通过分片之后的备份&＃xff0c;做到高可用。

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

蚂蚁的演进架构如下&＃xff0c;产生了两种不同的应用节点&＃xff1a;

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

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

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

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

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

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

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

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

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

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

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

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

1. Data 节点的发布在数据量大的前提下&＃xff0c;依然是个痛点&＃xff1b;

2. Session 节点的新加节点上&＃xff0c;可能很久都没有流量。

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

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

1. 改进数据存储算法&＃xff08;consistent-hash -> hash-slot&＃xff09;&＃xff1b;

2. 应用级服务发现。

&＃xff08;1&＃xff09;存储算法的演进

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

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

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

改进后的算法&＃xff0c;我们参考了 Redis Cluster 的算法机制&＃xff0c;使用 hash slot 进行数据分片&＃xff1b;

这样&＃xff0c;在 Data 发布过程中&＃xff0c;可以控制数据的迁移以 slot 为单位&＃xff08;单个 Data 节点多个 slot&＃xff0c;可配置&＃xff09;。

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

&＃xff08;2&＃xff09;应用级服务发现

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

-     开源    -

SOFARegistry 从项目早期就开始了开源的进程&＃xff0c;与目前主流的注册中心的对比如下&＃xff1a;

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

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

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

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

往期推荐

刘朋&＃xff1a;程序员如何练就领导力

2021-07-29

山哥新作&＃xff1a;架构师必备技能之业务分析

2021-07-26

浅谈云原生架构的 7 个原则

2021-07-23

资深架构师十几年的架构干货经验总结分享&＃xff01;

2021-07-19

资深架构专家聊小团队中微服务困境及分布式事务解决方案

2021-07-16

阿里专家晨末&＃xff1a;什么是技术一号位&＃xff1f;

2021-07-08

八戒技术&＃xff1a;徒手撸一套简易字符识别方案

2021-08-12

右军&＃xff1a;为张逸《解构领域驱动设计》推荐序

2021-08-09

架构师的职责、核心能力、能力修炼手册

2021-08-09

美团技术&＃xff1a;交易平台建设实践&＃xff08;视频&＃43;胶片&＃xff09;

2021-08-04