目录
上篇文章(探索云原生世界：Spring Cloud全方位解读——构建微服务架构的利器-CSDN博客)介绍了微服务的学习路线，以及 Spring Cloud 的组件，再来看下 Spring Cloud 的组件构成，如下图：
本文将着重介绍 Spring Cloud Alibaba 的服务治理组件 Nacos，及其工作原理，最后在对 Nacos 与 Consul进行下对比，因为Spring Cloud 后续会逐渐去 Neflix，所以这里就不介绍 Eureka了。
一、服务治理出现的原因
服务治理能解决什么问题呢？为什么会有服务治理的出现呢？先来看一个例子。
假设一个系统由两个集群组成，分别是 A 和 B，每一个服务都有10个节点，如果服务 A 调用服务 B，那怎么发起调用呢？
一种通用的做法：在服务 A 配置文件中添加服务 B 的地址，但这个地址不指向任何一台服务 B 集群中的节点，而是指向一个 VIP (虚拟 IP 地址)或者一个网关。这个 VIP 或网关背后维护了B 集群的服务节点列表，VIP 层通过负载均衡策略在将请求转到后面配置的某一台服务器，如下图：
服务 A 与服务 B 并不直接通讯，服务调用完全依靠虚拟地址来完成。如果这时需要对服务进行扩容或缩容，必须将服务器的地址配置在虚拟地址列表中。如果你的服务有上百个，这个工作量可想而知。
服务治理就是为了解决这个问题而诞生的，用服务治理来实现微服务中各个服务间的远程调用。
二、服务治理
如果我们要解决中间代理的问题，那么最好的办法就是让双方直连。因此，服务治理要解决的首要任务就是服务注册与服务发现，通过这两项技术，就能让微服务之间发起面对面的直接调用。
那么服务 A 怎么知道服务 B 中每台机器的地址呢？为了让服务 A 拿到服务 B 的地址清单，我们需要搭建一个中心化的服务注册中心，服务 B 只要将自己的信息添加到注册中心里，服务 A就能够从注册中心获取到服务 B 的所有节点列表，如下图：
具体的步骤如下
- 服务 B 集群向注册中心发起了注册，将自己的地址信息上报给注册中心，这个过程就是服务注册
- 服务 A 从注册中心获取服务 B 的服务列表，或者由注册中心将服务列表的表懂推送给服务 A，这个过程叫做服务发现
- 最后服务 A 根据负载均衡策略，从服务 B 的列表中选取某一个服务 B 的实例进行远程调用
有个过程，注册中心的角色是一个中心化的信息管理者，所有的微服务节点在启动后都将自己的地址信息添加到注册中心。在服务注册的过程中，有两个关键信息最为重要：
- 服务名称：服务名称通常默认是 spring.application.name 属性，在服务注册过程中，必须将应用服务名上报到注册中心，这样其他服务才能根据服务名称找到对应的服务节点列表。
- 地址信息：包括服务节点的IP和端口
通过服务注册和服务发现，我们已经能够实现端到端的调用了，但是如果出现了异常怎么办？缺少容错机制。
如果服务 B 因为某些原因出现了异常，不能提供服务了，这时服务 A 向服务 B 发起服务调用，就会出现超时或者服务无响应的异常，那如何处理这类问题呢？
通用的解决方案是服务探活或心跳检查。注册中心可以通过这种机制来标记出现异常的服务节点，然后将其剔除出去，在将服务地址变动推送给服务 A，这样服务 A 在发起远程调用时就能避开异常节点。
所有的服务都会在注册中心进行注册，而且每个节点都要每个一段时间向注册中心发送心跳请求，同步自己的状态。如果节点能持续发送心跳请求，则一切正常，服务可以被正常发现。如果在规定的时间内，注册中心没有收到节点的心跳包，注册中心就会标记该节点为下线状态，然后将其从服务列表中剔除。
服务剔除后，新的服务列表会发送给调用者 A，此时 A 在发起服务调用时就能避开被剔除的服务，避免异常请求。
三、Nacos
Nacos 是阿里巴巴集团开源的一款集服务发现、配置管理和服务管理于一体的云原生中间件，它的全称为“Naming and Configuration Service”，即名称服务和配置服务。
Nacos 有三个核心知识点：领域模型、数据模型和基本架构，这是整体把握 Nacos 架构的关键。
3.1 领域模型
Nacos 的领域模型描述了服务与实例之间的边界和层级关系。
Nacos的服务领域模型是以“服务”为维度构建起来的，这个服务并不是指集群中的单个服务器，而是指微服务的服务名。“服务”是 Nacos 中位于最上层的概念，在服务之下，还有集群和实例的概念。如下图：
服务
在服务这个层级上可以配置元数据和服务保护阈值等信息。服务阈值是一个 0~1 之间的数字，当服务的健康实例数与总实例的比例小于这个阈值的时候，说明能提供服务的机器已经没多少了。这时候 Nacos 会开启服务保护模式，不再主动剔除服务实例，同时还会将不健康的实例也返回给消费者。尽管这样做可能造成请求失败，但间接保证了最低限度的服务可用性。
集群
一个服务由很多服务实例组成，在每个服务实例启动的时候，我们可以设置它所属的集群，在集群这个层级上，我们也可以配置元数据。除此之外，我们还可以为持久化节点设置健康检查模式。
所谓持久化节点，是一种会保存到 Nacos 服务端的实例，即便该实例的客户端进程没有在运行，实例也不会被服务端删除，只不过 Nacos 会将这个持久化节点状态标记为不健康，Nacos 可以采用一种“主动探活”的方式来对持久化节点做健康检查。
除了持久化节点以外，大部分服务节点在 Nacos 中以“临时节点”的方式存在，它是默认的服务注册方式，从名字中我们就可以看出，这种节点不会被持久化保存在 Nacos 服务器，临时节点通过主动发送 heartbeat 请求向服务器报送自己的状态。
实例
这里所说的实例就是指服务节点，我们可以在Nacos控制台查看每个实例的 IP 地址和端口、编辑实例的元数据信息、修改它的上线 / 下线状态或者配置路由权重等等。
下图为领域模型真实的案例图
3.2 数据模型
Nacos 的数据模型有三个层次结构，分别是 Namespace、Group 和 Service/DataId，如图，这三个层次之间的包含关系：
- Namespace：即命名空间，它是最顶层的数据结构，我们可以用它来区分开发环境、生产环境等不同环境。默认情况下，所有服务都部署到一个叫做“public”的公共命名空间；
- Group：在命名空间之下有一个分组结构，默认情况下所有微服务都属于“DEFAULT_GROUP”这个分组，不同分组间的微服务是相互隔离的；
- Service/DataID：在 Group 分组之下，就是具体的微服务了，比如订单服务、商品服务等等。
通过 Namespace + Group + Service/DataID，我们就可以精准定位到一个具体的微服务。比如，调用生产环境下 A 分组的订单服务，那么对应的服务寻址的 Key 就是类似Production.A.orderService 的组合。
3.3 服务架构
Nacos的核心功能有两个，一个是 Naming Service，也就是我们用来做服务发现的模块；另一个是Config Service，用来提供配置项管理、动态更新配置和元数据的功能。
Provider APP和Consumer APP通过Open API和Nacos服务器的核心模块进行通信。这里的Open API是一组对外暴露的RESTful风格的HTTP接口。如果你对Open API里具体的接口感兴趣，可以从Nacos 官方网站获取更多的关于 Open API 的详细信息。
在 Nacos 核心模块里，Naming Service 提供了将对象和实体的“名字”映射到元数据的功能，这是服务发现的基础功能之一。例如，我想要调用 OrderService，我手里有这个服务的 Namespace 和 Group 信息，那么就可以通过 Naming Service 定位到这个服务对应的实例列表。同理，如果我有一个 DNS 名称，同样可以借助 Naming Service 获取 DNS 背后配置的 IP 列表。以上两个场景就分别对应了服务发现和 DNS 功能，这两个场景都是 Naming Service 的核心场景。
除了 Nacos Core 提供的这些功能以外，Nacos 还有一个“一致性协议”，用来确保 Nacos 集群中各个节点之间的数据一致性。Nacos 内部支持两种一致性协议，一种是侧重一致性的 Raft 协议，基于集群中选举出来的 Leader 节点进行数据写入；另一种是针对临时节点的 Distro 协议，它是一个侧重可用性（或最终一致性）的分布式一致性协议。
这里留一道思考题，后续文章在做介绍，为什么 Nacos 需要两种一致性协议呢？另外关于Nacos 的配置管理后续文章详细介绍，欢迎收藏关注。
四、Nacos 与 Consul 对比
下面主要从功能维度进行对比，选择Nacos还是Consul，应根据项目的技术栈、团队熟悉度、现有系统架构以及未来发展规划等因素综合考量。
| Nacos | Consul | |
| 一致性协议 | CP + AP | CP |
| 健康检查 | TCP/HTTP/MYSQL/CLIENT Beat | CP/HTTP/GRPC/Cmd |
| 负载均衡策略 | 权重/metadata/Selector | Fabio |
| 雪崩保护 | 有 | 无 |
| 自动注销实例 | 支持 | 不支持 |
| 访问协议 | HTTP/NDS | HTTP/NDS |
| 监听支持 | 支持 | 支持 |
| 多数据中心 | 支持 | 支持 |
| 跨注册中心同步 | 支持 | 支持 |
| SpringCloud集成 | 支持 | 支持 |
| Dubbo集成 | 支持 | 不支持 |
总得来说二者均提供了完善的服务发现机制，但在健康检查细节上略有差异，Consul 在服务网格领域的支持更为广泛。
Nacos 的配置管理功能相对更加强大，支持数据格式校验和版本控制等精细化操作；Consul 则侧重于简单的KV存储和查询。
Nacos 在国内有着更好的生态兼容性，尤其是与阿里云体系内的产品和服务深度整合；而Consul在全球范围内拥有更广泛的用户基础和社区支持。
往期经典推荐
Spring Cloud全方位解读——构建微服务架构的利器-CSDN博客
揭秘 Kafka 高性能之谜：一文读懂背后的设计精粹与技术实现-CSDN博客
486
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
