微服务注册中心zookeeper&Eureka

微服务注册中心zookeeper&Eureka

首先，大家要明确一点微服务注册中心是一个重要的组件，解决的是服务的注册和发现的问题，而zookeeper，Eureka都只是其中一款落地实现的产品，再比如Nacos也是如此，所以关键是掌握注册中心的工作原理，组件的使用，诸如配置，安装，这些都是常规步骤，没有什么特别的。

1，zookeeper
zookeeper的核心主要是包含两个部分：服务信息的管理和变更通知机制（watch）

服务注册，就是在zookeeper的服务器上创建一个节点，而且是临时节点，保存着服务的地址信息

为什么是临时节点？
因为一旦服务节点宕机，则zookeeper可以自动将该节点删除

服务发现，就是去获取zookeeper上面的节点信息，获取到提供该服务的地址列表信息

这样当消费者去调用服务提供者，就可以采用负载均衡策略，去访问其中一个提供者。

所谓监听机制，当服务提供者某个节点发生故障，这个时候服务端的临时节点会被删除，上层的父节点就相当发生了变化，所以可以基于监听机制通知客户端（服务消费者）当前服务列表发生变化了，客户端再次去获取最新的服务列表信息。

2，Eureka
1，包含两个组件

Eureka Server 注册中心服务端，提供了服务的注册和发现（相当于zookeeper的作用）
Eureka Client 注册中心客户端（相当于之前的生产者和消费者）， 需要将本身提供的服务注册到EurekaServer

2，两个关键的时间参数

一个是每隔30s，客户端会发送心跳包给EurekaServer，告知健康状态，表示还活着；
一个是每隔30s，客户端会去找EurekaServer拉取最新的注册表信息，刷新本地的缓存列表；

3，两者集群模型的差别
注册中心作为微服务架构中非常关键的组件，所以其可用性非常重要，所以我们来简单说说其集群架构的区别。

zk：CP设计(强一致性)，目标是一个分布式的协调系统，用于进行资源的统一管理。
当节点crash后，需要进行leader的选举，在这个期间内，zk服务是不可用的。

eureka：AP设计（高可用），目标是一个服务注册发现系统，专门用于微服务的服务发现注册。

Eureka各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而Eureka的客户端在向某个Eureka注册时如果发现连接失败，会自动切换至其他节点，只要有一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性）。

同时当eureka的服务端发现85%以上的服务都没有心跳的话，它就会认为自己的网络出了问题，就不会从服务列表中删除这些失去心跳的服务，同时eureka的客户端也会缓存服务信息。eureka对于服务注册发现来说是非常好的选择。

zookeeper，奇数台做集群，CP（强一致性）
eureka，只需要两台以上即可，AP（可用性）

Eureka的自我保护机制基本机制：

微服务在注册成功之后，会每隔30秒发送一次心跳包到服务注册中心，通知 Eureka Server
该实例仍然健康运行。如果超过90秒没有发送更新，则服务注册中心会从将该服务从服务列表中移除。

Eureka Server在运行期间，会统计心跳失败的比例在15分钟之内是否低于85%，如果出现这种情况，Eureka Server会
将当前的实例注册信息保护起来，同时提示这个警告。保护模式主要用于一组客户端和Eureka Server
之间存在网络分区场景下的保护作用。一旦进入保护模式，Eureka
Server将会尝试保护其服务注册表中的信息，不再删除服务注册表中的数据（也就是不会注销任何微服务）
验证完自我保护机制开启后，并不会马上呈现到web上，而是默认需等待 5 分钟（可以通过
eureka.server.wait-time-in-ms-when-sync-empty 配置），即 5
分钟后你会看到下面的红字提示信息。

#开发阶段，我们可以关闭自我保护机制，提高我们的开发效率。正式上线后，我们不要关闭保护模式 server:
enable-self-preservation: false #关闭自我保护
eviction-interval-timer-in-ms: 3000 #剔除服务间隔，单位毫秒

EurekaServer的注册表存储结构
使用的是ConcurrentHashMap
AbstractInstanceRegistry抽象类