Nacos、Zookeeper 搞不清？15 分钟清晰梳理注册中心全套知识体系！-五八三

专栏目录

从根儿上学习微服务01：微服务的“前世今生”

从根儿上学习微服务02：如何划分微服务？

耗时一晚上，我梳理出了 2023 年微服务技术架构必会知识点！

前言

大家好，我是「周三不Coding」。

在上一篇文章中，我们梳理了微服务技术架构脉络。今天，我们开始微服务架构中的第一个板块 —— 「服务发现与注册」。

请给我 15 分钟时间，我会从 2W1H 角度，梳理清楚注册中心全套知识点：

Why – 为什么需要注册中心？（3 分钟）
What – 什么是注册中心？（3 分钟）
How – 如何对注册中心进行技术选型？（9 分钟）

对于每一个部分，为了使大家更加通俗易懂地理解与兼顾趣味性，咱们先讲故事，再说结论。

今天的故事从 ?小T 停车场项目升级「微服务架构」开始讲起，如果有不熟悉的同学，可以先看看专栏第一篇～

如果大家不想听故事，可以直接跳到每个部分的「总结」，不影响整体的阅读～

废话不多说，咱们快速进入正题！

为什么需要注册中心 & 什么是注册中心

故事

?小T 的停车场项目团队中存在两个服务，一个是车场服务，另外一个是商城服务，采用的是「SOA 架构」。

为了适应新需求、新变化，他决定将其项目升级为「微服务架构」。

于是，他便首先开始做服务拆分，经过一番深思熟虑后，他将项目拆分为了「用户服务」、「商品服务」、「车场服务」、「订单服务」、「支付服务」、「优惠券服务」、「推荐服务」、「消息服务」等十余个服务。

想要看 ?小T 是如何拆分服务的，可以看看专栏第二篇，反正上班摸鱼，闲着也是闲着嘛～

但是，服务之间存在互相调用的情况，并且调用链条可能不止有两个服务，比如说：

「车场服务」或「商城服务」调用「推荐服务」获取推荐 ID 列表，并渲染首页；
「订单服务」调用「用户服务」获取用户信息，调用「支付服务」进行付款，后续「消息服务」向用户发送下订单以及支付成功消息

那么，这些服务之间如何互相通信呢？可以通过 TCP 协议或 HTTP 协议进行网络通信。

但机智的 ?小T 很快就意识了一个问题，既然要进行网络通信，那就必须知道各个服务的地址、端口、方法等基础信息。这些信息应该如何管理呢？

?小T 想到最为直接的方法就是，通过 Map 进行管理，key 为服务名称，value 为服务的基本信息。各个服务在调用其他服务之前，先到 Map 上通过服务名称找到对应的基本信息，然后发起请求调用。

但是他分析之后，认为这一方法不满足实际需求，仍需要进一步扩展。在实际的微服务场景中，当服务上下线时，其它各个微服务需要及时获取这一信息，以免出现消息滞后而造成调用失败的问题。

?小T 仔细想了想，认为如果要保证服务的高可用，短时间内很难造出一个合适的中间件轮子。

于是，他开始寻找开源的解决方案。经过一番调研后，他了解到了「注册中心」这一组件就是专门用于解决这一需求。

总结

微服务之间存在互相调用，既然涉及到调用，那么需要考虑网络通信，进而需要知道各个服务的地址、端口等基础信息。

因此，「注册中心」应运而生，其专门用于处理服务注册、服务信息查找、服务上下线通知。

更具体地来说，负责以下三类事项：

服务发现：客户端需要订阅注册中心。在需要远程调用时，从注册中心中获取信息，然后进行方法调用
服务注册：服务提供者将地址、接口、分组等信息存放在注册中心模块，当服务上线、下线均会通知注册中心
服务管理：提供服务的上下线管理、服务配置管理、服务健康检查等功能，以保证服务的可靠性和稳定性

具体流程为：

当服务提供者上线时，会通过注册中心，注册当前服务信息，即我们之前提到的服务地址、端口、方法等，交由注册中心进行管理。
当某一服务上线、下线或服务信息变更时，其他服务可通过如下方式获取到这一变更：
- 事件监听机制： 服务监听注册中心中被订阅服务的信息，当发生变化时，通过回调机制通知该服务。
- 定时拉取机制： 服务定时从注册中心中拉取服务列表并更新。

注册中心技术选型

前置知识：CAP 理论

CAP 理论是分布式系统中的重中之重！

CAP 是 Consistency（一致性） 、Availability（可用性） 、Partition Tolerance（分区容错性） 这三个单词首字母组合。

一致性（Consistency） : 所有节点访问同一份最新的数据副本

可用性（Availability） : 非故障的节点在合理的时间内返回合理的响应（不是错误或者超时的响应）。

分区容错性（Partition Tolerance） : 分布式系统出现网络分区的时候，仍然能够对外提供服务。

CAP 并不是简单的 3 选 2，因为分区容错性是必须实现的。以分区容错性作为前提，在一致性与可用性中做选择。

micro-4

故事

?小T 经过调研之后，发现目前市面上主要有如下几种注册中心：

Zookeeper
Nacos
Eureka
Consul

首先，他对这 4 种注册中心进行了详细的调研：

Zookeeper
- Zookeeper 通过 znode 节点来存储数据。因此可以利用这一特性进行服务注册，节点用于存储服务 IP、端口、协议等信息。
  - 例如：服务提供者上线时，Zookeeper 创建该节点 – /provider/{serviceName}:{ip}:{port}
- Zookeeper 提供 Watcher 机制，可以监听相应的节点路径。因此我们可以利用这一机制监听对应的路径，一旦路径上的数据发生了变化，我们便向其他订阅该服务的服务发送数据变更消息。收到消息的服务便去更新本地缓存列表。
- Zookeeper 提供心跳检测功能，定时向各个服务提供者发送心跳请求，确保各个服务存活。如果服务一直未响应，则说明服务挂了，将该节点删除。
- Zookeeper 遵循一致性原则，即「CP」
  - 对于注册中心而言，最重要的是可用性，我们需要随时能够获取到服务提供者的信息，即使它可能是几分钟以前的旧信息。
  - 但是 Zookeeper 由于其核心算法是 ZAB，主要适用于分布式协调系统（分布式配置、集群管理等场景）。当 master 节点故障后，剩余节点会重新进行 leader 选举，导致在选举期间整个 Zookeeper 集群不可用。
Nacos
- 服务提供者启动时，会向 Nacos Server 注册当前服务信息，并建立心跳机制，检测服务状态。
- 服务消费者启动时，从 Nacos Server 中读取订阅服务的实例列表，缓存到本地。并开启定时任务，每隔 10s 轮询一次服务列表并更新。
- Nacos Server 采用 Map 保存实例信息。当配置持久化后，该信息会被保存到数据库中。
- 对于服务健康检查，Nacos 提供了 agent 上报与服务端主动监测两种模式
- Nacos 支持 CP 和 AP 架构，根据 ephemeral 配置决定
  - ephemeral = true，则为 AP
  - ephemeral = false，则为 CP
Eureka
- 服务提供者启动时，会到 Eureka Server 去注册服务
- 服务消费者会从 Eureka Server 中定时以全量或增量的方式获取服务提供者信息，并缓存到本地
- 各个服务会每隔 30s 向 Eureka Server 发送一次心跳请求，确认当前服务正常运行。若 90s 内 Eureka Server 未收到心跳请求，则将对应服务节点剔除。
- Eureka 遵循可用性原则，即「AP」。
  - Eureka 为「去中心化结构」，没有 master / slave 节点之分。只要还有一个 Eureka 节点存活，就仍然可以保证服务可用。但是可能会出现数据不一致的情况，即查到的信息不是最新的。
  - Eureka 节点收到请求后，会在集群节点间进行复制操作，复制到其他节点中。
Consul
- 服务提供者启动时，会向 Consul Server 发送一个 Post 请求，注册当前服务信息
- 服务消费者发起远程调用时，会向 Consul Server 发送一个 Get 请求，获取对应服务的全部节点信息
- Consul Server 每隔 10s 会向服务提供者发送健康检查请求，确保服务存活，并更新服务节点列表信息。
- Consul 遵循一致性原则，即「CP」

?小T 发现这 4 种组件基本上都可以满足注册中心的需求。在这种场景下，他想要选择一种成本最低、最容易上手的注册中心组件！

对于 Zookeeper，它遵循一致性原则，也就导致其可用性差一些，这对于实际业务场景是致命的。尽管久经考验的 Dubbo 框架采用 Zookeeper 作为注册中心，但 ?小T 还是更倾向于使用 OpenFeign 进行服务调用。
对于 Consul，它底层语言是 Go，更支持容器化场景，而当前项目主语言为 Java，所以 ?小T 就直接将其淘汰啦～
对于 Eureka，它很适合作为注册中心，但是其维护更新频率很低，目前国内使用的人很少，所以也不是很好的选择～

最后，?小T 选择了 Nacos，选择它的原因也比较简单：

Nacos 底层语言为 Java，天然适配 SpringBoot
Nacos 既支持 AP，又支持 CP，更加灵活
Nacos 作为 SpringCloud Alibaba 的一部分，可以很好地与 SpringCloud 进行适配，而项目后续微服务架构是基于 SpringCloud 的。
Nacos 是国内非常火的注册中心组件，由阿里巴巴开源，开源社区活跃，解决方案多，字面意思就是出了 Bug 能够很快被解决。

总结

基于上述故事，我总结了一个技术选型表格，帮助大家更加直观地学习注册中心。

	Zookeeper	Nacos	Eureka	Consul
CAP 定理	CP	AP / CP	AP	CP
通信协议	TCP	HTTP	HTTP	HTTP
存储方式	k-v 存储	k-v 存储	k-v 存储	k-v 存储
服务信息变化监听	Watch 机制	长轮询，定时拉取	长轮询，定时拉取	长轮询，定时拉取
是否支持 SpringCloud	支持	支持	支持	支持
是否支持 Dubbo	支持	支持	支持	支持