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

问题

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

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

解析

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

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

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

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

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

1、存储模型实现

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

2、订阅模型实现

注册中心需要通过【健康检查】密切关注着服务提供方节点的任何风吹草动，一旦有情况，需要及时通过【变更通知】主动告之服务消费方节点，这就是订阅模型需要做的实现；我们曾经提到过，订阅模型系统由三种实现模型，即：信箱模型、电话模型和BP机模型（见《