目录
一、演变历程
服务注册发现是一个经久不衰的话题，Dubbo 早期开源时默认的注册中心 ZooKeeper 最早进入人们的视线，并且在很长一段时间里，人们将注册中心和 ZooKeeper 划上了等号，可能 ZooKeeper 的设计者都没有想到这款产品对微服务领域造成了如此深厚的影响，直到 Spring Cloud 开始流行，其自带的 Eureka 进入了人们的视野，人们这才意识到原来注册中心还可以有其他的选择。再到后来，热衷于开源的阿里把目光也聚焦在了注册中心这个领域， Nacos 横空出世。
Kirito 在做注册中心选型时的思考：曾经我没得选，现在我只想选择一个好的注册中心，它最好是开源的，这样开放透明，有自我的掌控力。不仅要开源，它还要有活跃的社区，以确保特性演进能够满足日益增长的业务需求，出现问题也能及时修复，功能还要很强大。除了满足注册服务、推送服务外，还要有完善的微服务体系中所需的功能。最重要的，它还要稳定，最好有大厂的实际使用场景背书，证明这是一个经得起实战考验的产品。当然，云原生特性，安全特性也是很重要的······
似乎 Kirito 对注册中心的要求实在是太高了，但这些五花八门的注册中心呈现在用户眼前，总是免不了一番比较。正如上面所言，功能特性、成熟度、可用性、用户体验度、云原生特性、安全都是可以拿出来做比较的话题。今天这篇文章重点介绍的是 Nacos 在可用性上的体现，希望借助于这篇文章，能够让你对 Nacos 有一个更加深刻的认识。
二、eureka、zookepeer、nacos三者关系
1、服务注册和发现基本概念
服务注册：将某个或者某些服务的信息（模块的ip和端口）注册到一个公用的组件上。
服务发现：新注册的模块信息能够被其他调用者发现，无论是服务的新增还是服务的剔除都可以知晓。
2、web1.0数据请求模型框架
在传统的项目框架中，没有服务的注册和发现组件，因为当时的服务架构比较简单，都是单体应用服务，如下图所示
这里不存在，服务的注册和发现因为这是一个单体的服务，足够应对当时的网络用户需求，但是所着科技的进步和社会的发展，这种单体的应用架构不足以支持业务的发展，来到了2.0版本
3、web2.0数据请求模型框架
随着用户变多，单体服务扛不住用户的请求压力时，我们将服务进行水平扩展，增加服务器，来应对用户的请求，用户的请求经过nginx来进行负载均衡到后面的服务器，如下图
这种架构虽然可以抗住用户的请求，但是服务的信息是配置在nginx上面，如果需要进行增加模块或者对一些应用进行扩展，还需要在nginx上面配置一遍，对运维人员非常不友好，而且服务太多了不好管理，来到了3.0版本——微服务
4、web3.0微服务框架
微服务即每个应用抽取出来成为一个独立的服务，部署在相同或者不同的服务器上面，彼此之间独立解耦 如下图
这种架构虽然解耦好扩展，但是随着业务的发展后面服务越来越多，服务的管理越来越复杂，如果进行服务之间的调用，可能需要将各个服务的信息写入数据库等其他地方，这种情况下服务的地址就是写死的很不容易进行扩展，所以便出现了服务管理组件
我们一起来思考下一个服务管理组件需要有哪些功能？1、服务的注册：各个服务的信息可以注册在这个组件上面
2、服务的发现：服务注册在这个组件上面之后可以被其他服务获取
3、服务的治理：服务的生命状态需要被时刻关注和管理，当服务宕机或者异常时需要进行剔除等
4、服务的负载均衡：对服务的调用采用一定的负载算法来提高服务的高可用
三、eureka简单介绍
上图中比较简单的几个角色
eureka:服务的注册中心，主要是保存服务的信息，可以进行搭建集群来提高注册中心的高可用
提供者:将自己的服务信息注册到eureka上面供消费者消费，同时也将获取注册表信息到本地
消费者:在eureka上面拉取服务，然后通过httpclient进行调用服务，同时也将自己的信息注册到eureka上面
eureka注册原理
分析上图的注册过程
1、先读eureka server的配置信息，从而知道eureka server在哪，以便后面进行注册
2、接着再读取自己的配置信息，然后将自己的信息封装在InstanceInfo实例中，等下将实例发送到eureka server中
3、通过上面步骤已经知道eureka server的地址了，此时先把注册拉取到本地缓存起来
4、将上面封装的InstanceInfo实例发送到eureka server进行注册，然后初始化心跳检测以及缓存刷新（这些都是通过开启后台线程完成的）
5、再次拉取注册表更新本地注册表信息
eureka服务续约
1、Eureka Client通过发送心跳进行续约
2、默认情况下每30秒发送一次心跳
3、如90秒内Eureka Server未收到续约，则进行服务剔除
eureka服务剔除
1、Eureka Client优雅退出时会发送cancel命令
2、Eureka Server收到cancel命令时会删除该节点
eureka自我保护
1、Eureka Server会自动更新续约更新阀值
2、Eureka Server续约更新频率低于阈值则进入保护模式
3、自我保护模式下Eureka Server不会剔除任何注册信息
四、zookepper简单介绍
定义：简单的说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-临时顺序编号目录节点
第四种情况和第二种情况很像，只不过，服务宕机之后就会剔除服务，不会永久保留
客户端注册监听它关心的目录节点，当目录节点发生变化（数据改变、被删除、子目录节点增加删除）时，zookeeper会通知客户端。
五、nacos简单介绍
下面我们先来看看NACOS的界面
主要的核心功能
1、服务注册：每个服务客户端通过rest方式向服务端进行注册自己的信息
2、服务心跳：每个服务客户端都会维护一个定时心跳，向服务到证明自己是健康的，默认5s发送一次
3、服务同步：服务器集群之间相互进行通讯来保证服务信息的一致性同时提高注册中心的高可用
4、服务发现：客户端有一个定时任务，定时的去注册中心拉取各个服务的信息列表到本地 5、服务健康检查：注册中心定时检查各个服务的健康状态
6、雪崩保护：通过给每个服务实例进行配置阈值，从而实现雪崩保护
7、临时实例：当服务宕机时，注册中心会进行删除注册的服务实例
8、永久实例：即使服务宕机了，服务实例也不会被删除，和前面我们一起讨论的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在这方面是支持的
七、参考资料
主要就是做个简单的整合，方便以后查阅，以后本篇会持续更新内容的...
