服务注册中心介绍与对比

服务注册中心介绍与对比

一、什么是注册中心？

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

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

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

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

最后，RPC Client 从本地缓存的服务节点列表中，基于负载均衡算法选择一台 RPC Sever 发起调用。

二、CAP 理论

CAP 理论是分布式架构中重要理论：

1.一致性(Consistency)：所有节点在同一时间具有相同的数据；

2.可用性(Availability) ：保证每个请求不管成功或者失败都有响应；

3.隔容忍(Partition tolerance) ：系统中任意信息的丢失或失败不会影响系统的继续运作。

服务注册中心往往只能兼顾其中的两点，我们选哪个服务注册中心就需要依据CAP理论，我们之所以只能满足其中两个原则，是因为他本身就是存在矛盾的，比如一致性原则，你又要同时有相同的数据，又想有性能，这是在想桃子吃。

三、常用注册中心对比

1. Zookeeper

ZooKeeper 是非常经典的服务注册中心中间件，在国内环境下，由于受到 Dubbo 框架的影响，大部分情况下认为 Zookeeper 是 RPC 服务框架下注册中心最好选择。随着 Dubbo 框架的不断开发优化，和各种注册中心组件的诞生，即使是 RPC 框架，现在的注册中心也逐步放弃了 ZooKeeper。在常用的开发集群环境中，ZooKeeper 依然起到十分重要的作用，Java 体系中，大部分的集群环境都是依赖 ZooKeeper 管理服务的各个节点。

在 CAP 模型中，Zookeeper 整体遵循一致性（CP）原则，即在任何时候对 Zookeeper 的访问请求能得到一致的数据结果，但是当机器下线或者宕机时，不能保证服务可用性。

那为什么 Zookeeper 不使用最终一致性（AP）模型呢？因为这个依赖 Zookeeper 的核心算法是 ZAB，所有设计都是为了强一致性。这个对于分布式协调系统，完全没没有毛病，但是你如果将 Zookeeper 为分布式协调服务所做的一致性保障，用在注册中心，或者说服务发现场景，这个其实就不合适。

2. Eureka

Eureka 为了保障注册中心的高可用性，容忍了数据的非强一致性，服务节点间的数据可能不一致， Client-Server 间的数据可能不一致。比较适合跨越多机房、对注册中心服务可用性要求较高的使用场景。 Eureka 设计巧妙，完美地解决了注册中心的稳定性和高可用性。
但问题是现在Eureka已经进入了维护阶段，社群相比较也不再活跃，目前最新版的Spring Cloud框架并不推荐使用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 节点在短时间内丢失过多的心跳时，那么这个节点就会进入自我保护模式。

3.Nacos

Nacos 是阿里开源的，支持基于 DNS 和基于 RPC 的服务发现。

Nacos 的注册中心支持 CP 也支持 AP，对他来说只是一个命令的切换，随你玩，还支持各种注册中心迁移到 Nacos，反正一句话，只要你想要的他就有。

Nacos 除了服务的注册发现之外，还支持动态配置服务，一句话概括就是 Nacos = Spring Cloud注册中心 + Spring Cloud 配置中心。

Nacos特点

1.CP模型，使用 Raft 算法来保证强一致性，不保证可用性。

2.支持服务注册与发现、健康检查、KV Store 功能。

3.支持多数据中心，可以避免单数据中心的单点故障，而其部署则需要考虑网络延迟, 分片等情况等。

4.支持安全服务通信，Consul 可以为服务生成和分发 TLS 证书，以建立相互的 TLS 连接。

5.支持 http 和 dns 协议接口。

6.官方提供 web 管理界面。

四、服务注册中心一图对比