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

共 4450字,需浏览 9分钟

 ·

2021-08-06 00:00

开篇



这篇文章是基于 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 对比,我们在金融级和分布式(存储量级)上具有很大优势,易用性和云原生方面,目前还在追赶。


欢迎加入我们



一个人可以走得很快,但一群人可以走的更远。

——题记

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,或是写一篇文档,都可以更好地帮助社区,帮助自己去成长。


浏览 16
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报