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

【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.***/alibaba/nacos

GitHub的Release下载页: https://github.***/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>***.alibaba.cloud</groupId>
    <artifactId>spring-cloud-alibaba-dependencies</artifactId>
    <version>2.2.6.RELEASE</version>
    <type>pom</type>
    <scope>import</scope>
</dependency>
  1. 注释掉 order-serviceuser-service 中原有的 Eureka 依赖,添加 Nacos 的客户端依赖:
<!-- Nacos 客户端依赖 -->
<dependency>
    <groupId>***.alibaba.cloud</groupId>
    <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>
  1. 修改 application.yml 文件,注释掉 Eureka 相关配置,添加 Nacos 相关配置:
spring:
  cloud:
    nacos:
	  server-addr: localhost:8848 # Nacos 服务地址
  1. 根据上述的修改步骤,同时修改 user-serviceorder-service 两个微服务的配置,然后分别启动这两个微服务:

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

  1. 启动之后就可以在 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-serviceapplication.yml 文件,设置负载均衡的 IRule***.alibaba.cloud.nacos.ribbon.NacosRule,这个规则优先会寻找与自己同集群的服务:

# 修改 Ribbon 负载均衡策略
userservice:
  ribbon:
    NFLoadBalancerRuleClassName: ***.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 的命名空间,但其中还没有注册任何服务:

  1. 修改 order-serviceapplication.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是***flix开发的,也有与Spring Cloud的天然集成。

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

转载请说明出处内容投诉
CSS教程_站长资源网 » 【Spring Cloud】深入探索 Nacos 注册中心的原理,服务的注册与发现,服务分层模型,负载均衡策略,微服务的权重设置,环境隔离

发表评论

欢迎 访客 发表评论

一个令你着迷的主题!

查看演示 官网购买