如何设计一个注册中心？（1）概念

1. 为什么需要注册中心

一个集群中有众多服务，每个服务有N个实例，因此需要一个第三方节点来存放每个服务的信息，这样服务需要其它的服务信息，直接到第三方节点获取就行了。这个第三方的节点，就是注册中心。

2. 注册中心的功能

三个模块：
注册中心模块：负责维护服务信息，提供服务注册接口，服务信息获取接口，同时根据心跳机制，与服务提供方维持心跳，从而及时检测到服务提供方是否下线，从而在注册中心中将其信息剔除。

服务提供方模块：将本地的相关服务通过端口暴露出去，可供服务消费方进行服务消费；与注册中心通过定时任务保持心跳机制，方便注册中心及时进行服务下线。

服务消费方模块：从注册中心拉取服务相关信息，从而消费服务提供者提供出来的服务；同时当注册中心服务信息有更新的时候，及时更新本地服务节点信息，重新生成代理对象使用。

功能：
服务注册表 ：服务注册表是注册中心的核心，它用来记录各个微服务的信息，例如微服务的名称、IP、端口等。服务注册表提供查询API和管理API，查询API用于查询可用的微服务实例，管理API用于服务的注册与注销。

服务注册与发现：服务注册是指微服务在启动时，将自己的信息注册到注册中心的过程。服务发现是指查询可用的微服务列表及网络地址的机制。

服务检查：注册中心使用一定的机制定时检测已注册的服务，如发现某实例长时间无法访问，就会从服务注册表移除该实例。

3. 注册中心工作的过程

各个微服务在启动时，将自己的网络地址等信息注册到注册中心，注册中心存储这些数据。

服务消费者从注册中心查询服务提供者的地址，并通过该地址调用服务提供者的接口。

各个微服务与注册中心使用一定机制（例如心跳）通信。如果注册中心与某微服务长时间无法通信，就会注销该实例。

微服务网络地址发送变化（例如实例增加或IP变动等）时，会重新注册到注册中心。这样，服务消费者就无需人工修改提供者的网络地址了。

4. 服务注册的实现

服务进程在注册中心注册自己的元数据信息。通常包括主机和端口号，有时还有身份验证信息，协议，版本号，以及运行环境的信息。

服务注册有两种形式：客户端注册和代理注册。

客户端注册（调用方实现）
客户端注册是服务自己要负责注册与注销的工作。当服务启动后注册线程向注册中心注册，当服务下线时注销自己。

缺点：注册注销逻辑与服务的业务逻辑耦合在一起，如果服务使用不同语言开发，那需要适配多套服务注册逻辑。

代理注册
代理注册由一个单独的代理服务负责注册与注销。当服务提供者启动后以某种方式通知代理服务，然后代理服务负责向注册中心发起注册工作。

5. 服务发现

服务发现也分为客户端发现和代理发现。

客户端发现（调用方实现）
客户端发现是指客户端负责向注册中心查询可用服务地址，获取到所有的可用实例地址列表后客户端根据负载均衡算法选择一个实例发起请求调用。

这种方式非常直接，客户端可以控制负载均衡算法。但是缺点也很明显，获取实例地址、负载均衡等逻辑与服务的业务逻辑耦合在一起，如果服务发现或者负载平衡有变化，那么所有的服务都要修改重新上线。

代理发现
代理发现是指新增一个路由服务负责服务发现获取可用的实例列表，服务消费者如果需要调用服务A的一个实例可以直接将请求发往路由服务，路由服务根据配置好的负载均衡算法从可用的实例列表中选择一个实例将请求转发过去即可，如果发现实例不可用，路由服务还可以自行重试，服务消费者完全不用感知。

6. 心跳机制

如果服务有多个实例，其中一个实例出现宕机，注册中心是可以实时感知到，并且将该实例信息从列表中移出，也称为摘机。

心跳检测有主动和被动两种方式。
被动检测是指服务主动向注册中心发送心跳消息，时间间隔可自定义，比如配置5秒发送一次，注册中心如果在三个周期内比如说15秒内没有收到实例的心跳消息，就会将该实例从列表中移除。
主动检测是注册中心主动发起，每隔几秒中会给所有列表中的服务实例发送心跳检测消息，如果多个周期内未发送成功或未收到回复就会主动移除该实例。

7. 注册中心高可用

高可用无非就是做集群，我们可以对注册中心部署多个节点。在消费端consumer只需要知道一个服务注册中心集群地址cluster-url即可

8. 常见的注册中心

Dubbo中的注册中心：Dubbo支持多种注册中心的实现，常用的是Redis、Zookeeper，这些组件本身就可以做到高性能和高可用。在Dubbo架构图中，可以看到注册中心（Registry）位于顶端，所有的服务治理相关的操作都围绕它进行。服务提供者（Provider）注册到注册中心，服务消费者（Comsumer）到注册中心订阅，同时，注册中心中的变更也会通知服务消费者。

eureka：

服务提供者向Eureka Server中注册服务， Eureka Server接受到注册事件会在集群和分区中进⾏数据同步，Application Client作为消费端（服务消费者）可以从Eureka Server中获取到服务注册信息，进⾏服务调⽤。微服务启动后，会周期性地向Eureka Server发送⼼跳（默认周期为30秒）以续约⾃⼰的信息。

Eureka Server在⼀定时间内没有接收到某个微服务节点的⼼跳， Eureka Server将会注销该微服务节点（默认90秒）。

每个Eureka Server同时也是Eureka Client，多个Eureka Server之间通过复制的⽅式完成服务注册列表的同步。

Eureka Client会缓存Eureka Server中的信息。即使所有的Eureka Server节点都宕掉，服务消费者依然可以使⽤缓存中的信息找到服务提供者。

zookeeper：
高度可靠的分布式协调
ZooKeeper是一种集中式服务，用于维护配置信息，命名，提供分布式同步和提供组服务。所有这些类型的服务都以分布式应用程序的某种形式使用。
zookeeper的核心主要是包含两个部分：服务信息的管理和变更通知机制（watch）

nacos：Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。