关于zookeeper:注册中心

服务注册核心，是一个给服务提供者注册服务、给服务消费者获取服务信息的中央，个别还提供服务列表查问、心跳检测等性能。注册核心为保障可用性个别集群部署。
注册核心组件咱们可选的组件有 Eureka、ZK、Nacos，而依据 CAP 定律，ZK 反对 CP，Eureka 反对 AP，Nacos 可反对 AP 也可反对 CP。上面别离论述下。

Eureka 分服务端与客户端，服务端为注册核心，而客户端实现向服务端注册与服务发现。服务端的次要工作有：

提供服务注册。提供一个对立存储服务的中央，客户端（服务提供者）将服务注册后服务端提供治理
提供注册表。为客户端（服务消费者）提供服务列表的查问，也就是服务发现性能。客户端获取服务列表后个别会在本地进行缓存，以缩小与注册核心交互
服务剔除。如果客户端在肯定工夫内未上报心跳，服务端会剔除此服务实例
自我爱护机制。一段时间内如果客户端可用率低于肯定比例则会进入自我爱护阶段，避免 Eureka 客户端自身是能够失常拜访的，然而因为网路通信故障等起因，造成 Eureka 服务端失去于客户端的连贯，从而造成的不可用

客户端的性能这里只是简略列举一下：服务注册、主动刷新缓存获取最新服务列表、服务续约上报心跳、近程调用、服务下线。

注册与发现的工作流程：

server 启动后，client 启动后将服务注册到 server
client 默认每 30s 向 server 发动心跳
server 若 90s 没收到 client 的心跳申请，则统计 15 分钟内是否有超过 85% 的比例，如果有进入自我爱护状态；如果没有则剔除该 client
client 定时调用 server 接口获取服务列表更新本地缓存
client 近程调用时，先从本地缓存找，如果找到则间接发动调用，如果没有则先向 server 进行查问后再发动调用
client 敞开时会发 http 申请到 server，server 承受申请后将该实例剔除

Eureka 是 CAP 里的 AP
从 CAP 实践看，Eureka 是一个 AP 零碎，其优先保障可用性 (A) 和分区容错性，不保障强一致性，但能做到最终一致性。

只有集群中任意一个实例不呈现问题，Eureka 服务就是可用的；即 Eureka Client 在向某个 Eureka Server 注册时，如果发现连贯失败，则会主动切换至其它节点；
Eureka 集群中没有主从的概念，各个节点都是平等的，节点间采纳 Replicate 异步的形式来同步数据；

因为 Eureka 并不强调一致性而偏重可用性，在设计上为晋升性能采纳了多级缓存的计划。这种设计和 mysql 的读写拆散及 JDK 里的 CopyOnWriteArrayList 有点相似，目标是为了使操作不阻塞读操作。

Eureka 数据存储机制

Eureka 没有采纳数据库这类存储介质，它的数据层分 数据存储层 和缓存层。数据存储层记录注册到 Eureka Server 上的服务信息，缓存层是通过包装后的数据，能够间接在 Eureka Client 调用时返回。

存储层
咱们先来看看数据存储层的数据结构，它底层是一个双层 HashMap:

private final ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>> registry= new ConcurrentHashMap<String, Map<String, Lease<InstanceInfo>>>();

第一层的 ConcurrentHashMap 的 key=spring.application.name 也就是客户端实例注册的利用名；value 为嵌套的 ConcurrentHashMap。
第二层嵌套的 ConcurrentHashMap 的 key=instanceId 也就是服务的惟一实例 ID，value 为 Lease 对象，Lease 对象存储着这个实例的所有注册信息，包含 ip、端口、属性等。

缓存层
接下来咱们再来看看缓存层。

Eureka Server 为了提供响应效率，提供了两层的缓存构造，将 Eureka Client 所须要的注册信息，间接存储在缓存构造中。

第一层缓存：readOnlyCacheMap，实质上是 ConcurrentHashMap，依赖定时从 readWriteCacheMap 同步数据，默认工夫为 30 秒。

readOnlyCacheMap：是一个 CurrentHashMap 只读缓存，这个次要是为了供客户端获取注册信息时应用，其缓存更新，依赖于定时器的更新，通过和 readWriteCacheMap 的值做比照，如果数据不统一，则以 readWriteCacheMap 的数据为准。

第二层缓存：readWriteCacheMap，实质上是 Guava 缓存。

readWriteCacheMap：readWriteCacheMap 的数据次要同步于存储层。当获取缓存时判断缓存中是否没有数据，如果不存在此数据，则通过 CacheLoader 的 load 办法去加载，加载胜利之后将数据放入缓存，同时返回数据。
readWriteCacheMap 缓存过期工夫，默认为 180 秒，当服务下线、过期、注册、状态变更，都会来革除此缓存中的数据。

客户端查问流程

客户端查问服务端数据的流程是怎么的呢，这里临时不思考客户端本身的缓存。

Eureka Client 获取全量或者增量的数据时，会先从一级缓存中获取；如果一级缓存中不存在，再从二级缓存中获取；如果二级缓存也不存在，这时候先将存储层的数据同步到缓存中，再从缓存中获取。

通过 Eureka Server 的二层缓存机制，能够十分无效地晋升 Eureka Server 的响应工夫，通过数据存储层和缓存层的数据切割，依据应用场景来提供不同的数据反对。

客户端缓存

客户端缓存只是简略提一下：
Eureka Client 也同样存在着缓存机制，Eureka Client 启动时会全量拉取服务列表，启动后每隔 30 秒从 Eureka Server 量获取服务列表信息，并放弃在本地缓存中。

ZK 作为注册核心原理主发依赖于其本身的文件，ZK 的文件构造相似于 Linux 零碎的树状构造，注册服务时，即在 ZK 中创立一个惟一的 znode 节点来保留服务的 IP、端口、服务名等信息；发现服务时，遍历树状构造文件找到具体的 znode 节点或者服务相干信息进行近程调用。

注册与发现的工作流程

ZK 曾经启动，服务提供者启动时把服务注册到 ZK 注册核心；
ZK 注册核心和服务提供者之间建设一个 Socket 长连贯，ZK 注册核心定时向每个服务提供者发数据包，如果服务提供者没响应，则剔除该服务提供者实例，把更新后的服务列表发送给所有服务消费者（即告诉）；
服务消费者启动时到 ZK 注册核心获取一份服务列表缓存到本地供当前应用；
服务消费者近程调用服务时，先从本地缓存找，如果找到则间接发动服务调用，如果没有则到 ZK 注册核心获取服务列表缓存到本地后再发动服务调用；
当其中一个服务提供者宕机或失常敞开时，ZK 注册核心会把该节点剔除，并告诉所有服务消费者更新本地缓存
当这个服务提供者失常启动后，ZK 注册核心也能感知到，并告诉所有服务消费者更新本地缓存。

ZK 与 Eureka 的区别

依据 CAP 定律，ZooKeeper 反对 CP，Eureka 反对 AP。因为 ZK 集群中如果有节点宕机则须要选举 leader，选举过程须要 30 至 120 秒，选举过程时集群不可用，就义工夫来保证数据一致性，因而反对 CP；而 Eureka 每个节点的数据都统一，没有主从节点之分，不需选举，如果其中一个节点宕机则马上切换到另外一个衰弱的节点上，保障可用性，因而反对 AP。
微服务架构当中，可用性比一致性更重要些，Eureka 比 ZooKeeper 更适合，而 ZooKeeper 更适宜做分布式协调服务，比方：hadoop 集群。

这里简略提一下京东自研的 RPC 框架 JSF，其注册核心为 NameServer，与 Eureka 各节点一样，它们之间也是平等的、各节点存着全量数据，数据的同步采纳的是音讯总线的形式，不言而喻,NameServer 属于 AP 准则，通过音讯总线来保障最终一致性。

Nacos 既能作为注册核心也能够作为配置核心，上面是作为注册核心的流程：

Nacos 启动后，服务提供者启动时将服务注册到 Nacos
服务提供者定时发送 http 申请，上报心跳
Nacos 长时间没收到服务提供者的心跳，则剔除该实例
服务消费者发现服务反对两种形式，一种是被动申请注册核心获取服务列表（图中左下角不举荐），一种是订阅注册核心的服务并提交一个 Listener，如果注册核心的服务有变更，由 Listener 来告诉服务消费者更新本地服务列表（图中右下角）

Nacos 里的 CP 与 AP

先看一下 Nacos 的架构图：

咱们能够看到 Nacos 是集成了 Raft 与 Distro 这两种一致性协定的，咱们先从 Distro 动手，看下 Nacos 的设计机制：

平等机制：nacos 每个节点是平等的，都能够解决写申请，同时会将数据同步到其它节点。
路由转发机制：客户端发送的写申请，如果属于本人则解决，否则路由转发给其它节点
本地计机制：每个节点独立解决读申请，及时从本地收回响应，因为每个节点都存有全量数据
异步复制机制：节点间通过 1s 的提早工作，将数据同步给其它节点
健康检查机制：每个节点只存局部数据，定期检查客户端状态保持数据一致性
新节点同步机制：服务实例注册到 nacos 后，通过 UDP 的形式推送到所有服务实例，让其它服务实例感知到服务列表的变动

Nacos 哪些地方用到了 AP 与 CP 呢？

对于长期服务实例，采纳 AP 来保障注册核心的可用性，Distro 协定
对于长久化服务实例，采纳 CP 保障各个节点的强一致性，JRaft 协定（Nacos 对 Raft 的革新）
对于配置核心，无 Database 作为存储的状况下，Nacos 节点之间的内存数据为了保持一致，采纳 CP
对于配置核心，有 Database 作为存储的状况下，Nacos 通过长久化后告诉其余节点到数据库拉取数据来保证数据一致性，另外采纳 读写拆散架构 来保障高可用，这里应该是 AP

Nacos、ZK、Eureka 区别

Eureka 不能撑持大量服务实例，因为它的每个节点之间会产生大量心跳查看导致并发性能升高；ZK 如果呈现频繁高低线告诉也会导致性能降落；Nacos 能够反对大量服务实例而又不失落性能，服务数量可达到 10 万级别。

参考文章：
《服务注册与发现原理分析（Eureka、Zookeeper、Nacos）》
Eureka 缓存机制具体配置
图文详述 Eureka 的缓存机制 / 三级缓存
Nacos 一致性协定：Distro 协定
揭秘 Nacos 的 AP 架构「Distro 一致性协定」
对标 Eureka 的 AP 一致性，Nacos 如何实现 Raft 算法

关于zookeeper:注册中心

一、Eureka

二、ZK

三、Nacos