Nacos基础概念

一、服务治理

服务注册与服务发现

从上图中的步骤中我们可以看出，首先，服务 B 集群向注册中心发起了注册，将自己的地址信息上报到注册中心，这个过程就是服务注册。接下来，每隔一段时间，服务 A 就会从服务中心获取服务 B 集群的服务列表，或者由服务中心将服务列表的变动推送给服务 A，这个过程叫做服务发现；最后，服务 A 根据本地负载均衡策略，从服务列表中选取某一个服务 B 的节点，发起服务调用。

在这个过程中，注册中心的角色是一个中心化的信息管理者，所有的微服务节点在启动后都会将自己的地址信息添加到注册中心。在服务注册的过程中，有两个关键信息是最为重要的，我把它们列在了这里。

  • 服务名称：服务名称通常默认是 spring.application.name 属性，在服务注册过程中我们必须将应用服务名上报到注册中心，这样其他服务才能根据服务名称找到对应的服务节点列表；

  • 地址信息：包括服务节点的 IP 地址和端口。

如果服务 B 集群因为未知的网络故障导致无法响应服务，这时候服务 A 向服务 B 发起了服务调用，就会发生超时或者服务无响应的异常情况。那我们如何在服务治理方案中规避这类问题呢？业界通用的解决方案是“heathcheck”或者“heartbeat”，又叫“服务探活”或“心跳检查”。注册中心可以通过这种机制来标记异常服务，这样一来，Client 端在发送服务请求的时候就能避开异常节点。

如果节点持续发送心跳信息，则一切正常，服务可以被发现；如果注册中心在一段时间内没有收到 Client 的心跳包，注册中心就会将这个节点标记为下线状态，进而将该服务从服务列表中剔除。

这里我再补充一句，我们上面说的“服务剔除”是由注册中心主导的“被动下线”场景。除此之外还有一类服务“主动下线”的场景，也就是当服务节点关闭或者重启的时候，通过发送一条“服务下线”指令给到注册中心，将当前节点标记为下线状态。

二、Nacos 体系架构

1. 数据模型

Nacos 的数据模型有三个层次结构，分别是 Namespace、Group 和 Service/DataId，我画了一幅图，帮你理解这三个层次之间的包含关系：

  • Namespace：即命名空间，它是最顶层的数据结构，我们可以用它来区分开发环境、生产环境等不同环境。默认情况下，所有服务都部署到一个叫做“public”的公共命名空间；

  • Group：在命名空间之下有一个分组结构，默认情况下所有微服务都属于“DEFAULT_GROUP”这个分组，不同分组间的微服务是相互隔离的；

  • Service/DataID：在 Group 分组之下，就是具体的微服务了，比如订单服务、商品服务等等。

通过Namespace + Group + Service/DataID，我们就可以精准定位到一个具体的微服务。比如，我想调用生产环境下 A 分组的订单服务，那么对应的服务寻址的 Key 就是类似 Production.A.orderService 的组合。

2. Nacos 基本架构

Nacos 的核心功能有两个，一个是 Naming Service，也就我们用来做服务发现的模块；另一个是 Config Service，用来提供配置项管理、动态更新配置和元数据的功能，关于配置管理的内容我会放到课程中的配置管理阶段为你详细讲解。

从上面的图中你可以看出，Provider APP 和 Consumer APP 通过 Open API 和 Nacos 服务器的核心模块进行通信。这里的 Open API 是一组对外暴露的 RESTful 风格的 HTTP 接口。如果你对 Open API 里具体的接口感兴趣，可以从Nacos 官方网站获取更多的关于 Open API 的详细信息。

Nacos 还有一个相当重要的模块：Nacos Core 模块。它可以提供一系列的平台基础功能，是支撑 Nacos 上层业务场景的基石。我挑选了几个 Nacos Core 中包含的重要功能，你可以看一下。

除了 Nacos Core 提供的这些功能以外，Nacos 还有一个“一致性协议”，用来确保 Nacos 集群中各个节点之间的数据一致性。Nacos 内部支持两种一致性协议，一种是侧重一致性的 Raft 协议，基于集群中选举出来的 Leader 节点进行数据写入；另一种是针对临时节点的 Distro 协议，它是一个侧重可用性（或最终一致性）的分布式一致性协议。

需要深入了解的问题：

  • Nacos 底层一致性协议的原理