跳到主要内容

Nacos

Nacos 的关键特性

  • 服务发现和服务健康监测
    • DNS 和 RPC 2 种方式
  • 动态配置服务
    • 让配置变更时，不需要重启服务了。
  • 动态 DNS 服务
  • 服务及其元数据管理

Nacos 基本概念​

  • namespace 用于租户隔离 namespace 就是用来做资源隔离的。
    • 单租户不同的环境：如 dev, test, prod
    • 多租户: 如 zhangsan, lisi, wangwu
  • group : 用于不同的应用户组件使用了相同的配置项, 如 database_url 和 MQ_topic
  • data-id 配置集的 id ${prefix}-${spring.profiles.active}-${file-extension}

存储模型​

config_info 配置信息的主表

config_info_beta 灰度测试的配置信息表

config_tags_relation 配置的标签表

his_config_info 配置的历史信息表

注册中心​

服务注册与发现

雪崩保护

推空保护

模糊订阅

负载策略

监控检查

配置中心​

配置中心要满足下面的基础诉求

  1. 支持动态修改配置 动态
  2. 动态修改配置要实时生效(越快越好) 实时
  3. 变更快了之后，如何管理控制变更风险, 如灰度，回滚等。 管控
  4. 敏感配置如何做安全配置 安全

配置动态生效

模糊订阅

配置灰度

配置版本管理

AI 中心​

MCP 管理

MCP Router

动态 prompt

A2A 协议

协议增强​

DNS

xDS

Prometheus

一致性模块​

Nacos 是要把配置存到数据库的。 在集群环境下，就需要考虑各个节点的数据一致性与数据同步。

分布式环境有一个 CAP 理论。

  • Consistency：一致性就是在客户端任何时候看到各节点的数据都是一致的。
  • Availability：可用性就是在任何时刻都可以提供读写。
  • Partition Tolerance：分区容错性是在网络故障、某些节点不能通信的时候系统仍能继续工作。

三者只能选其二。

引入一个共识算法

Nacos 引入了 Distro(最终一致性算法) 协议和 Raft(强一致性算法) 协议

**Nacos 为什么会引入 2 个协议呢？ **

因为这 2 个协议的达到的效果是不一样的。 Distro 能够实现 AP， 即能够保证可用性以及分区容错性。 Raft 能够实现 CP 即一致性和分区容错性。

Nacos 有 2 个功能，注册中心和配置管理。

注册中心在整个微服务系统中是一个非常重要的组件，因此对服务注册发现中心组件的可用性， 提出了很高的要求(要尽最大可能保证注册中心能够对外提供服务)。 要满足 Availability 在这种情况下，强一致性算法就不太合适了。强一致性算法在可用节点没有过半的时候， 不能保证可用性（整个算法会罢工）。应该使用最终一致性算法（AP）。

配置数据是直接在 Nacos 服务端进行创建的，必须保证大部分节点都保存了此配置数据 才能任务配置被保存成功了，否则就丢失配置的变更。这种情况下就必须使用强一致性算法。（CP）

Notify 机制​

Event 异步化​

通信模块​

gRpc

HTTP

需求分析：

  1. client 需要知道有哪些 server 列表，并根据某种策略选取一个节点进行连接。并且在底层连接断开时，需要进行切换 server 进行重连。
  2. client 基于当前长链接进行配置的增删改查以及监听，取消监听等 RPC 语意接口通信。
  3. 感知配置变更消息，需要将配置变更消息推送至当前监听的客户端。网络不稳定时，client 接收失败，需要支持重推，并告警。
  4. 感知客户端连接断开事件，将连接注销，并清空连接对应的上下文。
  5. 单个 server 需要获取到集群所有的 server 间的列表，并且为每一个 server 建立长链接。连接断开时需要重连。服务端列表发生变更时，需要创建新节点的长链接，销毁下线的节点长链接。
  6. Server 间需要进行数据同步，包括配置变更信息同步,当前连接数信息，系统负载信息同步，负载调节信息同步等。

Nacos 核心模块​

基础鉴权

集群管理

流量控制

基础监控

负载均衡

插件机制

事件机制

日志模块

回调机制

寻址机制

推送通道

容量管理

流量管理

缓存机制

启动模式

一致性协议

存储模块

传输通道

Nacos Group​

nacos-sync

nacos controller

nacos mcp router

nacos mcp server

nacos bench

nacos 插件​

鉴权

配置加解

多数据源

轨迹追踪

环境变量

反脆弱

配置 Hook

生态组件​

spring cloud

dubbo

higress

apisix

corends

istio

spring ai

ai agent

kitex

kratos

sentinal

seata

nacos console

Nacos 体系架构​

  1. 领域模型
  2. 数据模型
  3. 基本架构

领域模型​

描述了服务与实例之间的边界与层级关系。

  1. 服务, 可以配置服务阈值，当服务的健康实例数的比例小于这个阈值时， nacos 会开启服务保护模式，不再主动剔除服务实例，同时还会将不健康的实例也返回给消费者。
  2. 集群
  3. 实例

数据模型​

  1. namespace: 命名空间

    1. 环境隔离
    2. 多租户隔离

  2. group：分组，默认值是：DEFAULT_GROUP

    1. 环境隔离， namespace 被租户使用，通过 group 来区分环境
    2. 线上测试，生产环境使用 group-prod, 测试使用 group-test, 将测试请求的流量导入 group-test, 即可完成线上测试。
    3. 单元封闭，将同一个单元(机房) 的服务设置相同的 group，使微服务调用封闭在当前单元内，提高业务响应速度。

service/data id

通过 namespace + group + service/data id 可定位到一个具体的微服务。

Nacos 基本架构​

Nacos 的核心功能：

  • Naming service: 服务发现。
  • Config service：配置管理。
  • Nacos core
  • 一致性协议

Nacos 实战​

  1. 通过 server.port 修改端口
  2. spring.datasource.platom 指定数据库源，如 mysql
  3. db.num 指定 DB 实例数
  4. 在 conf/cluster.conf 添加 nacos 实例地址
  5. 以单机启动时需要加上 -m standalone

SpringBoot 工程集成 Nacos​

引入了 com.alibaba.cloud.spring-cloud-starter-alibaba-nacos-discovery, 配置了 @EnableDiscoveryClient 即可实现服务注册功能。

问题排查​

  1. 查看日志 nacos/nacos.log
  2. Nacos 连接参数是否正确，服务器端口是否已放开

Nacos 服务发现底层实现​

Nacos Client 通过主动轮询的机制从 Nacos Server 获取服务注册信息，包括地址列表、group、cluster 等一些列信息。

Nacos 作为配置中心​

配置动态刷新。

Nacos 配置中心的连接信息需要配置在 bootstrap 文件，而非 application.yml 文件中。在 spring cloud 2020.0.0 版本之后，bootstrap 文件不会被自动加载，你需要主动添加 spring-cloud-starter-bootstrap 依赖项来开启 bootstrap 的自动加载流程。

为什么集成 Nacos 配置中心必须用到 bootstrap 配置文件呢？

我们可能会把数据库的连接信息配置到 nacos 的配置中心里面，这个需要在其它组件初始化之前就从 Nacos 读取到。之后再将获取到的配置项用于后续的初始化流程。

bootstrap.yml 文件优先级高于 application.yml

spring:
  application:
    name: coupon-template-serv  # 必须把 name 属性放到 bootstrap.yml 中，不然动态刷新不会生效。
  cloud:
    nacos:
      config:
        server-addr: localhost:8848
        file-extension: yml
        # prefix: 文件名前缀，默认是spring.application.name
        # 如果没有指定命令空间，则默认命令空间为PUBLIC
        namespace: dev
        # 如果没有配置Group，则默认值为DEFAULT_GROUP
        group: DEFAULT_GROUP
        # 从Nacos读取配置项的超时时间
        timeout: 5000
        # 长轮训超时时间
        config-long-poll-timeout: 1000
        # 重试时间
        config-retry-time: 100000
        # 长轮训重试次数
        max-retry: 3
        # 开启监听和自动刷新
        refresh-enabled: true
        # Nacos的扩展配置项，数字越大优先级越高
        enable-remote-sync-config: true
        extension-configs:
          # 可以添加其他节点
          - dataId: rabbitmq-config.yml
            group: EXT_GROUP
            refresh: true

Nacos 配置中心的长轮询机制的工作原理。

当 Client 向 Nacos Config 服务端发起一个配置查询请求时，服务端并不会立即返回查询结果，而是会将这个请求 hold 一段时间。 如果在这段时间内有配置项数据的变更，那么服务端会触发变更事件，客户端将会监听到该事件，并获取相关配置变更。 如果这段时间内没有发生数据变更，那么在这段 hold 时间结束户，服务端将释放请求。

通过 @Value("${xxxxxxx}") 来获取 Nacos Config 中配置的值，并在添加类上 @RefreshScope

@RefreshScope 能够让被标记的 Bean 能够自动刷新，获取最新的配置值，无需重启应用。

最后于 更新