几种常见的注册中心以及区别
文章目录
- 服务注册
- 服务发现
- 心跳机制
- 常见的注册中心
-
- consul
-
- client
- server
- server-leader
- raft
- 服务发现协议
- 服务注册
- 服务发现
- eureka
-
- Eureka Client
- Eureka Server
- 自我保护机制
- Eureka 集群原理
- Eurka 保证 AP
- Eurka 工作流程
- zookeeper
-
- 服务注册
- 为什么是临时节点？
- 服务发现
- 监听机制
- zookeeper功能
- zookeeper的存储结构
- zookeeper选举机制
- zookeeper应用场景
- **优点**
- nacos
-
- 概念
- 关键特性
- CAP
- consul和eureka区别
-
- consul
- eureka
- eureka和zookeeper区别
- nacos和eureka区别
- 选型建议
- 服务注册：服务进程在注册中心注册自己的元数据信息。通常包括主机和端口号，有时还有身份验证信息，协议，版本号，以及运行环境的信息。
- 服务发现：客户端服务进程向注册中心发起查询，来获取服务的信息。服务发现的一个重x
服务注册
服务注册有两种形式：客户端注册和代理注册。
客户端注册（调用方实现）
客户端注册是服务自己要负责注册与注销的工作。当服务启动后注册线程向注册中心注册，当服务下线时注销自己。
缺点
是注册注销逻辑与服务的业务逻辑耦合在一起，如果服务使用不同语言开发，那需要适配多套服务注册逻辑。
代理注册
代理注册由一个单独的代理服务负责注册与注销。当服务提供者启动后以某种方式通知代理服务，然后代理服务负责向注册中心发起注册工作。
缺点
是多引用了一个代理服务，并且代理服务要保持高可用状态。
服务发现
服务发现也分为客户端发现和代理发现。
客户端发现（调用方实现）
客户端发现是指客户端负责向注册中心查询可用服务地址，获取到所有的可用实例地址列表后客户端根据负载均衡算法选择一个实例发起请求调用。
这种方式非常直接，客户端可以控制负载均衡算法。
但是缺点也很明显，获取实例地址、负载均衡等逻辑与服务的业务逻辑耦合在一起，如果服务发现或者负载平衡有变化，那么所有的服务都要修改重新上线。
代理发现
代理发现是指新增一个路由服务负责服务发现获取可用的实例列表，服务消费者如果需要调用服务A的一个实例可以直接将请求发往路由服务，路由服务根据配置好的负载均衡算法从可用的实例列表中选择一个实例将请求转发过去即可，如果发现实例不可用，路由服务还可以自行重试，服务消费者完全不用感知。
心跳机制
如果服务有多个实例，其中一个实例出现宕机，注册中心是可以实时感知到，并且将该实例信息从列表中移出，也称为摘机。
心跳检测有主动和被动两种方式。
- 被动检测是指服务主动向注册中心发送心跳消息，时间间隔可自定义，比如配置5秒发送一次，注册中心如果在三个周期内比如说15秒内没有收到实例的心跳消息，就会将该实例从列表中移除。
- 主动检测是注册中心主动发起，每隔几秒中会给所有列表中的服务实例发送心跳检测消息，如果多个周期内未发送成功或未收到回复就会主动移除该实例
常见的注册中心
consul
consul是google开源的一个使用go语言开发的服务发现、配置管理中心服务。内置了服务注册与发现框 架、分布一致性协议实现、健康检查、Key/Value存储、多数据中心方案，不再需要依赖其他工具（比如ZooKeeper等）。服务部署简单，只有一个可运行的二进制的包。每个节点都需要运行agent，他有两种运行模式server和client。每个数据中心官方建议需要3或5个server节点以保证数据安全，同时保证server-leader的选举能够正确的进行。
client
client表示consul的client模式，就是客户端模式。是consul节点的一种模式，这种模式下，所有注册到当前节点的服务会被转发到server，本身是不持久化这些信息。
server
server表示consul的server模式，表明这个consul是个server，这种模式下，功能和client都一样，唯一不同的是，它会把所有的信息持久化的本地，这样遇到故障，信息是可以被保留的。
server-leader
中间那个server下面有leader的字眼，表明这个server是它们的老大
和其它server不一样的一点是，它需要负责同步注册的信息给其它的server，同时也要负责各个节点的健康监测。
raft
server节点之间的数据一致性保证，一致性协议使用的是raft，而zookeeper用的paxos，etcd采用的也是raft。
服务发现协议
consul采用http和dns协议，etcd只支持http
服务注册
consul支持两种方式实现服务注册
- 一种是通过consul的服务注册http API，由服务自己调用API实现注册
- 另一种方式是通过json的配置文件实现注册，将需要注册的服务以json格式的配置文件给出。consul官方建议使用第二种方式。
服务发现
consul支持两种方式实现服务发现，一种是通过http API来查询有哪些服务，另外一种是通过consul agent 自带的DNS（8600端口），域名是以NAME.service.consul的形式给出，NAME即在定义的服务配置文件中，服务的名称。DNS方式可以通过check的方式检查服务。
eureka
Eureka 包含两个组件：Eureka Server和 Eureka Client
Eureka Client
是⼀个Java客户端，⽤于简化与Eureka Server的交互；
-
服务下线
Eureka Client 在程序关闭时向 Eureka Server 发送取消请求。 发送请求后，该客户端实例信息将从 Eureka Server 的实例注册表中删除。该下线请求不会自动完成，它需要调用以下内容：
DiscoveryManager.getInstance().shutdownComponent()；
-
获取注册列表信息
Eureka Client 从服务器获取注册表信息，并将其缓存在本地。客户端会使用该信息查找其他服务，从而进行远程调用。该注册列表信息定期（每30秒钟）更新一次。每次返回注册列表信息可能与 Eureka Client 的缓存信息不同，Eureka Client 自动处理。
如果由于某种原因导致注册列表信息不能及时匹配，Eureka Client 则会重新获取整个注册表信息。 Eureka Server 缓存注册列表信息，整个注册表以及每个应用程序的信息进行了压缩，压缩内容和没有压缩的内容完全相同。Eureka Client 和 Eureka Server 可以使用 JSON/XML 格式进行通讯。在默认情况下 Eureka Client 使用压缩 JSON 格式来获取注册列表的信息。
Eureka Server
提供服务发现的能⼒，各个微服务启动时，会通过Eureka Client向Eureka Server 进⾏注册⾃⼰的信息（例如⽹络信息），Eureka Server会存储该服务的信息；
- 服务注册
服务提供者启动时，会通过 Eureka Client 向 Eureka Server 注册信息，Eureka Server 会存储该服务的信息，Eureka Server 内部有二层缓存机制来维护整个注册表 - 提供注册表
服务消费者在调用服务时，如果 Eureka Client 没有缓存注册表的话，会从 Eureka Server 获取最新的注册表 - 同步状态
Eureka Client 通过注册、心跳机制和 Eureka Server 同步当前客户端的状态。
详细流程如下
- 服务提供者向Eureka Server中注册服务， Eureka Server接受到注册事件会在集群和分区中进⾏数据同步，Application Client作为消费端（服务消费者）可以从Eureka Server中获取到服务注册信息，进⾏服务调⽤。微服务启动后，会周期性地向Eureka Server发送⼼跳（默认周期为30秒）以续约⾃⼰的信息
- Eureka Server在⼀定时间内没有接收到某个微服务节点的⼼跳， Eureka Server将会注销该微服务节点（默认90秒）
- 每个Eureka Server同时也是Eureka Client，多个Eureka Server之间通过复制的⽅式完成服务注册列表的同步
- Eureka Client会缓存Eureka Server中的信息。即使所有的Eureka Server节点都宕掉，服务消费者依然可以使⽤缓存中的信息找到服务提供者。
自我保护机制
默认情况下，如果 Eureka Server 在一定的 90s 内没有接收到某个微服务实例的心跳，会注销该实例。
但是在微服务架构下服务之间通常都是跨进程调用，网络通信往往会面临着各种问题，比如微服务状态正常，网络分区故障，导致此实例被注销。
固定时间内大量实例被注销，可能会严重威胁整个微服务架构的可用性。为了解决这个问题，Eureka 开发了自我保护机制。Eureka Server 在运行期间会去统计心跳失败比例在 15 分钟之内是否低于 85%，如果低于 85%，Eureka Server 即会进入自我保护机制。
Eureka Server 进入自我保护机制，会出现以下几种情况：
- Eureka 不再从注册列表中移除因为长时间没收到心跳而应该过期的服务
- Eureka 仍然能够接受新服务的注册和查询请求，但是不会被同步到其它节点上(即保证当前节点依然可用)
- 当网络稳定时，当前实例新的注册信息会被同步到其它节点中
Eureka 自我保护机制是为了防止误杀服务而提供的一个机制。当个别客户端出现心跳失联时，则认为是客户端的问题，剔除掉客户端；当 Eureka 捕获到大量的心跳失败时，则认为可能是网络问题，进入自我保护机制；当客户端心跳恢复时，Eureka 会自动退出自我保护机制。
Eureka 集群原理
Eureka Server 集群相互之间通过 Replicate 来同步数据，相互之间不区分主节点和从节点，所有的节点都是平等的。在这种架构中，节点通过彼此互相注册来提高可用性，每个节点需要添加一个或多个有效的 serviceUrl 指向其他节点。
如果某台 Eureka Server 宕机，Eureka Client 的请求会自动切换到新的 Eureka Server 节点。当宕机的服务器重新恢复后，Eureka 会再次将其纳入到服务器集群管理之中。当节点开始接受客户端请求时，所有的操作都会进行节点间复制，将请求复制到其它 Eureka Server 当前所知的所有节点中。
另外 Eureka Server 的同步遵循着一个非常简单的原则：
- 只要有一条边将节点连接，就可以进行信息传播与同步。所以，如果存在多个节点，只需要将节点之间两两连接起来形成通路，那么其它注册中心都可以共享信息。每个 Eureka Server 同时也是 Eureka Client，多个 Eureka Server 之间通过 P2P 的方式完成服务注册表的同步。
Eureka Server 集群之间的状态是采用异步方式同步的，所以不保证节点间的状态一定是一致的，不过基本能保证最终状态是一致的。
Eurka 保证 AP
Eureka Server 各个节点都是平等的，几个节点挂掉不会影响正常节点的工作，剩余的节点依然可以提供注册和查询服务。而 Eureka Client 在向某个 Eureka 注册时，如果发现连接失败，则会自动切换至其它节点。只要有一台 Eureka Server 还在，就能保证注册服务可用(保证可用性)，只不过查到的信息可能不是最新的(不保证强一致性)。
Eurka 工作流程
- Eureka Server 启动成功，等待服务端注册。在启动过程中如果配置了集群，集群之间定时通过 Replicate 同步注册表，每个 Eureka Server 都存在独立完整的服务注册表信息
- Eureka Client 启动时根据配置的 Eureka Server 地址去注册中心注册服务
- Eureka Client 会每 30s 向 Eureka Server 发送一次心跳请求，证明客户端服务正常
- 当 Eureka Server 90s 内没有收到 Eureka Client 的心跳，注册中心则认为该节点失效，会注销该实例
- 单位时间内 Eureka Server 统计到有大量的 Eureka Client 没有上送心跳，则认为可能为网络异常，进入自我保护机制，不再剔除没有上送心跳的客户端
- 当 Eureka Client 心跳请求恢复正常之后，Eureka Server 自动退出自我保护模式
- Eureka Client 定时全量或者增量从注册中心获取服务注册表，并且将获取到的信息缓存到本地
- 服务调用时，Eureka Client 会先从本地缓存找寻调取的服务。如果获取不到，先从注册中心刷新注册表，再同步到本地缓存
- Eureka Client 获取到目标服务器信息，发起服务调用
- Eureka Client 程序关闭时向 Eureka Server 发送取消请求，Eureka Server 将实例从注册表中删除
zookeeper
高度可靠的分布式协调
ZooKeeper是一种集中式服务，用于维护配置信息，命名，提供分布式同步和提供组服务。所有这些类型的服务都以分布式应用程序的某种形式使用。
zookeeper的核心主要是包含两个部分：服务信息的管理和变更通知机制（watch）
服务注册
就是在zookeeper的服务器上创建一个节点，而且是临时节点，保存着服务的地址信息
为什么是临时节点？
因为一旦服务节点宕机，则zookeeper可以自动将该节点删除
服务发现
就是去获取zookeeper上面的节点信息，获取到提供该服务的地址列表信息
这样当消费者去调用服务提供者，就可以采用负载均衡策略，去访问其中一个提供者。
监听机制
当服务提供者某个节点发生故障，这个时候服务端的临时节点会被删除，上层的父节点就相当发生了变化，所以可以基于监听机制通知客户端（服务消费者）当前服务列表发生变化了，客户端再次去获取最新的服务列表信息。
zookeeper功能
- 存储数据
- 监听
zookeeper的存储结构
zookeeper选举机制
zookeeper应用场景
（1）集群统一配置管理
（2）集群统一命名服务
（3）集群统一管理
（4）服务器的动态上下线感知
（5）负载均衡
优点
zookeeper 的特长是做分布式协调服务，例如 kafka、hbase、flink、hadoop 等大项目都在用 zookeeper。
用作注册中心的缺点
在大规模服务集群场景中，zookeeper 的性能也是瓶颈。zookeeper 所有的写操作都是 leader 处理的，在大规模服务注册写请求时，压力巨大，而且 leader 是单点，无法水平扩展。还有所有服务于 zookeeper 的长连接也是很重的负担。zookeeper 对每一个写请求，都会写一个事务日志，同时会定期将内存数据镜像dump到磁盘，保持数据一致性和持久性。这个动作会降低性能，而且对于注册中心来讲，是不需要的。
从 CP 模型上来讲，zookeeper 并不适合注册中心高可用的需要。
从性能上来讲，zookeeper 也无法满足注册中心大规模且频繁注册写的场景。
nacos
概念
Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。
Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。
解释来源官网：https://nacos.io/zh-cn/docs/what-is-nacos.html
关键特性
-
服务发现和服务健康监测
Nacos 支持基于 DNS 和基于 RPC 的服务发现。
Nacos 提供对服务的实时的健康检查，阻止向不健康的主机或服务实例发送请求。Nacos 支持传输层 (PING 或 TCP)和应用层 (如 HTTP、MySQL、用户自定义）的健康检查。 对于复杂的云环境和网络拓扑环境中（如 VPC、边缘网络等）服务的健康检查，Nacos 提供了 agent 上报模式和服务端主动检测2种健康检查模式。Nacos 还提供了统一的健康检查仪表盘，帮助您根据健康状态管理服务的可用性及流量。
-
动态配置服务
动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。
-
动态 DNS 服务
动态 DNS 服务支持权重路由，让您更容易地实现中间层负载均衡、更灵活的路由策略、流量控制以及数据中心内网的简单DNS解析服务。动态DNS服务还能让您更容易地实现以 DNS 协议为基础的服务发现，以帮助您消除耦合到厂商私有服务发现 API 上的风险。
-
服务及其元数据管理
Nacos 能让您从微服务平台建设的视角管理数据中心的所有服务及元数据，包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略、服务的 SLA 以及最首要的 metrics 统计数据。
注意：
Nacos集群默认采用AP方式，当集群中存在非临时实例时，采用CP模式
CAP
- C强一致性
- A可用性
- P 分区容错性
consul和eureka区别
consul
Consul则是go编写而成。
服务注册的时间会稍长一些，因为 Consul 的 raft 协议要求必须过半数的节点都写入成功才认为注册成功 ；在leader挂掉了之后，重新选举出leader之前会导致Consul 服务不可用。
Consul强一致性©带来的是（CP）
服务注册相比Eureka会稍慢一些。因为Consul的raft协议要求必须过半数的节点都写入成功才认为注册成功
Leader挂掉时，重新选举期间整个consul不可用。保证了强一致性但牺牲了可用性。
eureka
eureka就是个servlet程序，跑在servlet容器中。
Eureka保证高可用(A)和最终一致性（AP）
服务注册相对要快，因为不需要等注册信息replicate到其他节点，也不保证注册信息是否replicate成功
当数据出现不一致时，虽然A, B上的注册信息不完全相同，但每个Eureka节点依然能够正常对外提供服务，这会出现查询服务信息时如果请求A查不到，但请求B就能查到。如此保证了可用性但牺牲了一致性。 ****
eureka和zookeeper区别
zookeeper 遵守 CP
服务注册功能对一致性的要求要高于可用性，zookeeper 会出现这样一种情况, 当 master节点因为网络故障与其他节点失去联系时,剩余节点会重新进行 leader选举。选举 leader的时间太长,30~120s,目选举期间整个zookeeper 集群都是不可用的,这就导致在选举期间注册服务瘫痪。
eureka 遵守 AP
Eureka各个节点都是平等的,几个节点挂掉不会影响正常节点的工作,剩余的节点依然可以提供注册和查询服务。
而 Eureka的客户端在向某个 Eureka注册或时如果发现连接失败,则会自动切换至其它节点，只要有一台 Eureka还在,就能保证注册服务可用(保证可用性),只不过查到的信息可能不是最新的不保证强一致性)。
Eureka可以很好的应对因网络故障导致部分节点失去联系的情況,而不会像 zookeeper那样使整个注册服务瘫痪。
nacos和eureka区别
| 模块 | Nacos | Eureka | 说明 |
|---|---|---|---|
| 注册中心 | 是 | 是 | 服务治理基本功能，负责服务中心化注册 |
| 配置中心 | 是 | 否 | Eureka需要配合Config实现配置中心，且不提供管理界面 |
| 动态刷新 | 是 | 否 | Eureka需要配合MQ实现配置动态刷新，Nacos采用Netty保持TCP长连接实时推送 |
| 可用区AZ | 是 | 是 | 对服务集群划分不同区域，实现区域隔离，并提供容灾自动切换 |
| 分组 | 是 | 否 | Nacos可用根据业务和环境进行分组管理 |
| 元数据 | 是 | 是 | 提供服务标签数据，例如环境或服务标识 |
| 权重 | 是 | 否 | Nacos默认提供权重设置功能，调整承载流量压力 |
| 健康检查 | 是 | 是 | Nacos支持由客户端或服务端发起的健康检查，Eureka是由客户端发起心跳 |
| 负载均衡 | 是 | 是 | 均提供负责均衡策略，Eureka采用Ribion |
| 管理界面 | 是 | 否 | Nacos支持对服务在线管理，Eureka只是预览服务状态 |
选型建议
采用Eureka方案的考虑
- 想用Spring Cloud原生全家桶
- 想用本地文件和Git作为配置管理的,将配置与服务分开管理
- 考虑短期的稳定性
采用Nacos方案的考虑
- 想在线对服务进行上下线和流量管理
- 不想采用MQ实现配置中心动态刷新
- 不想新增配置中心生产集群
- 考虑引入Spring Cloud Alibaba生态
采用consul方案的考虑
- 运行状态发现
- 动态负载均衡
- 与Kubernetes集成和扩展
- 安全的多云服务网络
JVM内存泄漏和内存溢出的原因
JVM常用监控工具解释以及使用
Redis 常见面试题（一）
ClickHouse之MaterializeMySQL引擎（十）
三种实现分布式锁的实现与区别
线程池的理解以及使用
号外！号外！
最近面试BAT，整理一份面试资料，覆盖了Java核心技术、JVM、Java并发、SSM、微服务、数据库、数据结构等等。想获取吗？如果你想提升自己，并且想和优秀的人一起进步，感兴趣的朋友，可以在扫码关注下方公众号。资料在公众号里静静的躺着呢。。。
- 喜欢就收藏
- 认同就点赞
- 支持就关注
- 疑问就评论
一键四连，你的offer也四连
————————————————————————————————————————————————————————————————
本文作者：Java技术债务
原文链接：https://www.cuizb.top/myblog/article/1646575927
版权声明： 本博客所有文章除特别声明外，均采用 CC BY 3.0 CN协议进行许可。转载请署名作者且注明文章出处。