源码篇--Nacos服务--前章

---

前言

在 阿里云轻量服务器–Docker–nacos 集群部署 中我们了解了怎么搭建一个nacos集群；
在 工具篇–Nacos 源码启动 & jmenv.tbsite.net 错误分析，我们了解了nacos 源码的启动；
在 框架篇–springboot 客户端 整合& Nacos 版本问题 我们了解了 怎么整合到springboot 中；
在Idea+maven+spring-cloud项目搭建系列–3整合Nacos 中我们可以了解cloud的整合和使用；
本文对Nacos 的架构及相关概念进行介绍；
本文环境：nacos2.4 ；
nacos官网：https://nacos.io/docs/v2/what-is-nacos/
参考知乎： 最新版Nacos 2.X服务端源码分析（一）

---

一、Nacos 能干什么：

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service的首字母简称，一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

Nacos 致力于帮助发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助快速实现动态服务发现、服务配置、服务元数据及流量管理。

二、Nacos 架构&概念：

2.1 服务（Service）和服务实例（Instance）：

2.1.1 服务和服务实例的关系：

在生活中，我们被各式各样的服务包围，例如：如果生病了会到医院找医生诊断、如果网购遇到了 问题会找客服咨询，医生提供了诊断服务，客服提供了咨询服务，这位为你诊断病症的医生和为你 解答问题的客服，都是该服务的具体提供者。

在程序世界中也存在类似的情形，例如：在使用支付宝进行付款的时候，或许会要求你先登陆，验 证你的身份信息，最后才能进行支付。而这其中，可能涉及到了支付服务，登陆服务，信息验证服 务等等。而这些，都离不开服务的发现。

在服务发现领域中，服务指的是由应用程序提供的⼀个或⼀组软件功能的⼀种抽象概念（例如上述 例子的登陆或支付）。它和应用有所不同，应用的范围更广，和服务属于包含关系，即⼀个应用可 能会提供多个服务。为了能够更细粒度地区分和控制服务，Nacos 选择服务作为注册中心的最基本 概念。

而服务实例（以下简称实例）是某个服务的具体提供能力的节点，⼀个实例仅从属于⼀个服务，而 ⼀个服务可以包含⼀个或多个实例。在许多场景下，实例又被称为服务提供者（Provider），而使用该服务的实例被称为服务消费者（Consumer）。

2.1.2 nacos 服务：

如下图 nacos 服务，在默认的public 空间下，有2个服务实例，其中 spring-cloud-nacos-client 下存在2个 健康的实例；

在 Nacos 中，服务的定义包括以下几个内容：

• 命名空间（Namespace）：Nacos 数据模型中最顶层、也是包含范围最广的概念，用于在类似 环境或租户等需要强制隔离的场景中定义。Nacos 的服务也需要使用命名空间来进行隔离。
• 分组（Group）：Nacos 数据模型中次于命名空间的⼀种隔离概念，区别于命名空间的强制隔离 属性，分组属于⼀个弱隔离概念，主要用于逻辑区分⼀些服务使用场景或不同应用的同名服务， 最常用的情况主要是同⼀个服务的测试分组和生产分组、或者将应用名作为分组以防止不同应用 提供的服务重名。
• 服务名（Name）：该服务实际的名字，⼀般用于描述该服务提供了某种功能或能力。

之所以 Nacos 将服务的定义拆分为命名空间、分组和服务名，除了方便隔离使用场景外，还有方 便用户发现唯⼀服务的优点。在注册中心的实际使用场景上，同个公司的不同开发者可能会开发出 类似作用的服务，如果仅仅使用服务名来做服务的定义和表示，容易在⼀些通用服务上出现冲突， 比如登陆服务等。

通常推荐使用由运行环境作为命名空间、应用名作为分组和服务功能作为服务名的组合来确保该服 务的天然唯⼀性，当然使用者可以忽略命名空间和分组，仅使用服务名作为服务唯⼀标示，这就需 要使用者在定义服务名时额外增加自己的规则来确保在使用中能够唯⼀定位到该服务而不会发现到 错误的服务上。

2.1.3 nacos 服务元数据：

服务的定义只是为服务设置了⼀些基本的信息，用于描述服务以及方便快速的找到服务，而服务的 元数据是进⼀步定义了 Nacos 中服务的细节属性和描述信息。主要包含：

• 健康保护阈值（ProtectThreshold）：为了防止因过多实例故障，导致所有流量全部流入剩余实 例，继而造成流量压力将剩余实例被压垮形成的雪崩效应。应将健康保护阈值定义为⼀个 0 到 1 之间的浮点数。当域名健康实例数占总服务实例数的比例小于该值时，无论实例是否健康，都会 将这个实例返回给客户端。这样做虽然损失了⼀部分流量，但是保证了集群中剩余健康实例能正 常工作。换句话说如果 nacos 的健康实例数是高于阈值的，则可以返回健康的实例，如果已经小于阈值，则为了保护现有的甲亢实例也会将不健康的实例返回给消费端（默认值0）；
• 实例选择器（Selector）：用于在获取服务下的实例列表时，过滤和筛选实例。该选择器也被称 为路由器，目前 Nacos 支持通过将实例的部分信息存储在外部元数据管理 CMDB 中，并在发现 服务时使用 CMDB 中存储的元数据标签来进行筛选的能力。
• 拓展数据(extendData)：用于用户在注册实例时自定义扩展的元数服务中拓展服务的元数据信息，方便用户实现自己的自定义逻辑。

2.1.4 nacos 服务实例：

2.1.4.1 实例数据介绍:

由于服务实例是具体提供服务的节点，因此 Nacos 在设计实例的定义时，主要需要存储该实例的 ⼀些网络相关的基础信息，主要包含以下内容：

• 网络 IP 地址：该实例的 IP 地址，在 Nacos2.0 版本后支持设置为域名；
• 网络端口：该实例的端口信息；
• 临时实例: 该实例的持久化状态，true 临时实例，false 持久化实例；
• 权重（Weight）：实例级别的配置。权重为浮点数，范围为 0-10000。权重越大，分配给该实例 的流量越大;
  - 健康状态（Healthy）：用于表示该实例是否为健康状态，会在 Nacos 中通过健康检查的手段进 行维护，具体内容将在 Nacos 健康检查机- 制章节中详细说明，读者目前只需要该内容的含义即 可；
• 元数据(extendData)：用于用户自定义扩展的元数据内容，形式为 K-V。可以在实例中拓展该 实例的元数据信息，方便用户实现自己的自定义逻辑和标示该实例；
  
• 上线状态（Enabled）：标记该实例是否接受流量，优先级大于权重和健康状态。用于运维人员 在不变动实例本身的情况下，快速地手动将某个实例从服务中移除。

在 Nacos2.0 版本中，实例数据被拆分为实例定义和实例元数据，主要是因为这两类数据其实是同 ⼀个实例的两种不同场景：开发运行场景及运维场景。对于上下线及权重这种属性，⼀般认为在实 例已经在运行时，需要运维人员手动修改和维护的数据，而 IP，端口和集群等信息，⼀般情况下在实例启动并注册后，则不会在进行变更。将这两部分数据合并后，就能够得到实例的完整信息，也 是 Nacos1.0 版本中的实例数据结构。

同时在 Nacos2.0 版本中，定义实例的这部分数据，会受到持久化属性的的影响，而实例元数据部 分，则⼀定会进行持久化；这是因为运维操作需要保证操作的原子性，不能够因为外部环境的影响 而导致操作被重置，例如在 Nacos1.0 版本中，运维人员因为实例所处的网络存在问题，操作⼀个 实例下线以此摘除流量，但是同样因为网络问题，该实例与 Nacos 的通信也收到影响，导致实例 注销后重新注册，这可能导致上线状态被重新注册而覆盖，失去了运维人员操作的优先级。

当然，这部分元数据也不应该无限制的存储下去，如果实例确实已经移除，元数据也应该移除，为 此，在 Nacos 2.0 版本后，通过该接口更新的元数据会在对应实例删除后，依旧存在⼀段时间，如 果在此期间实例重新注册，该元数据依旧生效；您可以通过 nacos.naming.clean.expired-metadat a.expired-time 及 nacos.naming.clean.expired-metadata.interval 对记忆时间进行修改。

2.1.4.2 实例持久化介绍:

如 Nacos 注册中心的设计原理文中所述，Nacos 提供两种类型的服务：持久化服务和非持久化服 务，分别给类 DNS 的基础的服务组件场景和上层实际业务服务场景使用。为了标示该服务是哪种类 型的服务，需要在创建服务时选择服务的持久化属性。考虑到目前大多数使用动态服务发现的场景 为非持久化服务的类型（如 Spring Cloud，Dubbo，Service Mesh 等），Nacos 将缺醒值设置为 了非持久化服务。

在 Nacos2.0 版本后，持久化属性的定义被抽象到服务中，⼀个服务只能被定义成持久化服务或非 持久化服务，⼀旦定义完成，在服务生命周期结束之前，无法更改其持久化属性。

持久化属性将会影响服务及实例的数据是否会被 Nacos 进行持久化存储，设置为持久化之后，实 例将不会再被自动移除，需要使用者手动移除实例。

注意： 当一个以前是临时实例的实例，直接修改为非临时实例，在 nacos 中，是不允许的。也就是说，nacos 发现你的这些ip和端口信息什么都和以前一样，现在想直接注册为非临时实例，会直接报错

持久化实例属性配置：

spring.cloud.nacos.discovery.ephemeral=false

2.2 集群（Cluster）：

集群是 Nacos 中⼀组服务实例的⼀个逻辑抽象的概念，它介于服务和实例之间，是⼀部分服务属 性的下沉和实例属性的抽象。

在 Nacos 中，集群中主要保存了有关健康检查的⼀些信息和数据：

• 健康检查类型（HealthCheckType）：使用哪种类型的健康检查方式，MySQL；设置为 NONE 可以关闭健康检查。
• 健康检查端口（HealthCheckPort）：设置用于健康检查的端口。
• 是否使用实例端口进行健康检查（UseInstancePort）：如果使用实例使用实例定义中的网络端口进行健康检查，而不再使用上述设置的健康
• 拓展数据(extendData)：用于用户自定义扩展的元数据内容，形式为 K群的元数据信息，方便用户实现自己的自定义逻辑和标示该集群。

2.3 生命周期：

在注册中心中，实例数据都和服务实例的状态绑定，因此服务实例的状态直接决定了注册中心中实 例数据的生命周期。而服务作为实例的聚合抽象，生命周期也会由服务实例的状态来决定。

2.3.1 服务的⽣命周期：

服务的生命周期相对比较简单，是从用户向注册中心发起服务注册的请求开始。在 Nacos 中，发起 服务注册有两种方式，⼀种是直接创建服务：

⼀种是注册实例时自动创建服务；前者可以让发起者 在创建时期就制定⼀部分服务的元数据信息，而后者只会使用默认的元数据创建服务：

在生命周期期间，用户可以向服务中新增，删除服务实例，同时也能够对服务的元数据进行修改。当用户主动发起删除服务的请求或⼀定时间内服务下没有实例（无论健康与否）后，服务才结束其 生命周期，等待下⼀次的创建。

2.3.2 实例的⽣命周期：

实例的生命周期开始于注册实例的请求。但是根据不同的持久化属性，实例后续的生命周期有⼀定 的不同。

持久化的实例，会通过健康检查的状态维护健康状态，但是不会自动的终止该实例的生命周期；在 生命周期结束之前，持久化实例均可以被修改数据，甚至主动修改其健康状态。唯⼀终止持久化实 例生命周期的方式就是注销实例的请求。

而非持久化的实例，会根据版本的不同，采用不同的方式维持健康状态：如果是 Nacos1.0 的版本， 会通过定时的心跳请求来进行续约，当超过⼀定时间内没有心跳进行续约时，该非持久化实例则终 止生命周期；如果是 Nacos2.0 的版本，会通过 gRPC 的长连接来维持状态，当连接发生中断时， 该非持久化实例则终止生命周期。当然，非持久化实例也可以通过注销实例的请求，主动终止其生 命周期，但是由于长连接和心跳续约的存在，可能导致前⼀个实例数据的生命周期刚被终止移除， 立刻又因为心跳和长连接的补偿请求，再次开启实例的生命周期，给人⼀种注销失败的假象。

2.3.3 集群的⽣命周期：

集群的生命周期则相对复杂，由于集群作为服务和实例的⼀个中间层，因此集群的生命周期与实例 和服务的生命周期均有关。

集群的生命周期开始与该集群第⼀个实例的生命周期同时开始，因为⼀个实例必定归属于⼀个集群， 哪怕是默认的集群，因此当第⼀个实例的生命周期开始时，也就是集群生命周期的开始；

当⼀个集群下不存在实例时，集群的生命周期也不会立刻结束，而是会等到这个服务的生命周期结 束时，才会⼀起结束生命周期。

2.3.4 服务的元数据⽣命周期：

由于元数据的其对应的数据模型是紧密关联的，所以元数据的生命周期基本和对应的数据模型保持 ⼀致。但是也如前文所说，元数据通常为运维人员的主动操作的数据，会被 Nacos 进行⼀段时间 内的记忆，因此元数据的生命周期的终止相比对应的数据要滞后；若这滞后期间内，对应的数据又 重新开始生命周期，则该元数据的生命周期将被立刻重置，不再终止。

---

总结

本文对nacos 的架构及相关概念进行介绍。