常用的注册中心以及他们的对比

注册中心一般原理：

客户端（服务提供者）向注册中心注册服务信息，注册中心存储服务提供者地址信息以及服务发布相关的属性信息，消费者通过主动拉取或者是被动通知的方式获取到服务提供者的服务信息，消费者根据服务注册中心获取到的信息选取一个服务提供者进行访问。

• 服务消费者获取注册信息 1、pull 模式：消费者主动再服务注册中心拉取 2、push 模式：消费者订阅服务（当订阅的服务发生变化时，注册中心推送新的服务清单列表给消费者）

• 服务消费者直接调用服务提供者另外，注册中心也需要完成对服务提供者的健康监控，当发现服务提供者失效时，需要再服务列表中剔除。

主流服务中心对比

• Zookeeper（保证 CP）zk 是一款高度可靠的分布式协调服务。zk 是一种集中式服务，用于提供未付配置信息，命名服务，提供分布式同步服务。zk 的核心功能有两部分：信息存储（服务信息管理）和通知变更（wath）服务注册：服务注册就是再服务器上创建一个 znode 节点，并且时临时节点，保存者服务器的地址，端口，协议等一些信息。临时节点可以再服务断开时自动在服务列表剔除，服务发现服务发现就是客户端获取 zookeeper 上面的节点信息，获取到提供该服务的地址列表信息，然后当消费者调用服务提供者时可以根据相应的负载均衡策略，去访问其中一个提供者。监听机制客户端通过 watch zookeeper 的节点，当服务提供者有某个有故障时，可以被删除（临时节点机制），当服务提供者时可以通过 watch 事件通知客户端（消费者），当前服务列表发生了变化，客户端要再次去获取最新的服务列表信息。zookeeper 应用场景

• zookeeper 优点：特长是做分布式协调服务，例如 kafka、hbase、flink，hadoop 等项目都是用 zk。作为注册中心：1、性能瓶颈，zk 所有的写操作都是 leader 处理的，再大规律服务注册写请求时，压力巨大，而且 leader 是但单点，无法水平扩展。2、所有服务与 zk 的长连接也是很重的负担 3、zk 对于每一个写请求，都会写一个事务日志，同时会定期将内存数据镜像 dump 到磁盘，保持数据一致性和持久性，这个对性能影响较大，并且这对注册中心来说并不需要。4、cp 模型来说 zk 并不适合注册中心的高可用 5、zk 选举制度也不适合做注册中心（再选举 leader 时会暂停对外服务）

eureka

eureka分为两个组件 一个服务端 eureka server和客户端 eureka client

eureka client

• 服务下线 eureka client 在程序关闭时向 server 发送取消请求，发送请求后该客户端实例信息将从 eureka server 的实例注册表中删除，下线请求需要调用相应的接口 discoveryManager.getInstance().shutdownComponent();

• 获取注册列表信息 client 从服务器获取注册列表信息，并将其缓存到本地。客户端会使用该信息查找其他服务，从而进行远程调用，该注册列表信息定期（30 秒）更新一次如果由于某些原因导致注册列表信息不能及时匹配，eureka client 则会从新获取整个注册表信息

eureka server

• 服务注册服务提供者启动时，会通过 eureka client 向 server 进行注册自己的信息，eureka server 会存储该服务的信息，eureka server 内存有两层缓存机制来维护整个注册表

• 提供注册表服务消费者在调用服务时，如果客户端没有注册表的话，会从 eureka server 获取最新的注册表

• eureka client 通过注册表，心跳禁止 和 server 同步当前客户端的状态。

详细流程

• 服务提供者向 eureka server 中注册服务，eureka server 接收到注册事件会在集群中同步信息，消费端则可以从 eureka server 中获取到服务注册的服务注册信息，进而进行远程调用；提供者启动后会周期性的向 eureka server 发送心跳（默认 30 秒）以续约自己的信息。

• eureka server 在一定事件内没有接收到心跳信息时，eureka server 将会注销该服务提供者（默认 90 秒）

• eureka server 在同步注册信息时，其他的 server 也是一个 client，多个 server 间通过复制的方式完成注册表的同步

• eureka client 会缓存 server 中的信息，所以即使所有的 server 节点都宕机，服务消费者依然可以使用缓存中的信息找到服务提供者

自我保护机制

eureka server 在默认额情况下，实例在90秒内没有发送心跳就会注销该实例。但是微服务架构下通常是进程调用的，网络通信往往会有很多的的问题，比如微服务实例是没有问题的，但是实例到eureka server的网络故障，导致此实例被注销。
如果eureka server所在的分区网络有故障，则会有大量的实例被注销，这可能会严重的威胁到微服务架构的可用性，为了解决这个问题，eureka 开发了自我保护措施，如果在15分钟内超过85%的节点都没有正常的心跳，那么eureka就认为客户端与注册中心出现了网络故障，此时会进入自我保护机制。

eureka server 进入自我保护机制，出现的集中情况

1. eureka 不在从注册列表中移除因为长时间没有心跳而过期的应用

2. eureka 仍然能够接收新的服务注册和查询请求，但是不会被同步到其他的节点上

3. 当网络稳定时，当前实例新注册的信息会被同步到卡的 server 节点上去。eureka 自我保护机制时为了防止误删除服务而提供的一种机制，当少数实例失败时，则认为时实例问题，当多数实例失败时则认为是自身问题，进行自我保护措施；当客户端心跳恢复时，eureka 会自动退出自我保护机制。

eureka 集群原理

eureka server集群相互之间时通过replicate来同步数据，相互之间不区分主节点和从节点，所有的节点都是平等的，节点通过彼此相互注册来提高可用性，每个节点哟啊添加一个或者多个有效的serviceUrl指向其他节点。

如果某台 eureka server 宕机，client 的请求会自动切换到新的 eureka server 节点，恢复后，eureka 集群会再次纳入到服务器集群管理之中。

eureka server 同步原则：

• 只要有一条边将节点连接，就可以进行信息传播与同步，所以如果存在多个节点，只要将节点间两两连接起来形成通路，那么其他的注册中心都可以共享信息，

eureka server 集群之间同步状态时通过异步实现，所以不保证每个节点间的状态一定是一致的（AP），不过基本能保证最终一致；

eureka 工作流程

• server 启动完成，等待服务注册，配置了集群时，集群之间定时通过 replicate 同步注册表，每个 server 都独立存储一份完成的服务注册表。

• eureka client 启动时根据配置的 server 地址去注册服务；

• eureka client 会每隔 30s 向 server 发送一次心跳请求，证明客户端正常。

• eureka server 90s 内 没有收到某个 client 心跳请求，注册中心则认为这个服务提供者已经失效，会注销该实例

• 如果在一定事件内 eureka server 统计到大量的 client 没有发送心跳，则认为时网络异常，进入自我保护机制。

• 当 client 心跳请求恢复之后，eureka server 自动退出保护模式

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

• 服务调用时，client 会现在本地缓存寻找调取的服务，如果取不到先从注册中心刷新注册表，再 2 同步到本地缓存

• client 获取到目标服务器信息，发起服务调用

• client 程序关闭时会向 server 发送取消请求，将实例从注册表中删除。

nacos

 nacos  致力于帮助您发现，配置和管理微服务，Nacos提供了一组简单易用的特性集，帮助您快速实现动态发现、服务配置、服务元素据及流量管理。

相关特性

• 服务发现和服务健康检查 1、nacos 支持基于 DNS 和基于 RPC 的服务发现。2、nacos 提供对服务的时候健康检查，组织向不健康的主机或者服务实例发送请求。nacos 支持传输层（PING 或者 TCP）和应用层（如 HTTP、MySQL、用户自定义）的健康检查，并且 nacos 还提供了 agent 上报模式和服务端主动检测 2 种健康检查模式。

• 动态配置服务 1、动态配置服务可以让您以中心化、外部化和动态化的方式管理所有花鸟卷的应用配置和服务配置。2、动态配置消除了配置修改服务重新部署和应用重启的选哟，使配置功能加灵活 3、配置中心化让实现无状态服务变的更见简单

• 动态 DNS 服务动态 DNS 服务支持权重路由，让您更容易地实现中间层负载均衡、更灵活的路由策略、流量控制以及数据中心内网的简单 DNS 解析服务。动态 DNS 服务还能让您更容易地实现以 DNS 协议为基础的服务发现，以帮助您消除耦合到厂商私有服务发现 API 上的风险。