springcloud四个注册中心的比较

Posted 2023-04-15

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了springcloud四个注册中心的比较相关的知识，希望对你有一定的参考价值。

参考技术A springcloud是一个非常优秀的微服务框架，要管理众多的服务，就需要对这些服务进行治理，也就是我们说的服务治理 , 服务治理的作用就是在传统的rpc远程调用框架中，管理每个服务与每个服务之间的依赖关系，可以实现服务调用、负载均衡、服务容错、以及服务的注册与发现。
如果微服务之间存在调用依赖，就需要得到目标服务的服务地址，也就是微服务治理的服务发现。要完成服务发现，就需要将服务信息存储到某个载体，载体本身即是微服务治理的服务注册中心，而存储到载体的动作即是服务注册。
springcloud支持的注册中心有 Eureka 、 Zookeeper 、 Consul 、 Nacos

Spring Cloud Netflix 在设计 Eureka 时就紧遵AP原则,Eureka Server 也可以运行多个实例来构建集群，解决单点问题，但不同于 ZooKeeper 的选举 leader 的过程，Eureka Server 采用的是Peer to Peer 对等通信。这是一种去中心化的架构，无 master/slave 之分，每一个 Peer 都是对等的。在这种架构风格中，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点。每个节点都可被视为其他节点的副本。

在集群环境中如果某台 Eureka Server 宕机，Eureka Client 的请求会自动切换到新的 Eureka Server 节点上，当宕机的服务器重新恢复后，Eureka 会再次将其纳入到服务器集群管理之中。当节点开始接受客户端请求时，所有的操作都会在节点间进行复制（replicate To Peer）操作，将请求复制到该 Eureka Server 当前所知的其它所有节点中。

Eureka的集群中，只要有一台Eureka还在，就能保证注册服务可用（保证可用性），只不过查到的信息可能不是最新的（不保证强一致性）。除此之外，Eureka还有一种自我保护机制，如果在15分钟内超过85%的节点都没有正常的心跳，那么Eureka就认为客户端与注册中心出现了网络故障，此时会出现以下几种情况:

因此，Eureka可以很好的应对因网络故障导致部分节点失去联系的情况，而不会像zookeeper那样使得整个注册服务瘫痪

与 Eureka 有所不同，Apache Zookeeper 在设计时就紧遵CP原则，即任何时候对 Zookeeper 的访问请求能得到一致的数据结果，同时系统对网络分割具备容错性，但是 Zookeeper 不能保证每次服务请求都是可达的。从 Zookeeper 的实际应用情况来看，在使用 Zookeeper 获取服务列表时，如果此时的 Zookeeper 集群中的 Leader 宕机了，该集群就要进行 Leader 的选举，又或者 Zookeeper 集群中半数以上服务器节点不可用（例如有三个节点，如果节点一检测到节点三挂了，节点二也检测到节点三挂了，那这个节点才算是真的挂了），那么将无法处理该请求。所以说，Zookeeper 不能保证服务可用性。

Consul 是 HashiCorp 公司推出的开源工具，用于实现分布式系统的服务发现与配置。Consul 使用 Go 语言编写，因此具有天然可移植性（支持Linux、windows和Mac OS X）。Consul 内置了服务注册与发现框架、分布一致性协议实现、健康检查、Key/Value 存储、多数据中心方案，不再需要依赖其他工具（比如 ZooKeeper 等），使用起来也较为简单。
Consul 遵循CAP原理中的CP原则，保证了强一致性和分区容错性，且使用的是Raft算法，比zookeeper使用的Paxos算法更加简单。虽然保证了强一致性，但是可用性就相应下降了，例如服务注册的时间会稍长一些，因为 Consul 的 raft 协议要求必须过半数的节点都写入成功才认为注册成功；在leader挂掉了之后，重新选举出leader之前会导致Consul 服务不可用。

Nacos是阿里开源的，Nacos 支持基于 DNS 和基于 RPC 的服务发现。Nacos除了服务的注册发现之外，还支持动态配置服务。动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。动态配置消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。一句话概括就是Nacos = 注册中心 + 配置中心。

这四个组件虽然都实现了注册中心的功能，但是他们的功能和实现方式都有不同的地方，也各有各的优点,单从注册中心方面来比价四个注册中心(如果不了解 CAP定理可先阅读下一章节):

CAP原则的精髓就是要么AP，要么CP，要么AC，但是不存在CAP。如果在某个分布式系统中数据无副本，那么系统必然满足强一致性条件，因为只有独一数据，不会出现数据不一致的情况，此时C和P两要素具备，但是如果系统发生了网络分区状况或者宕机，必然导致某些数据不可以访问，此时可用性条件就不能被满足，即在此情况下获得了CP系统，但是CAP不可同时满足。

因此在进行分布式架构设计时，必须做出取舍。当前一般是通过分布式缓存中各节点的最终一致性来提高系统的性能，通过使用多节点之间的数据异步复制技术来实现集群化的数据一致性。通常使用类似 memcached 之类的 NOSQL 作为实现手段。虽然 memcached 也可以是分布式集群环境的，但是对于一份数据来说，它总是存储在某一台 memcached 服务器上。如果发生网络故障或是服务器死机，则存储在这台服务器上的所有数据都将不可访问。由于数据是存储在内存中的，重启服务器，将导致数据全部丢失。当然也可以自己实现一套机制，用来在分布式 memcached 之间进行数据的同步和持久化，但是实现难度是非常大的

例如，根据CAP定理将NoSql数据分成了满足CA原则、满足CP原则和满足AP原则的三大类:

SpringCloud Alibaba——Nacos服务注册与配置中心（二作为服务配置中心）

1.开篇

为什么叫Nacos？前四个字母分别为Naming和Configuration的前两个字母，最后的s为Service。

Nacos是什么：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

在之前学习SpringCloud H版的时候，一般来说是用Eureka作为服务注册中心，Config + Bus来进行服务配置。那么现在有了阿里的Nacos，就完全可以替代前面说的那三个，也即：Nacos = Eureka + Config + Bus。

Nacos的官方文档：https://nacos.io/zh-cn https://github.com/alibaba/nacos/

https://spring-cloud-alibaba-group.github.io/github-pages/hoxton/en-us/index.html#_spring_cloud_alibaba_nacos_discovery

有关Nacos的下载安装请参考：https://blog.csdn.net/weixin_43823808/article/details/119480692

上一篇文章说到Nacos作为服务注册中心的配置与实现，这篇文章来说一下Nacos作为服务配置中心。首先一个很大的区别就是Nacos作为服务注册中心的时候，我们的微服务模块只需要配置一个yml就可以了；而现在作为服务配置中心则需要两个！！！

原因：Nacos同springcloud-config一样，在项目初始化时，要保证先从配置中心进行配置拉取，拉取配置之后，才能保证项目的正常启动。springboot中配置文件的加载是存在优先级顺序的，bootstrap优先级高于application。（也就是我必须先获取总的配置文件信息，然后再配置自己私有的信息）

之前学SpringCloud H版的Config + Bus时，为了实现动态刷新，需要@RefreshScope注解，还需要写其他很多东西。那么现在有了Nacos，有很多配置都不需要再写了，但是仍然需要这个注解 @RefreshScope //在控制器类加入@RefreshScope注解使当前类下的配置支持Nacos的动态刷新功能。

更多配置信息，直接参考Nacos的官方文档：https://nacos.io/zh-cn/docs/quick-start-spring-cloud.html

最终读取到配置文件的公式：${spring.application.name}-${spring.profiles.active}.${spring.cloud.nacos.config.file-extension}

2.项目源码

github源码地址：https://github.com/2656307671/SpringCloud-Alibaba-Nacos

gitee源码地址：https://gitee.com/szh-forever-young/SpringCloud-Alibaba-Nacos

下面先演示Nacos作为服务配置中心的基本配置。这里只对应3377这一个微服务模块。

首先在Nacos的配置管理---配置列表中，新增一个配置文件、内容如下。（关于Data Id、Group、Namespace后面再说）

配置文件添加成功之后，我们到浏览器中测试，可以正常访问。

此时对刚刚添加的配置文件做一个修改，将version改为2。然后不用重启3377，直接再到浏览器中刷新刚才的访问页面，可以看到version也更新成了2。

这就是 @RefreshScope 注解实现了动态刷新功能。

下面再来说一下Nacos作为服务配置中心的分类配置。（什么是Data Id、Group、Namespace？）

实际开发中，通常一个系统会准备dev开发环境、test测试环境、prod生产环境。如何保证指定环境启动时服务能正确读取到Nacos上相应环境的配置文件呢？

此时就需要Data Id、Group、Namespace这三者了。类似Java里面的package名和类名，最外层的namespace是可以用于区分部署环境的，Group和DataID逻辑上区分两个目标对象。

默认情况：Namespace=public，Group=DEFAULT_GROUP，默认Cluster是DEFAULT。Data Id ＜ Group ＜ Namespace。Namespace类似于Java中的某个项目、某个微服务模块；Group类似于当前Java项目的某个包；Data Id类似于Java当前Java项目的某个包下的某个类。