【Spring Cloud】深入探索 Nacos 注册中心的原理，服务的注册与发现，服务分层模型，负载均衡策略，微服务的权重设置，环境隔离

---

前言

在微服务架构中，服务注册中心是整个体系中的关键组件之一。它负责服务的注册、发现和管理，为微服务之间的通信提供了基础设施。在这方面，Nacos（Namespace Aware Clustered Object Storage）作为一种服务发现和配置管理系统，提供了丰富的功能，旨在简化微服务架构中的服务注册、配置管理以及服务元数据的处理。

一、初识 Nacos 注册中心

1.1 什么是 Nacos

Nacos（Namespace Aware Clustered Object Storage） 是一个开源的、易于配置的、多功能的服务发现和配置管理系统。它由阿里巴巴开发，提供了一种简化微服务架构中服务发现、动态配置和服务元数据的解决方案。

Nacos 具有以下主要特性：

• 服务发现与健康检查： Nacos 提供了服务注册和发现的功能，可以方便地管理微服务的实例。它还支持对服务进行健康检查，及时发现不可用的实例。

• 动态配置管理： Nacos 允许将配置信息存储在服务端，并支持动态更新配置，实现了配置的集中管理。

• 动态 DNS 服务： Nacos 提供了内置的 DNS 服务，通过 DNS 查询可以获取到注册在 Nacos 上的服务实例信息。

• 多环境和命名空间： Nacos 支持多环境（例如开发、测试、生产）和命名空间的管理，可以更灵活地组织和管理配置信息。

1.2 Nacos 的安装，配置，启动

1. 安装

1. 下载安装包

在 Nacos 的 GitHub 页面，提供有下载链接，可以下载编译好的 Nacos 服务端或者源代码：

GitHub主页： https://github.com/alibaba/nacos

GitHub的Release下载页： https://github.com/alibaba/nacos/releases

如图：

2. 点击右侧的 Tags 标签更加直观的选择历史版本，这里以 Nacos 1.4.1 为例：

3. Windows 环境选择 zip ，如果是 Linux 则选择 tar.gz 压缩包。这里以Windows环境为例：

4. 下载完成之后，将其解压到一个没有中文的路径下，此时就安装完成了。

5. Nacos 的目录结构

目录说明：

• bin：启动 Nacos 的脚本文件。
• conf：Nacos 的配置文件。

2. 配置

Nacos的默认端口是8848，如果电脑上的其它进程占用了8848端口，请先尝试关闭该进程。

如果无法关闭占用8848端口的进程，也可以进入 Nacos 的 conf 目录，修改配置文件中的端口：
修改其中的内容：

修改端口：

3. 启动

启动 Nacos 非常简单，进入 bin 目录，结构如下：

然后执行命令即可：

startup.cmd -m standalone

执行后的效果如图：

访问启动日志中提供的地址，或者是在浏览器输入地址http://127.0.0.1:8848/nacos 即可访问 Nacos 控制台：

默认的账号和密码都是 nacos，进入后：

二、服务的注册与发现

Nacos 的服务注册非常简单，Spring Cloud 提供了通用接口规范，因此使用不同的注册中心只需要更改配置，而不需要修改代码即可完成注册中心的切换。例如，切换 Eureka 到 Nacos 的操作方式如下：

1. 在 cloud-demo 父工程中添加 spring-cloud-alilbaba 的管理依赖：

<dependency>
    <groupId>com.alibaba.cloudgroupId>
    <artifactId>spring-cloud-alibaba-dependenciesartifactId>
    <version>2.2.6.RELEASEversion>
    <type>pomtype>
    <scope>importscope>
dependency>

2. 注释掉 order-service 和 user-service 中原有的 Eureka 依赖，添加 Nacos 的客户端依赖：

<dependency>
    <groupId>com.alibaba.cloudgroupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discoveryartifactId>
dependency>

3. 修改 application.yml 文件，注释掉 Eureka 相关配置，添加 Nacos 相关配置：

spring:
  cloud:
    nacos:
	  server-addr: localhost:8848 # Nacos 服务地址

4. 根据上述的修改步骤，同时修改 user-service 和 order-service 两个微服务的配置，然后分别启动这两个微服务：

此时启动了一个 order-service 服务实例和三个 user-service 服务实例。

5. 启动之后就可以在 Nacos 控制台的服务列表中查看注册的所有服务了：

并且可以查看服务的详情：

通过上述步骤，我们成功将服务的注册中心从 Eureka 切换到 Nacos，实现了服务的注册与发现。 Nacos 提供了强大的服务治理功能，是一个优秀的云原生应用的服务中心。

三、Nacos 服务分层模型

3.1 Nacos 的服务分级存储模型

Nacos 的服务分级存储模型是其设计架构的一个重要组成部分，它有助于更好地管理和组织服务信息。这个模型分为三个层级，分别是服务（Service）、集群（Cluster）和实例（Instance）。

例如，Nacos 的服务分级存储模型如下图所示：

这模型分为三个层级：

1. 服务（Service）： 服务是 Nacos 中的最高层级，它代表了一个抽象的服务实体，通常以服务的名称来标识，例如 userservice。服务可以包含一个或多个集群。

2. 集群（Cluster）： 集群是服务的下一层级，用于表示同一个服务的多个实例的分组。一个服务可以分布在不同的集群中，每个集群可以包含一个或多个实例。以地理位置或部署环境为例，一个服务可以有多个集群，如杭州集群、上海集群等。

3. 实例（Instance）： 实例是服务的最低层级，它代表了一个具体的服务实例，通常对应一个运行中的服务节点。每个集群中可以包含一个或多个实例，每个实例都具有唯一的 IP 地址和端口号，并提供了服务的访问地址。

这个模型的设计使得 Nacos 能够更好地管理和组织服务信息，尤其是在多地理位置、多环境下部署的场景中。服务可以以地理位置、部署环境等为单位进行划分，每个集群中包含多个实例，具备了高可用性和负载均衡的特性。这种结构也有助于更好地理解和管理微服务架构中的服务体系，使得服务的注册、发现和管理更加直观和可控。

3.2 服务跨集群调用问题

在微服务架构中，服务通常会分布在不同的集群中，而服务之间的调用可能涉及到跨集群的情况。在 Nacos 中，服务跨集群调用时需要考虑一些问题，其中一个重要的问题是延迟。

服务调用时的一般原则是尽可能选择本地集群的服务进行调用，因为本地调用通常延迟较低。当本地集群的服务不可访问时，才考虑跨集群调用。

以一个示例来说明：

假设有两个集群，一个是杭州集群，另一个是上海集群。在杭州集群中有一个 order-service 服务，而在上海集群中也有一个相同的 user-service 服务。如果 order-service 这个微服务需要调用 user-service，它首先会尝试调用本地集群的服务，即杭州集群的 user-service。只有当杭州集群的服务不可访问时，才会考虑跨集群调用，去访问上海集群的 user-service。

这样的设计可以有效降低服务调用的延迟，因为本地调用通常比跨集群调用更快速。同时，也提高了系统的稳定性，避免了出现某个集群不可用时，整个系统都无法正常工作的情况。

3.3 服务集群属性设置

当我们在 Nacos 的控制台查看具体服务的详情的时候，会发现当前服务处于的集群的 DEFAULT：

此时，如果我们想要修改服务的所属集群，则可以通过修改 application.yml 文件来进行配置：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848 # nacos 服务地址
      discovery:
        cluster-name: name # 集群名称

例如，将user-service 服务的一个实例设置到杭州集群中，另外两个实例设置到上海集群中，重新启动后再次查看 Nacos 的控制台：

此时就成功配置user-service了服务的集群属性。但是，如果要想order-service 调用里自己最近的集群，还需要对 order-service 服务进行集群属性的配置。

例如，将其配置到杭州集群：

配置完成之后，现在 order-service 和 8081端口的 user-service 就在同一个集群中了，而 8082 和 8083 端口的 user-service 则在上海集群中。

3.4 修改负载均衡策略为集群策略

重启 order-service 服务，然后再进行多次查询订单操作，观察调用 user-service 服务的情况：

此时我们发现了，好像没有采用优先访问相同集群的策略，而是采取轮询的负载均衡方式。当然，应该采取这种方式，因为目前order-service中设置的就是随机选择的负载均衡策略：

如果要想优先访问相同集群的策略，则需要修改 order-service 的application.yml 文件，设置负载均衡的 IRule 为 com.alibaba.cloud.nacos.ribbon.NacosRule，这个规则优先会寻找与自己同集群的服务：

# 修改 Ribbon 负载均衡策略
userservice:
  ribbon:
    NFLoadBalancerRuleClassName: com.alibaba.cloud.nacos.ribbon.NacosRule # 集群优先负载均衡规则

再次重启 order-service 服务，然后多次进行订单查询操作，观察 user-service 的调用情况：

此时可以发现，访问的都是 8081 端口的 user-service 实例，而没有服务另外两个实例。这是因为 8081 端口的 user-service 服务和order-service在同一个集群中。

如果此时停止 8081 的user-service 服务，再次访问会出现什么样的状况呢？例如：

此时就跨集群的访问到了 8083 端口的这个 user-service 服务。

并且，在order-service服务的日志中也出现了警告：

其含义就是进行了跨集群的调用，即 order-service 想要服务的集群是杭州集群，但是实际上访问的是上海集群。

四、根据服务的权重进行负载均衡

在实际部署中，服务器设备的性能可能存在差异，一些实例所在机器的性能较好，而另一些性能较差。为了合理利用资源，我们希望性能较好的机器能够承担更多的用户请求。Nacos 提供了权重配置的功能，通过设置权重，可以控制访问频率，权重越大的实例被选中的概率就越高。

下面演示如何在 Nacos 控制台中设置服务实例的权重：

1. 在 Nacos 控制台中，选中相应实例后点击编辑按钮，就发现了权重的配置项：
   

2. 设置某个实例的权重，例如将 8081 端口的服务的权重设置为 0.1：
   

设置了权重之后，进行多次访问，观察 user-service 服务的调用情况：

可以看到，经过多次访问后，8081 端口对应的 user-service 被访问的次数相对较少，说明权重设置生效。这种方式可以有效地利用资源，使性能较好的机器更多地承担用户请求，实现负载均衡。

注意：

• 如果将权重设置为0，那么这个服务就不会被服务到了。
• 在实际生产环境中，可以在某个服务需要升级的时候，将其权重设置为0，从而避免将流量导向到正在升级的实例，防止影响用户体验，等升级完成后，再将权重恢复为正常值。
• 同时，这个设置也适用于故障处理，通过将故障的服务实例的权重设置为0，暂时屏蔽掉该实例，以保证整体服务的可用性。

五、Nacos 环境隔离

5.1 什么是 Nacos 的环境隔离（namespace）

通过上文我们知道了 Nacos 是一个注册中心，但是同时 Nacos 还是一个数据中心。因此，Nacos 为了管理服务和数据，它还提供了对环境隔离的支持。Nacos 中服务存储和数据存储的最外层都是一个名为 namespace 的东西，用来做最外层隔离。

如下图所示：

从外到里，Nacos 的层级关系如下：

1. Namespace（命名空间）： 是最外层的隔离单位。一个 Namespace 对应一个隔离环境，包含独立的服务和配置信息。每个 Namespace 都有唯一的命名空间 ID 和名称。

2. Group（分组）： 在一个 Namespace 下，服务和配置可以根据 Group 进行划分。不同的 Group 中可以包含相同服务名（Service）或配置名（Data）的不同版本。Group 的作用是在一个 Namespace 中更细粒度地划分服务和配置。

3. Service/Data（服务/配置）： 是 Namespace 和 Group 中最基本的单位。Service 代表服务，Data 代表配置。在一个 Namespace 和 Group 的范围内，服务和配置的名称是唯一的。

这种分层结构使得 Nacos 具有很好的灵活性和隔离性。Namespace 提供最大范围的隔离，Group 进一步细化隔离，而 Service 和 Data 则是具体的服务和配置单元。

5.2 为什么需要环境隔离

环境隔离在分布式系统和微服务架构中是一项重要的实践，对于 Nacos 来说，引入环境隔离的主要原因包括：

1. 多环境支持： 在软件开发和运维过程中，通常会存在多个环境，例如开发环境、测试环境、生产环境等。通过使用 Namespace 来隔离环境，可以使得不同环境下的服务和配置信息得以独立管理，不会相互干扰。

2. 团队协作： 在大型项目中，可能有多个开发团队同时在开发和维护服务。每个团队都可以在自己的 Namespace 下独立管理服务和配置，确保彼此之间的隔离。

3. 版本管理： 随着业务的发展，服务和配置可能会有多个版本。通过使用 Group 和 Namespace 的结构，可以更好地进行版本管理，不同版本的服务和配置可以在同一个 Namespace 下通过 Group 进行区分。

4. 隔离风险： 在微服务架构中，服务之间是相互独立的。如果没有环境隔离，一个服务的错误可能会波及到其他服务，导致整个系统出现问题。通过使用 Namespace 隔离环境，可以最小化这种风险。

总的来说，Nacos 的环境隔离功能为多环境、多团队、多版本的复杂场景提供了灵活的解决方案，使得服务和配置的管理更加清晰和可控。

5.3 设置 Nacos 的环境隔离

查看 Nacos 控制台中的“命名空间”，可以发现为我们提供了一个默认的命名空间public：

而此时所有的服务也都在这个命名空间中：

通过 Nacos 控制台以及相关配置文件的修改即可完成 Nacos 环境隔离的设置，具体的操作步骤如下：

1. 在 Nacos 控制台可以的“命名空间”中创建 namespace，用来隔离不同环境：
   
   此时创建一个dev 的命名空间，用于开发环境。其中还有一个命名空间 ID，这个ID可以填也可以不填，不填则会使用 UUID 自动生成一个唯一 ID。

2. 点击确认之后，就会发现为 dev 自动生成了命名空间 ID：
   

并且此时的服务列表中也多了一个 dev 的命名空间，但其中还没有注册任何服务：

3. 修改 order-service 的 application.yml，添加新创建的 namespace：

spring:
  cloud:
    nacos:
      server-addr: localhost:8848 # nacos 服务地址
      discovery:
        namespace: ID # 命名空间 ID

注意，这个 ID 要与 Nacos 中的 命名空间 ID 保持一致。

例如，设置为 dev命名空间的 ID：

5.4 重启 order-service 服务

设置完了 order-service 服务的命名空间之后，重启并查看控制台服务列表：

此时，可以发现在 dev 命名空间中就成功注册了order-service 服务了。

如果此时再次访问订单信息，那么会访问成功吗？

发现结果报错了，原因是没有可以的 user-service 可用实例，但是现在明明启动了三个 user-service 实例啊。

原来三个 user-service 实例是位于 public 命名空间中的，而 order-service 位于 dev 命名空间，由于命名空间具有隔离性，因此就访问不到其他命名空间的 user-service 服务了。

此时，以同样的方式也将user-service服务也注册到 dev 命名空间中：

重启服务，查看 Nacos 控制台：

发现所有服务都在dev命名空间中了，再次服务订单信息，就可以正常访问了：

六、Nacos 注册中心原理剖析

6.1 Nacos 注册中心的执行流程

Nacos（Naming and Configuration Service）是一个开源的服务发现和配置管理平台，用于构建和管理微服务体系结构。在微服务架构中，服务的注册与发现是至关重要的，而Nacos作为一种服务注册中心，承担了这一关键任务。下面将深入剖析 Nacos 注册中心的执行流程，详细说明其背后的原理。

Nacos 注册中心执行流程概览:

对上图流程的详细说明：

1. 服务提供者注册: 服务提供者在启动时，将自己的服务信息注册到Nacos注册中心。这包括服务名称、IP地址、端口号等关键信息。注册的实例可以是临时实例或非临时实例，根据实际需要选择注册类型。

2. 健康检测:

   • 对于临时实例，Nacos采用心跳检测机制。注册的临时实例会定期向Nacos注册中心发送心跳包，证明自己正常运行。如果心跳包未按时到达，Nacos将删除该实例，确保注册中心中只有健康的服务实例。
   • 对于非临时实例，Nacos会主动向实例发起询问，检查其健康状态。如果发现异常，Nacos将更新实例的健康状态，同时在实例恢复正常后，将其状态恢复。

3. 服务消费者拉取: 服务消费者定期向Nacos注册中心拉取最新的服务列表。这个服务列表包含了可用的服务实例信息，使得消费者能够了解到当前可用的服务。

4. 异常处理与服务推送: Nacos注册中心具有异常处理机制。当注册中心发生异常或停止运行时，它会主动推送更新后的服务信息给服务消费者。这样，消费者能够及时感知到注册中心的状态变化，并作出相应的调整，确保系统的稳定性。

5. 负载均衡: 服务消费者在获取到服务列表后，会在缓存的服务列表上进行负载均衡。这确保了请求能够被均匀分配到不同的服务实例上，避免了单点故障的发生。

6.2 临时实例和非临时实例的设置

查看 Nacos 的控制台中的实例详情：

可以发现，前面注册的实例默认都是临时实例的。

如果要修改为非临时实例，则可以通过修改 application.yml 文件进行设置：

spring:
  cloud:
    nacos:
      discovery:
        ephemeral: false # 设置为非临时实例

例如，修改 order-service 服务为非临时实例：

重启服务，再次查看 Nacos 控制台：

此时就成功将 order-service 服务设置为了非临时实例的。

如果此时停止 order-service 服务，可以发现健康状态变为 false，但是并没有从服务列表中删除：

再次重启 order-service 服务，可以发现健康状态又变成了 true：

总结：Nacos 和 Eureka 的区别

Nacos 和 Eureka 是两个常见的服务注册与发现工具，它们有一些区别，主要体现在以下几个方面：

1. 数据存储方式：

   • Nacos： Nacos不仅是服务注册中心，还是一个支持配置管理的平台。它使用类似数据库的方式存储服务和配置信息，提供了命名空间、组、服务、实例等多层次的存储结构，支持更细粒度的管理。
   • Eureka： Eureka主要是一个简单的服务注册与发现系统，它的服务信息存储在一个全局的注册表中，相对来说简单直接。

2. 多环境隔离：

   • Nacos： Nacos提供了Namespace（命名空间）和Group的概念，支持多环境、多团队、多版本的隔离和管理。
   • Eureka： Eureka没有直接支持多环境隔离的概念，需要通过其他手段来实现。

3. 配置管理：

   • Nacos： Nacos作为配置中心，支持动态配置、配置的版本管理、监听配置变更等功能。
   • Eureka： Eureka主要关注服务注册与发现，没有显式的配置管理功能。

4. 服务权重与流量控制：

   • Nacos： Nacos支持通过权重配置来实现流量控制，可以根据服务的性能设置不同的权重。
   • Eureka： Eureka在原生形态下并没有提供类似权重配置的功能，需要借助其他组件（比如Ribbon）来实现。

5. 兼容性：

   • Nacos： Nacos提供了Spring Cloud的原生支持，更好地与Spring Cloud应用集成。
   • Eureka： Eureka是Netflix开发的，也有与Spring Cloud的天然集成。

总体而言，Nacos 相对于 Eureka 更加全面，支持更多的功能，尤其在配置管理、多环境隔离等方面更加灵活。选择使用哪个取决于具体的需求和场景。