微服务学习笔记1：注册中心

最新推荐文章于 2024-05-23 17:16:23 发布

zhaozll

最新推荐文章于 2024-05-23 17:16:23 发布

阅读量813

点赞数 25

分类专栏：微服务专栏文章标签：微服务学习笔记

本文链接：https://blog.csdn.net/qq_44689742/article/details/138134150

版权

微服务专栏专栏收录该内容

2 篇文章 0 订阅

订阅专栏

微服务学习笔记1：注册中心

本编文章仅用于个人学习笔记，文中内容部分摘抄自参考文章。

一、SpringCloud5大组件

注册中心： Eureka
负载均衡： Ribbon
远程调用： Feign
服务熔断： Hystrix
网关： Zuul/Gateway

二、SpringCloudAlibaba5大组件

注册中心 / 配置中心： Nacos
负载均衡： Ribbon
服务调用： Feign
服务保护： sentinel
服务网关： Gateway

三、不同RPC框架的注册中心

服务注册表是一个可用的服务实例的数据库，是一个分布式的KV数据库。

1. Eureka — SpringCloud

Eureka Server 集群当中的每个节点都通过 Replicate (复制) 来同步数据，没有主节点和从节点之分，所有节点都是平等的而且数据都保持一致。
因为节点之间通过异步方式进行数据同步，不保证强一致性，保证可用性，所以是AP (高可用性和分区容错性)。

1.1 服务注册与发现的工作流程

假设 Eureka Server 已经启动，Eureka Client (服务提供者) 启动时把服务注册到Eureka Server。
Eureka Client (服务提供者) 每 30 秒 (默认 30 秒，可以进行配置) 向 Eureka Server 发送 http 请求 (即心跳)，所谓的服务续约。
Eureka Client (服务提供者) 应用关闭时会发 http 请求到 Eureka Server，服务端接受请求后把该实例剔除。
Eureka Server 90 秒没有收到 Eureka Client (服务提供者) 的心跳，则剔除该 Eureka Client (服务提供者) 实例。
Eureka Client (服务消费者) 定时调用 Eureka Server 接口获取服务列表更新本地缓存。
Eureka Client (服务消费者) 远程调用服务时，先从本地缓存找，如果找到则直接发起服务调用，如果没有则到 Eureka Server 获取服务列表缓存到本地后再发起服务调用。
如果服务提供者有集群，则服务消费者会利用负载均衡算法选择一个进行调用。

1.2 Eureka的自我保护机制

在默认的配置下，Eureka Server 在默认的90秒没有得到服务提供者的心跳，则注销该实例。但是因为微服务跨进程调用，网络通信往往会面临各种问题。比如微服务状态正常，但是因为网络分区故障时，Eureka Server 注销服务实例则会让大部分微服务不可用，这很危险，因为服务本身是没有问题的。
为了解决这个问题，Eureka有自我保护机制。通过在 Euraka Server 配置如下参数，可以启动保护机制。

eureka.server.enable-self-preservation=true;

它的原理是，当 Eureka Server 节点在短时间内丢失过多的服务提供者客户端时 (可能发生了网络故障)，那么这个节点将进入自我保护模式，不再注销任何微服务，当网络故障恢复后，该节点会自动退出自我保护模式。
具体体现在当 Eureka Server 90 秒没有收到 Eureka Client (服务提供者) 的心跳时，不直接剔除该 Eureka Client (服务提供者) 实例。而是统计 15 分钟内是否存在 85% 的 Eureka Client (服务提供者) 没有发送心跳，如果是则进行自我保护。

1.3 注册中心内部同步

Eureka Server 集群中的各个节点之间采用纯异步复制的方式进行数据同步。
每个 Eureka Server 节点都通过 PeerEurekaNodes 管理其他服务器节点，并通过 http 进行通信。
当任意节点收到服务实例的注册、续约、注销请求时，除了在本地更新服务注册表外，还会将这些变更广播给集群中的其它节点。
其他节点接收到广播过来的服务状态变化消息后，在本地进行相应的更新操作，从而保证整个集群内的服务注册表信息一致。

2. Zookeeper — Dubbo

Zookeeper 支持 CP (一致性和分区容错性)。
当集群中有节点宕机则需要选举 leader (FastLeaderElection)，选举过程需要 30 到 120 秒。
选举过程中 ZK 集群不可用 (不能使用服务注册、服务发现)，牺牲时间来保证数据一致性。

2.1 服务注册与发现的工作流程

假设 ZK 已经启动，服务提供者启动时把服务注册到 ZK 注册中心。(同Eureka)
ZK 注册中心和服务提供者之间建立一个 Socket 长连接，ZK 注册中心定时向每个服务提供者发数据包，如果服务提供者没有响应，则剔除该服务提供者实例，把更新后的服务列表发送给所有服务消费者 (即通知)。
服务消费者启动时，到 ZK 注册中心获取一份服务列表缓存到本地供以后使用。
服务消费者远程调用服务时，先从本地缓存找，如果找到则直接发起服务调用，如果没有则到 ZK 注册中心获取服务列表缓存到本地后再发起服务调用。
当其中一个服务提供者宕机或者正常关闭时，ZK 注册中心会把该节点剔除，并通知所有服务消费者更新本地缓存。
当这个服务提供者正常启动后，ZK 注册中心也能感知到，并通知所有服务消费者更新本地缓存。

2.2 注册中心内部同步

原子广播协议 (ZAB)：当一个客户端向 ZK 注册或注销服务时，请求会被发送给 Leader，Leader接收到写请求后，会将这个变更提案 (Proposal) 提交到内部事务日志，并且通过 ZAB 协议以原子性的方式广播给所有的 Follower 节点。
Follower同步：Follower 节点接收到 Proposal 后，在本地持久化存储 (通常是磁盘文件)，并在成功应用该更新后向 Leader 发送 ACK 确认消息。一旦 Leader 收到半数以上 Follower 的 ACK，那么这个更新就被认为已提交并完成同步过程。

3. Nacos — SpringCloudAlibaba

Nacos 从 1.0 版本选择 AP 和 CP 混合形式实现注册中心，默认情况下使用 AP 形式保证服务的可用性。
CP 形式底层采用 Raft 协议保证数据的一致性问题。

3.1 服务注册与发现的工作流程

假设 Nacos Server 已经启动，服务提供者启动时把服务注册到 Nacos 注册中心。
服务提供者注册成功后，定时发 http 请求 (即心跳) 到注册中心，表明自身服务实例可用。
如果注册中心长时间没有收到服务提供者的心跳，则剔除该实例。
服务消费者发现服务支持两种方式：
- 1）主动请求注册中心获取服务列表 (不推荐)。
- 2）订阅注册中心的服务并提交一个 Listener，如果注册中心的服务有变更，由 Listener 来通知服务消费者更新本地服务列表。
服务消费者获取服务相关信息进行远程调用。

在 Nacos 都停止的情况下，服务消费者依然能通过本地服务列表访问服务提供者。