微服务注册中心如何选型？这几个维度告诉你！( 三 ) _微服务

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、端口、调用方式(协议、序列化方式)等。
该节点承担着最重要的职责，它由服务提供者(发布服务时)创建，以供服务消费者获取节点中的信息，从而定位到服务提供者真正IP，发起调用。通过IP设置为临时节点，那么该节点数据不会一直存储在 ZooKeeper 服务器上。
当创建该临时节点的客户端会话因超时或发生异常而关闭时，该节点也相应在 ZooKeeper 服务器上被删除，剔除或者上线的时候会触发Zookeeper的Watch机制，会发送消息给消费者，因此就做到消费者信息的及时更新。
Zookeeper从设计上来说的话整体遵循的CP的原则，在任何时候对 Zookeeper 的访问请求能得到一致的数据结果，同时系统对网络分区具备容错性，在使用 Zookeeper 获取服务列表时，如果此时的 Zookeeper 集群中的 Leader 宕机了，该集群就要进行 Leader 的选举，又或者 Zookeeper 集群中半数以上服务器节点不可用（例如有三个节点，如果节点一检测到节点三挂了，节点二也检测到节点三挂了，那这个节点才算是真的挂了)，那么将无法处理该请求。
所以说，Zookeeper 不能保证服务可用性。
2、EurekaNetflix我感觉应该是在酝酿更好的东西的，下面我们重点还是来介绍Ereka 1.x相关的设计。

文章插图
Eureka由两个组件组成：Eureka服务端和Eureka客户端。Eureka服务器用作服务注册服务器。Eureka客户端是一个JAVA客户端，用来简化与服务器的交互、作为轮询负载均衡器，并提供服务的故障切换支持。
Eureka的基本架构，由3个角色组成：

Eureka Server

提供服务注册和发现功能；

Service Provider服务提供方，将自身服务注册到Eureka，从而使服务消费方能够找到；
Service Consumer服务消费方，从Eureka获取注册服务列表，从而能够消费服务

文章插图
Eureka 在设计时就紧遵AP原则，Eureka Server 可以运行多个实例来构建集群，解决单点问题，实例之间通过彼此互相注册来提高可用性，是一种去中心化的架构，无 master/slave 之分，每一个实例都是对等的，每个节点都可被视为其他节点的副本。
在集群环境中如果某台 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还在，就能保证注册服务可用，只不过查到的信息可能不是最新的（不保证强一致性）。