注册中心ETCD 、 Zookeeper、 Eureka、Nacos、Consul

注册中心

注册中心主要有三种角色：

服务提供者（RPC Server）：在启动时，向 Registry 注册自身服务，并向 Registry 定期发送心跳汇报存活状态。

服务消费者（RPC Client）：在启动时，向 Registry 订阅服务，把 Registry 返回的服务节点列表缓存在本地内存中，并与 RPC Sever 建立连接。

服务注册中心（Registry）：用于保存 RPC Server 的注册信息，当 RPC Server 节点发生变更时，Registry 会同步变更，RPC Client 感知后会刷新本地 内存中缓存的服务节点列表。
 

 

RP和HPPT

1. 基本定义

• HTTP是一种应用层协议，专为超文本传输而设计，最初用于浏览器和服务器之间的通信。HTTP 是基于请求-响应模型的标准化协议。
• RPC是一种机制，旨在像调用本地函数一样调用远程服务器上的函数。它抽象了底层通信细节，让开发者专注于功能逻辑的实现。

2. 通信模型

• HTTP 的通信模型
• 客户端通过 URL 和 HTTP 方法（如 GET、POST、PUT、DELETE）向服务器发起请求。
• 服务器解析请求并返回响应，通常包括状态码和数据内容。
• HTTP 基于无状态的请求-响应模型，每个请求独立完成。
• RPC 的通信模型
• 客户端调用远程方法时，实际会向服务器发送一条消息，包含方法名、参数和其他元数据。
• 服务器接收调用信息后，执行对应的操作并返回结果。
• RPC 可以支持状态管理（例如会话持久化），但也可能是无状态的。

3. 数据格式

• HTTP
• 通常使用标准化的文本格式（如 JSON、XML）或二进制格式（如 Protobuf）。
• 数据格式与协议无强耦合，可以根据需求自定义。
• RPC
• 多数情况下，RPC 使用高效的二进制格式（如 Protobuf、Thrift）进行数据序列化和反序列化。
• 数据结构通常与接口定义文件（如 .proto 文件）紧密绑定。

4. 应用场景

• HTTP
• 适用于需要与广泛的客户端通信的场景，例如 Web 应用程序、RESTful API服务等。
• 对标准化和跨平台兼容性要求较高。
• RPC
• 适用于服务间通信，尤其是在微服务架构中。
• 更强调高效、低延迟，通常用于内部系统调用。

5. 开发复杂度

• HTTP
• 相对简单，尤其是在使用 RESTful API 风格时，开发者只需了解基本的 HTTP 方法和状态码即可。
• 很容易与不同语言和平台集成。
• RPC
• 通常需要使用特定框架（如 gRPC、Apache Thrift）和工具链。
• 开发时需定义接口（IDL），增加了一定的复杂性。

6. 性能

• HTTP
• 由于协议的通用性和数据格式的灵活性，性能往往比RPC略低，特别是使用JSON或XML等较大数据格式时。
• 对于频繁的小数据调用场景，HTTP 的头部开销会成为瓶颈。
• RPC
• 通常性能更高，因为使用了轻量级的二进制协议和更高效的传输机制。
• 对延迟敏感的场景非常友好。

 

Zookeeper

①Zookeeper 如何实现注册中心

Zookeeper 可以充当一个服务注册表（Service Registry），让多个服务提供者形成一个集群，让服务消费者通过服务注册表获取具体的服务访问地址（IP+端口）去访问具体的服务提供者。

每当一个服务提供者部署后都要将自己的服务注册到 Zookeeper 的某一路径上: /{service}/{version}/{ip:port} 。

比如我们的 HelloWorldService 部署到两台机器，那么 Zookeeper 上就会创建两条目录：

/HelloWorldService/1.0.0/100.19.20.01:16888

/HelloWorldService/1.0.0/100.19.20.02:16888

 

在 Zookeeper 中，进行服务注册，实际上就是在 Zookeeper 中创建了一个 znode 节点，该节点存储了该服务的 IP、端口、调用方式（协议、序列化方式）等。

该节点承担着最重要的职责，它由服务提供者(发布服务时)创建，以供服务消费者获取节点中的信息，从而定位到服务提供者真正网络拓扑位置以及得知如何调用。
 

RPC 服务注册/发现过程简述如下：

服务提供者启动时，会将其服务名称，IP 地址注册到配置中心。

服务消费者在第一次调用服务时，会通过注册中心找到相应的服务的 IP 地址列表，并缓存到本地，以供后续使用。

当消费者调用服务时，不会再去请求注册中心，而是直接通过负载均衡算法从 IP 列表中取一个服务提供者的服务器调用服务。

当服务提供者的某台服务器宕机或下线时，相应的 IP 会从服务提供者 IP 列表中移除。同时，注册中心会将新的服务 IP 地址列表发送给服务消费者机器，缓存在消费者本机。

当某个服务的所有服务器都下线了，那么这个服务也就下线了。

同样，当服务提供者的某台服务器上线时，注册中心会将新的服务 IP 地址列表发送给服务消费者机器，缓存在消费者本机。

服务提供方可以根据服务消费者的数量来作为服务下线的依据。
 Zookeeper 提供了“心跳检测”功能：它会定时向各个服务提供者发送一个请求（实际上建立的是一个 socket 长连接），如果长期没有响应，服务中心就认为该服务提供者已经“挂了”，并将其剔除。

| Eureka

Eureka 特点：
可用性（AP 原则）：Eureka 在设计时就紧遵 AP 原则，Eureka 的集群中，只要有一台 Eureka 还在，就能保证注册服务可用，只不过查到的信息可能不是最新的（不保证强一致性）。

去中心化架构：Eureka Server 可以运行多个实例来构建集群，不同于 ZooKeeper 的选举 leader 的过程，Eureka Server 采用的是 Peer to Peer 对等通信。

这是一种去中心化的架构，无 master/slave 之分，每一个 Peer 都是对等的。节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点。每个节点都可被视为其他节点的副本。

请求自动切换：在集群环境中如果某台 Eureka Server 宕机，Eureka Client 的请求会自动切换到新的 Eureka Server 节点上，当宕机的服务器重新恢复后，Eureka 会再次将其纳入到服务器集群管理之中。

节点间操作复制：当节点开始接受客户端请求时，所有的操作都会在节点间进行复制操作，将请求复制到该 Eureka Server 当前所知的其它所有节点中。

自动注册&心跳：当一个新的 Eureka Server 节点启动后，会首先尝试从邻近节点获取所有注册列表信息，并完成初始化。

Eureka Server 通过 getEurekaServiceUrls() 方法获取所有的节点，并且会通过心跳契约的方式定期更新。

自动下线：默认情况下，如果 Eureka Server 在一定时间内没有接收到某个服务实例的心跳（默认周期为 30 秒），Eureka Server 将会注销该实例（默认为 90 秒，eureka.instance.lease-expiration-duration-in-seconds 进行自定义配置）。

保护模式：当 Eureka Server 节点在短时间内丢失过多的心跳时，那么这个节点就会进入自我保护模式。
 

Eureka 的工作流程：

Eureka Server 启动成功，等待服务端注册。在启动过程中如果配置了集群，集群之间定时通过 Replicate 同步注册表，每个 Eureka Server 都存在独立完整的服务注册表信息。

Eureka Client 启动时根据配置的 Eureka Server 地址去注册中心注册服务。

Eureka Client 会每 30s 向 Eureka Server 发送一次心跳请求，证明客户端服务正常。

当 Eureka Server 90s 内没有收到 Eureka Client 的心跳，注册中心则认为该节点失效，会注销该实例。

单位时间内 Eureka Server 统计到有大量的 Eureka Client 没有上送心跳，则认为可能为网络异常，进入自我保护机制，不再剔除没有上送心跳的客户端。

当 Eureka Client 心跳请求恢复正常之后，Eureka Server 自动退出自我保护模式。

Eureka Client 定时全量或者增量从注册中心获取服务注册表，并且将获取到的信息缓存到本地。

服务调用时，Eureka Client 会先从本地缓存找寻调取的服务。如果获取不到，先从注册中心刷新注册表，再同步到本地缓存。

Eureka Client 获取到目标服务器信息，发起服务调用。

Eureka Client 程序关闭时向 Eureka Server 发送取消请求，Eureka Server 将实例从注册表中删除。
 

Nacos

Nacos 主要特点如下：
服务发现和服务健康监测：

Nacos 支持基于 DNS 和基于 RPC 的服务发现。服务提供者使用原生SDK、OpenAPI、或一个独立的Agent TODO注册 Service 后，服务消费者可以使用DNS TODO 或HTTP&API查找和发现服务。

Nacos 提供对服务的实时的健康检查，阻止向不健康的主机或服务实例发送请求。Nacos 支持传输层 (PING 或 TCP)和应用层 (如 HTTP、MySQL、用户自定义）的健康检查。

对于复杂的云环境和网络拓扑环境中（如 VPC、边缘网络等）服务的健康检查，Nacos 提供了 agent 上报模式和服务端主动检测 2 种健康检查模式。Nacos 还提供了统一的健康检查仪表盘，帮助您根据健康状态管理服务的可用性及流量。
 

| Consul

Consul 的调用过程：
当 Producer 启动的时候，会向 Consul 发送一个 post 请求，告诉 Consul 自己的 IP 和 Port。

Consul 接收到 Producer 的注册后，每隔 10s（默认）会向 Producer 发送一个健康检查的请求，检验 Producer 是否健康。

当 Consumer 发送 GET 方式请求 /api/address 到 Producer 时，会先从 Consul 中拿到一个存储服务 IP 和 Port 的临时表，从表中拿到 Producer 的 IP 和 Port 后再发送 GET 方式请求 /api/address。

该临时表每隔 10s 会更新，只包含有通过了健康检查的 Producer。
 

ETCD

etcd 是一个 Go 言编写的分布式、高可用的一致性键值存储系统，用于提供可靠的分布式键值存储、配置共享和服务发现等功能

ETCD 特点：
易使用：基于 HTTP+JSON 的 API 让你用 curl 就可以轻松使用

易部署：使用 Go 语言编写，跨平台，部署和维护简单

强一致：使用 Raft 算法充分保证了分布式系统数据的强一致性

高可用：具有容错能力，假设集群有 n 个节点，当有 (n-1)/2 节点发送故障，依然能提供服务

持久化：数据更新后，会通过 WAL 格式数据持久化到磁盘，支持 Snapshot 快照

快速：每个实例每秒支持一千次写操作，极限写性能可达 10K QPS

安全：可选 SSL 客户认证机制

ETCD 框架主要分为四个部分：
HTTP Server：用于处理用户发送的 API 请求以及其他 etcd 节点的同步与心跳信息请求。

Store：用于处理 etcd 支持的各类功能的事务，包括数据索引、节点状态变更、监控与反馈、事件处理与执行等等，是 etcd 对用户提供的大多数 API 功能的具体实现。

Raft：Raft 强一致性算法的具体实现，是 etcd 的核心。

WAL：Write Ahead Log（预写式日志），是 etcd 的数据存储方式。除了在内存中存有所有数据的状态以及节点的索引以外，etcd 就通过 WAL 进行持久化存储。

WAL 中，所有的数据提交前都会事先记录日志。Snapshot 是为了防止数据过多而进行的状态快照；Entry 表示存储的具体日志内容。
 

| 注册中心对比

 服务健康检查：Euraka 使用时需要显式配置健康检查支持；Zookeeper、Etcd 则在失去了和服务进程的连接情况下任务不健康，而 Consul 相对更为详细点，比如内存是否已使用了90%，文件系统的空间是不是快不足了。

多数据中心：Consul 和 Nacos 都支持，其他的产品则需要额外的开发工作来实现。

KV 存储服务：除了 Eureka，其他几款都能够对外支持 k-v 的存储服务

CAP 理论的取舍：

Eureka 是典型的 AP，Nacos 可以配置为 AP，作为分布式场景下的服务发现的产品较为合适，服务发现场景的可用性优先级较高，一致性并不是特别致命。

而 Zookeeper、Etcd、Consul 则是 CP 类型牺牲可用性，在服务发现场景并没太大优势。
 Watch 的支持：Zookeeper 支持服务器端推送变化，其它都通过长轮询的方式来实现变化的感知。