1 什么是注册中心
注册中心是服务实例信息的管理平台,是连接服务提供者和服务消费者中间件。主要有两大核心功能：服务注册和服务发现。
1.1 为什么需要注册中心
在传统的单体架构中，应用内的各个模块的耦合度高，影响开发和部署效率。因此，现在更多的大型应用开始拆分成一个个的微服务。这些微服务之间通过RPC进行通信。没有注册中心，其他微服务的访问地址是Hard Code的。这样就会出现维护困难、难以应对频繁变更的情况。
因此，注册中心应运而生。注册中心维护服务的实例以及对应的IP：port信息，服务调用者只需要服务名就可以对具体的服务进行调用。
1.2 CAP理论
CAP理论是分布式架构中的重要理论，即一个分布式系统不能同时满足C、A、P三种特性。
- C-Consistency 一致性：所有节点在同一时间具有相同的数据。
- A-Availability 可用性：保证每个请求都有响应，不管是成功还是失败。
- P-Partition tolerance 分区容忍性：系统中任意信息的丢失或失败不会影响系统的运行。
对于分布式系统，P是必须要满足的。否则单点故障导致整个分布式系统不可用。因此，一般会在C和A取舍。
2 注册中心的重要功能
- 服务注册：将提供某个服务的模块信息（ip:port）告知注册中心中。
- 服务发现：服务消费者可从注册中心获取到对应服务的实例列表，根据需要进行调用。
- 健康检测：检测服务的健康状态。
- 服务注销：注销服务实例，使其不再被发现。
3 常见的注册中心引擎
3.1 Nacos
Nacos（Dynamic Naming and Configuration Service的首字母简称），一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。
关键特性
Nacos的关键特性主要包括服务发现和服务健康监测、动态配置服务、动态DNS服务、服务及其元数据管理等。
服务发现：
Nacos支持基于DNS和基于RPC的服务发现。服务提供者使用原生SDK、OpenAPI、或一个独立的Agent TODO注册 Service 后，服务消费者可以使用DNS TODO 或HTTP&API查找和发现服务。
服务健康检测：
1. 客户端上报：所有注册的服务默认为临时实例，默认开启主动上报动能。心跳连接间隔为5秒，若15秒未上报，则被标记为“不健康”；30秒未上报，则服务会被移除。
2. 服务端下探：Nacos默认使用TCP检查服务的健康状态，检测端口为80，检测间隔为20秒。
健康保护阈值
Nacos为每个服务提供了保护阀值，其值范围在0-1之间,当服务实例健康个数占比（健康实例个数/总实例个数）小于这个保护阀值时，为降低服务雪崩的可能，也会向不健康实例发送请求，保证剩余健康实例可用性。
负载均衡
支持服务端、客户端负载均衡
AP与CP共存
Nacos同时支持AP和CP，默认AP协议。具体地，对于临时实例，Nacos保证AP；对于持久实例，Nacos保证CP。
兼容性
Nacos支持与Spring Cloud/K8S/dubbo集成。
支持多种注册中心的同步
NacosSync是一个支持多种注册中心的同步组件,目前已支持的同步类型:
- Nacos数据同步到Nacos;
- Zookeeper数据同步到Nacos;
- Nacos数据同步到Zookeeper;Eureka数据同步到Nacos;
- Consul数据同步到Nacos
3.2 Eureka
Eureka是一个服务治理组件，它主要包括服务注册和服务发现，主要用来搭建服务注册中心。主要就两种角色服务端和客户端（服务提供者/服务消费者）。
Eureka保证AP：
Eureka优先保证可用性，各个节点是平等的，当部分节点出现故障时，剩余的节点依然能够提供服务，但是不保证查到的信息是最新的。
自我保护机制
在15分钟内85%的节点都没有正常的心跳，Eureka就会认为客户端与注册中心出现网络故障。此时：
- Eureka不移除因长时间没收到心跳而过期的服务。
- 仍接收新服务注册和查询请求，但不会同步到其他节点，保证当前节点可用。
- 当网络稳定时，当前实例新注册的信息会同步到其他节点。
负载均衡
客户端负载均衡
生态
Eureka只支持与Spring Cloud集成。
3.3 Zookeeper
Zookeeper是一种协调分布式应用的引擎，因Dubbo使用ZK实现注册中心的功能。因此，ZK也被常用于注册中心。
三角色
- Leader： 一个ZK集群在同一时间只有一个工作的Leader节点，由其发起并维持与其他节点之间的心跳。写操作都是通过Leader完成并广播给其他节点。
- Follower：一个集群可能同时存在多个Follower。其可以直接处理客户端的读请求，同时将写请求转发的Leader节点，并且负责在Leader处理写请求时对请求进行投票。
- Observer：类似于Follower，但是没有投票权。
四节点
- Persistent-持久节点：不被删除则一直存在。
- Ephemeral-临时节点：生命周期与客户端会话绑定。
- Persistent_sequential-持久顺序节点：类似于Persistent，只是具有顺序，节点名后会追加一个由父节点维护的自增整数。
- Ephemeral——sequential-临时顺序节点：类似于Ephemeral，只是具有顺序，节点名后会追加一个由父节点维护的自增整数。
ZK优先保证CP
Zookeeper整体遵循一致性（CP）原则，即在任何时候对 Zookeeper 的访问请求能得到一致的数据结果，但是当机器下线或者宕机时，不能保证服务可用性。
负载均衡
客户端负载均衡
Watch机制
ZK的监听机制采用了一种推拉的模式。
- 服务消费者会去监听相应路径，一旦路径上的数据有任务变化（增加或减少），Zookeeper会发送一个事件类型和节点信息给关注的客户端，而不会包括具体的变更内容，事件本身是轻量级的。
- 收到变更通知的客户端需要自己去拉变更的数据。
生态
ZK只支持与Dubbo集成。
4 总结
| Nacos | Eureka | Zookeeper | |
| 一致性 | AP/CP | AP | CP |
| 健康监测 | TCP/HTTP/Client Beat | Client Beat | Keep Alive |
| 负载均衡 | 服务端/客户端 | 客户端 | 客户端 |
| 雪崩保护 | 有 | 有 | 无 |
| 跨注册中心同步 | 支持 | 不支持 | 不支持 |
| SpringCloud集成 | 支持 | 支持 | 不支持 |
| K8S集成 | 支持 | 不支持 | 不支持 |
| Dubbo集成 | 支持 | 不支持 | 支持 |
- 在数据一致性方面，Nacos支持CP和AP，Eureka是AP模型，Zookeeper是CP模型。
- 在状态监测方面，Zookeeper 使用TCP的KeepAlive保持客户端和服务端的连接。Eureka 通过客户端心跳来确定客户端是否启动。Nacos 既支持客户端的健康检查（KeepAlive、Client心跳），也支持服务端的健康检查（MYSQL命令等）。
- 在负载均衡方面，Nacos支持服务端/客户端负载均衡，而Eureka和Zookeeper需要在客户端实现负载均衡。
- Nacos和Eureka支持雪崩保护机制，而Zookeeper则不支持。
- 只有Nacos支持跨注册中心同步。Nacos支持与SpringCloud/K8S/Dubbo集成，而Eureka只支持与SpringCloud集成，Zookeeper只支持与Dubbo集成。
