架构师面试（十四）：注册中心设计

问题

大家或多或少都接触过【注册中心】，对注册中心的基本功能，如：服务注册、服务发现、健康检查和变更通知 ，肯定是耳熟能详的；那么大家对注册中心的架构设计是否了解呢？

如果让你负责设计一个分布式的注册中心系统，那么你会考虑哪些关键问题呢？

解析

我们先来回顾关于【注册中心】的几个关键点：

1、注册中心的四大基本功能包括：服务注册、服务发现、健康检查和变更通知；其中 “服务注册” 动作由服务提供方节点发起，“服务发现” 动作由服务消费方节点发起，“健康检查” 和 “变更通知” 动作由注册中心发起；

2、注册中心这个组件存在的本质意义是什么呢？从系统架构分析的角度是为了解耦服务提供方节点对服务消费方节点的依赖。怎么理解呢？假设 服务消费方节点A 对 服务提供方节点B 进行 RPC 调用，我们说A和B的关系是 单向依赖；但是在实际的应用中，B节点的访问地址需要提供（以及将来的回收）给A，此时A和B 就形成了双向依赖的循环依赖关系；通过引入注册中心则方便的解决了该问题；

3、注册中心从功能的实现角度分析其本质，即：注册中心 = 存储系统 + 订阅系统，即在搭建一个注册中心的框架时，把握好其【存储实现】和【订阅实现】，也就基本实现了一个注册中心系统。

现在回到我们的问题上来，设计一个分布式的注册中心系统，需要考虑哪些关键问题呢？需要考虑三个最关键的点：

1、存储模型实现

注册中心需要记录和保存：服务提供方服务与节点之间的映射关系、服务消费方服务与节点之间的映射关系、服务消费方与服务提供方之间的订阅和被订阅的映射关系；存储模型的实现关乎注册中心【服务注册】和【服务发现】两个基本功能的实现。

2、订阅模型实现

注册中心需要通过【健康检查】密切关注着服务提供方节点的任何风吹草动，一旦有情况，需要及时通过【变更通知】主动告之服务消费方节点，这就是订阅模型需要做的实现；我们曾经提到过，订阅模型系统由三种实现模型，即：信箱模型、电话模型和BP机模型（见《架构师面试（三）：订阅模型》），大家想一下广为人知的作为注册中心的zookeeper采用了什么样的订阅模型呢？ 

关于【健康检查】，大家需要注意，当服务数量非常高的时候，注册中心应该通过什么样的算法及时检测到服务提供方的健康状态呢？

3、数据节点同步

作为分布式的注册中心系统，肯定有很多的节点组成，而不同客户端连接的往往是不同的节点，这些节点之间如何进行数据同步呢？这是作为分布式注册中心系统必须要考虑的关键问题。为了让大家有一个更直观的理解，我们举一个例子：

假设一个分布式的注册中心系统由三个节点组成，分别是：X、Y、Z；服务提供方A有两个节点，分别是PA-1、PA-2；服务消费方B有两个节点，分别是CA-1、CA-2；服务B订阅了服务A；PA-1连接的是X节点、PA-2和CA-1连接的是Y节点、CA-2连接的是Z节点。（下面重点来了）当PA-1节点挂掉以后，X节点通过【健康检查】及时获取这个事件后，必须及时同步到Y节点和Z节点，由Y节点把变更通知给CA-1和由Z节点把变更通知给CA-2。

最后，我们一句话总结：设计一个分布式的注册中心系统，需要考虑存储模型实现、订阅模型实现和数据节点同步这样三个最关键的问题。