说清eureka、zookepeer、nacos三者的关系

前言

随着微服务被各大企业应用在项目中，微服务的框架也被更多人学习和使用，但是大部分情况下都是停留在应用层，俺也是一样，所以写springcloud这个系列和大家交流下心得，有什么不对的地方欢迎指出，看完记得一键三连(⊙o⊙)

一、演变过程

  1.1 服务注册和发现基本概念

服务注册：将某个或者某些服务的信息（模块的ip和端口）注册到一个公用的组件上。
服务发现：新注册的模块信息能够被其他调用者发现，无论是服务的新增还是服务的剔除都可以知晓。


  1.2 web1.0数据请求模型框架
在传统的项目框架中，没有服务的注册和发现组件，因为当时的服务架构比较简单，都是单体应用服务，如下图所示


这里不存在，服务的注册和发现因为这是一个单体的服务，足够应对当时的网络用户需求，但是所着科技的进步和社会的发展，这种单体的应用架构不足以支持业务的发展，来到了2.0版本

  1.3 web2.0数据请求模型框架
随着用户变多，单体服务扛不住用户的请求压力时，我们将服务进行水平扩展，增加服务器，来应对用户的请求，用户的请求经过nginx来进行负载均衡到后面的服务器，如下图


这种架构虽然可以抗住用户的请求，但是服务的信息是配置在nginx上面，如果需要进行增加模块或者对一些应用进行扩展，还需要在nginx上面配置一遍，对运维人员非常不友好，而且服务太多了不好管理，来到了3.0版本——微服务

  1.4 web3.0微服务框架
微服务即每个应用抽取出来成为一个独立的服务，部署在相同或者不同的服务器上面，彼此之间独立解耦 如下图

这种架构虽然解耦好扩展，但是随着业务的发展后面服务越来越多，服务的管理越来越复杂，如果进行服务之间的调用，可能需要将各个服务的信息写入数据库等其他地方，这种情况下服务的地址就是写死的很不容易进行扩展，所以便出现了服务管理组件

我们一起来思考下一个服务管理组件需要有哪些功能？

1、服务的注册：各个服务的信息可以注册在这个组件上面
2、服务的发现：服务注册在这个组件上面之后可以被其他服务获取
3、服务的治理：服务的生命状态需要被时刻关注和管理，当服务宕机或者异常时需要进行剔除等
4、服务的负载均衡：对服务的调用采用一定的负载算法来提高服务的高可用
…

二、eureka简单介绍

  2.1 常见的服务管理组件
现在常见的服务管理组件有eureka、zookeeper以及nacos，下面我们来逐个分析下这几个组件

  1.1、eureka组件

上图中比较简单的几个角色：
eureka:服务的注册中心，主要是保存服务的信息，可以进行搭建集群来提高注册中心的高可用
提供者:将自己的服务信息注册到eureka上面供消费者消费，同时也将获取注册表信息到本地
消费者:在eureka上面拉取服务，然后通过httpclient进行调用服务，同时也将自己的信息注册到eureka上面

  1.2、eureka注册原理

图片来自SpringCloud微服务架构进阶

分析上图的注册过程：
1、先读eureka server的配置信息，从而知道eureka server在哪，以便后面进行注册
2、接着再读取自己的配置信息，然后将自己的信息封装在InstanceInfo实例中，等下将实例发送到eureka server中
3、通过上面步骤已经知道eureka server的地址了，此时先把注册拉取到本地缓存起来
4、将上面封装的InstanceInfo实例发送到eureka server进行注册，然后初始化心跳检测以及缓存刷新（这些都是通过开启后台线程完成的）
5、再次拉取注册表更新本地注册表信息

  1.3、eureka服务续约
1、Eureka Client通过发送心跳进行续约
2、默认情况下每30秒发送一次心跳
3、如90秒内Eureka Server未收到续约，则进行服务剔除

  1.4、eureka服务剔除
1、Eureka Client优雅退出时会发送cancel命令
2、Eureka Server收到cancel命令时会删除该节点

  1.5、eureka自我保护
1、Eureka Server会自动更新续约更新阀值
2、Eureka Server续约更新频率低于阈值则进入保护模式
3、自我保护模式下Eureka Server不会剔除任何注册信息

三、zookepper简单介绍

定义：简单的说zookepper=文件系统 监听通知机制

  3.1、文件系统
上面我们说了zookepper是文件系统的类型，下面我们来一起看下


每个子目录项如 NameService 都被称作为 znode(目录节点)，和文件系统一样，我们能够自由的增加、删除znode，在一个znode下增加、删除子znode，唯一的不同在于znode是可以存储数据的

有四种类型的znode：
  1、PERSISTENT-持久化目录节点
  指client和zookepper断开链接之后，client在zookepper上面创建的节点不会被zookepper删除，还会继续保留
  2、PERSISTENT_SEQUENTIAL-持久化顺序编号目录节点
  比如，一个user模块部署了多台服务器，在zookepper上面进行注册自己服务，zookepper会对user模块进行创建持久性顺序节点，当第一个节点宕机之后，会按照顺序取下一个节点
  3、EPHEMERAL-临时目录节点
  client在zookepper上面进注册自己的服务，当服务宕机之后,zookepper会进行删除创建的节点
  4、EPHEMERAL_SEQUENTIAL-临时顺序编号目录节点
  第四种情况和第二种情况很像，只不过，服务宕机之后就会剔除服务，不会永久保留

  3.2、监听通知机制
客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，zookeeper会通知客户端。

四、nacos简单介绍

下面我们先来看看 NACOS的界面

可以看到nacos的界面相对于 另外两个注册中心的可视化界面颜值要高一
点，下面我们一起来看看nacos的主要特点

  4.1、主要的核心功能

1、服务注册：每个服务客户端通过rest方式向服务端进行注册自己的信息
2、服务心跳：每个服务客户端都会维护一个定时心跳，向服务到证明自己是健康的，默认5s发送一次
3、服务同步：服务器集群之间相互进行通讯来保证服务信息的一致性同时提高注册中心的高可用
4、服务发现：客户端有一个定时任务，定时的去注册中心拉取各个服务的信息列表到本地
5、服务健康检查：注册中心定时检查各个服务的健康状态

  4.2、可视化界面配置的功能

1、雪崩保护：通过给每个服务实例进行配置阈值，从而实现雪崩保护
2、临时实例：当服务宕机时，注册中心会进行删除注册的服务实例
3、永久实例：即使服务宕机了，服务实例也不会被删除，和前面我们一起讨论的zookepper的持久性节点很像

上面主要介绍各个服务组件一些简单的功能点，详细介绍，下面我们来将这三个组件进行横向的比较，来看看具体的区别点

五、三者的区别

我们先来看一下对比图

我们先来说下什么是CAP原理：

C：Consistency
即一致性，访问所有的节点得到的数据应该是一样的。注意，这里的一致性指的是强一致性，也就是数据更新完，访问任何节点看到的数据完全一致，要和弱一致性，最终一致性区分开来。
A：Availability
即可用性，所有的节点都保持高可用性。注意，这里的高可用还包括不能出现延迟，比如如果节点B由于等待数据同步而阻塞请求，那么节点B就不满足高可用性。
P：Partiton tolerance
即分区容忍性，这里的分区是指网络意义上的分区。由于网络是不可靠的，所有节点之间很可能出现无法通讯的情况，在节点不能通信时，要保证系统可以继续正常服务。

通过上图我们可以清晰看到这几个微服务之间的区别，下面我们选择几点主要说明下：

1、协议：
eureka内部是AP协议，即它可以保证服务的高可用，但是对于一致性的要求不高
zookepper内部是CP协议，即它可以保证服务的数据一致性，但是对于服务的可用性要求不高
nacos内部是AP/CP协议，默认AP协议，如果对一致性的要求比较高可以切换为CP协议

2、雪崩保护：
eureka是存在雪崩保护机制的，服务注册列表会缓存再调用方的本地
zookepper没有雪崩保护机制
nacos的雪崩保护机制和eureka的原理相同，将服务的注册列表保存在调用方的本地

3、容器化部署：
eureka和zookepper暂时不支持k8s
nacos在这方面是支持的

总结

eureka、zookepper、nacos这三种注册中心在功能上没有太大区别，主要功能都是服务注册和服务发现，看你的业务场景和主体的架构选择，如果是springcloud的项目erurka是比较好的选择，当然nacos也是不错的选择

如果您感觉文章对您有帮助，记得一键三连哦，有什么不对的地方，欢迎指出，随时沟通交流

推荐

最后推荐一个朋友的公众号，可以更好的方便大家沟通和学习

这篇好文章是转载于：学新通技术网