随着单体应用的拆分,我们面临的首要问题就是采用哪种方式实现服务间的调用,像之前单体应用可能直接在配置或数据库保存调用方的域名 IP 信息等。
但拆分后服务实例信息众多,且随着服务动态扩缩容,服务运行时信息一直变化,那么我们就需引入注册中心帮助我们解决这类问题了。
今天我们来聊一聊微服务架构中的服务注册与发现有哪些?Zookeeper、Eureka、Nacos、Consul都有什么区别,他们的实现原理是什么?
引入注册中心后
在微服务架构中,服务注册与发现是一个至关重要的功能。它确保了分布式系统中各个微服务之间能够动态地相互定位和通信。常见的服务注册中心有 Eureka、Zookeeper、Consul 和 Nacos
我们来看下实际项目中要如何选择合适的注册中心呢?
Eureka 是由 Netflix 提供的服务注册与发现框架,通常用于大规模的微服务系统。它的架构分为两部分:Eureka Server 和 Eureka Client,这是 Eureka 的架构图。
“那么,Eureka 是如何保证 AP 的呢?
“什么是 Eureka 的自我保护机制?
所以 Eureka 遵循的是 AP(Availability + Partition tolerance)。它牺牲了数据一致性,尤其是在网络分区发生时。Eureka 实现了 "最终一致性" 的策略,允许系统在出现故障时继续提供可用的服务。
“Zookeeper 是如何实现注册中心的呢?
Zookeeper 的数据模型基于一种叫做 ZNode(Zookeeper 节点)的概念,在 Zookeeper 中,服务注册和发现的核心思想是利用临时节点来存储服务实例的信息。具体过程如下:
存储路径示例:
/services/payment-service/instance-1
/services/payment-service/instance-2
//payment-service:支付服务名称
//instance-1:实例唯一标识符,Ip端口信息。
ZooKeeper 是基于 CP 来设计的,即任何时刻对 ZooKeeper 的访问请求能得到一致的数据结果,同时系统对网络分割具备容错性,但是它不能保证每次服务请求的可用性。
从实际情况来分析,在使用 ZooKeeper 获取服务列表时,如果 zookeeper 正在选主,或者 ZooKeeper 集群中半数以上机器不可用,那么将无法获得数据。所以说,ZooKeeper 不能保证服务可用性。
Nacos 的关键特性:
Nacos 生态图
如 Nacos 全景图所示,Nacos 无缝支持一些主流的开源生态。
Nacos 作为注册中心架构图
Nacos 作为注册中心,它是支持户根据需求选择 一致性优先(CP) 或 可用性优先(AP) 模式的。
可以通过更改 Nacos 的配置文件 conf/application.properties 切换 AP 或 CP 模式:
nacos.core.protocol.distro.data.sync.mode
Raft表示CP模式,Async表示AP模式
默认情况下,Nacos 会采用 AP 模式,因为大多情况下作为注册中心,微服务架构更看重它对服务注册发现高可用的要求。
Consul 是 HashiCorp 公司推出的开源工具,Consul 由 Go 语言开发,部署起来非常容易,只需要极少的可执行程序和配置文件,具有绿色、轻量级的特点。
Consul 的特点:
**Consul 架构图 **
由上图可看出,Consul 分为 Client 和 Server 两种节点(所有的节点也被称为 Agent):
Consul 采用的 Raft 协议来保证集群内多个节点的数据一致性,所以是采用的 CP 模式。
最后,我们来看下各注册中心的对比:
Eureka | Zookeeper | Nacos | Consul | |
---|---|---|---|---|
一致性协议 | AP | CP | CP、AP | CP |
健康检查 | 心跳 | Keep Alive | TCP/HTTP/MYSQL | TCP/HTTP/gRPC/Cmd |
负载均衡策略 | Ribbon | -- | 权重/metadata/Selector | Fabio |
访问协议 | HTTP | TCP | HTTP/DNS | HTTP/DNS |
多数据中心 | 支持 | 不支持 | 支持 | 支持 |
跨注册中心同步 | 支持 | 不支持 | 支持 | 支持 |
SpringCloud 集成 | 支持 | 支持 | 支持 | 支持 |
K8S 集成 | 支持 | 支持 | 支持 | 支持 |