海量数据下的注册中心 - SOFARegistry 架构介绍

简介： SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。

SOFAStack
Scalable Open Financial Architecture Stack 是蚂蚁金服自主研发的金融级分布式架构，包含了构建金融级云原生架构所需的各个组件，是在金融场景里锤炼出来的最佳实践。 

SOFARegistry 是蚂蚁金服开源的具有承载海量服务注册和订阅能力的、高可用的服务注册中心，最早源自于淘宝的初版 ConfigServer，在支付宝/蚂蚁金服的业务发展驱动下，近十年间已经演进至第五代。

GitHub 地址：https://github.com/sofastack/sofa-registry 

3 月 31 日，蚂蚁金服正式开源了内部演进了近 10 年的注册中心产品-SOFARegistry。先前的文章介绍了 SOFARegistry 的演进之路，而本文主要对 SOFARegistry 整体架构设计进行剖析，并着重介绍一些关键的设计特点，期望能帮助读者对 SOFARegistry 有更直接的认识。

服务注册中心是什么

不可免俗地，先介绍一下服务注册中心的概念。对此概念已经了解的读者，可选择跳过本节。

如上图，服务注册中心最常见的应用场景是用于 RPC 调用的服务寻址，在 RPC 远程过程调用中，存在 2 个角色，一个服务发布者（Publisher）、另一个是服务订阅者（Subscriber）。Publisher 需要把服务注册到服务注册中心（Registry），发布的内容通常是该 Publisher 的 IP 地址、端口、调用方式 （协议、序列化方式）等。而 Subscriber 在第一次调用服务时，会通过 Registry 找到相应的服务的 IP 地址列表，通过负载均衡算法从 IP 列表中取一个服务提供者的服务器调用服务。同时 Subscriber 会将 Publisher 的服务列表数据缓存到本地，供后续使用。当 Subscriber 后续再调用 Publisher 时，优先使用缓存的地址列表，不需要再去请求Registry。

如上图，Subscriber 还需要能感知到 Publisher 的动态变化。比如当有 Publisher 服务下线时， Registry 会将其摘除，随后 Subscriber 感知到新的服务地址列表后，不会再调用该已下线的 Publisher。同理，当有新的 Publisher 上线时，Subscriber 也会感知到这个新的 Publisher。

 

初步认识

在理解了常见的服务注册中心的概念之后，我们来看看蚂蚁金服的 SOFARegistry 长什么样子。如上图，SOFARegistry 包含 4 个角色：

1. Client

提供应用接入服务注册中心的基本 API 能力，应用系统通过依赖客户端 JAR 包，通过编程方式调用服务注册中心的服务订阅和服务发布能力。

1. SessionServer

会话服务器，负责接受 Client 的服务发布和服务订阅请求，并作为一个中间层将写操作转发 DataServer 层。SessionServer 这一层可随业务机器数的规模的增长而扩容。

1. DataServer

数据服务器，负责存储具体的服务数据，数据按 dataInfoId 进行一致性 Hash 分片存储，支持多副本备份，保证数据高可用。这一层可随服务数据量的规模的增长而扩容。

1. MetaServer

元数据服务器，负责维护集群 SessionServer 和 DataServer 的一致列表，作为 SOFARegistry 集群内部的地址发现服务，在 SessionServer 或 DataServer 节点变更时可以通知到整个集群。

产品特点