如何设计一个注册中心

引言

注册中心是微服务技术体系中非常重要的组件，主要负责服务的注册与发现。不知道大家有没有想过，假如我们是设计师，我们该如何设计注册中心呢？本文从设计者角度出发，和大家一起讨论下注册中心的核心设计思路。

• 为什么需要注册中心
• 注册中心核心功能
• 总结

一、为什么需要注册中心

在微服务体系中，各个业务服务之间互相调用是家常便饭。如何对各个服务的ip、port等路由信息进行统一的管理是一个非常值得思考的方式。特别是在集群以及云的场景下，服务节点的路由信息可能会经常发生变化。如何做到服务节点路由信息变化时对于业务方调用无感知，在当前的微服务体系中显得尤为重要。注册中心也就是为了解决这个问题而应运而生的。

二、注册中心核心功能

注册中心的核心功能主要包括服务注册、服务发现、健康监测等，它就相当于微服务体系中的交通枢纽，拥有所有业务服务的地址信息。

（1）服务注册

服务提供方向注册中心进行注册，注册时提供的信息主要包括服务提供方IP、端口以及上下文等服务路由信息。以便于服务消费方进行调用信息获取以及服务调用。序列化协议、节点的权重。

（2）服务发现

服务发现主要实现服务消费方可以通过注册中心寻找到服务提供方的调用路由信息。

服务消费方启动后进行服务列表的拉取，客户端同时在本地进行服务列表信息缓存。为什么进行缓存？主要是为了万一注册中心挂了，还可以在本地的缓存信息中获取到服务提供方法的调用信息。

另外在注册中心中的服务发生服务节点变化的时候，注册中心可以告知服务消费方。服务消费方可以重新拉取最新的服务列表，进行服务列表数据更新。

但是有以上两点可以保证客户端在节点变化时更新本地服务列表信息吗？万一注册中心通知回调消费方的时候发生网络抖动，无法正常通知到消费方，那么就有可能导致通知失败。因此我们还需要一个兜底的措施，就是服务消费方可以定时向注册中心进行服务列表信息的拉取，更新消费方客户端的本地服务列表数据。

（3）健康检测

服务健康检测的目的是为了确保注册到注册中心的服务节点是可以被正常调用的，避免坏死无效节点导致的调用资源浪费等问题。注册中心在检测到节点异常后可以对服务节点进行及时剔除。

服务节点一般通过客户端主动定时向注册中心上报心跳，表明服务节点的存活情况。但是只有心跳是否可以满足健康监测的要求呢？如果服务节点内部发生死锁或者假死，此时心跳仍然可以正常上报，注册中心会误以为服务提供方仍然是活着的。

因此服务提供方在向注册中心注册的时候，还要注册一个用于进行检测的服务内部接口，确保健康监测的正确性。

（4）数据存储

对于一个分布式中间件来说，其数据如何进行高效的进行组织是关乎中间件整体性能以及可用度的重要设计参考。在数据存储方面，我们主要考虑三个重要指标，分别是数据可靠性、服务可用性以及数据的一致性。

在分布式系统中，CAP理论是指导思想，是架构的基石。但是CAP并不能同时满足，一般满足AP或者CP。有时候要保证数据一致性就要牺牲可用性，有时候要保证可用性就要牺牲数据一致性。但是分区容错性是一个分布式系统高可用的基础。那么对于注册中心来说，它属于AP还是CP呢？

在使用场景上更倾向于AP模型。注册中心作为基础中间件，为了保证高可用，肯定进行多节点集群部署。如果发生网络分区的情况。每个服务分区都只有部分节点，如果此时使用CP模型，那么就需要等到分区问题解决，各个注册中心节点完成数据一致性恢复才可对外提供服务。那么中间这一段时间，整个注册中心就是不可用的。在这样的场景下是不是对于业务消费方来说不太能接受。因为这样的操作相当于终止业务了。即便发生网络分区，导致部分节点信息可知，但是至少好有节点是可以使用的，可以查询到对应的服务提供方的。那么这种场景下，AP模型应该更加符合业务场景。

在注册中心中的数据主要关注两点，一是服务节点注册或者下线应该怎么存储，二是服务节点变化时怎么找到对应订阅的服务消费方进行通知。针对第一点，我们可以以集群的维度来进行数据的组织，比如ProviderA集群下面三个服务节点，那么在新增加点后，可以追加到ProviderA集群下面。针对第二个点，当服务节点发生变化时，可以找到ProviderA集群被哪些消费方订阅，进而及时通知各个订阅消费方。

但是对于注册中心集群来说，各个服务方进行注册的时候可能注册到了不同的注册中心节点上，那么当节点发生变化时，需要通知不同节点上面的服务订阅者。我们可以通过gossip协议进行处理，在注册中心集群中进行消息传播。保证变更消息可以通知到消费方。

三、总结

本文主要介绍了注册中心的核心功能以及设计思想，通过对注册中心的分析，能够帮助我们更好的理解以及使用注册中心，甚至可以思考现有注册中心是否存在不足以及可以进行优化的地方。