1. 小郑聊编程
  2. 首页
  3. Nacos 教程
  4. 正文

17、Nacos系列-Nacos2.x之总体设计

分类：Nacos 教程    2024-01-30    阅读(94)

Nacos 总体设计

Nacos 架构

Nacos 开源之前在阿里内部已经发展了十年，沉淀了很多优秀的能力，也有很多历史负担，在开源 的时候我们取其精华进行开源，为了提升代码的健壮性和扩展性，进行了充分的分层和模块化设计。

设计原则

  • 极简原则，简单才好用，简单才稳定，简单才易协作。
  • 架构⼀致性，⼀套架构要能适应开源、内部、商业化（公有云及专有云）3 个场景。
  • 扩展性，以开源为内核，商业化做基础，充分扩展，方便用户扩展。
  • 模块化，将通用部分抽象下沉，提升代码复用和健壮性。
  • 长期主义，不是要⼀个能支撑未来 3 年的架构，而是要能够支撑 10 年的架构。
  • 开放性，设计和讨论保持社区互动和透明，方便大家协作。

架构图

整体架构分为用户层、业务层、内核层和插件，用户层主要解决用户使用的易用性问题，业务层主 要解决服务发现和配置管理的功能问题，内核层解决分布式系统⼀致性、存储、高可用等核心问题， 插件解决扩展性问题。

 

用户层
  • OpenAPI：暴露标准 Rest 风格 HTTP 接口，简单易用，方便多语言集成。
  • Console：易用控制台，做服务管理、配置管理等操作。
  • SDK：多语言 SDK，目前几乎支持所有主流编程语言。
  • Agent：Sidecar 模式运行，通过标准 DNS 协议与业务解耦。
  • CLI：命令行对产品进行轻量化管理，像 git ⼀样好用。
业务层
  • 服务管理：实现服务 CRUD，域名 CRUD，服务健康状态检查，服务权重管理等功能。
  • 配置管理：实现配置管 CRUD，版本管理，灰度管理，监听管理，推送轨迹，聚合数据等功能。
  • 元数据管理：提供元数据 CURD 和打标能力，为实现上层流量和服务灰度非常关键。
内核层
  • 插件机制：实现三个模块可分可合能力，实现扩展点 SPI 机制，用于扩展自己公司定制。
  • 事件机制：实现异步化事件通知，SDK 数据变化异步通知等逻辑，是 Nacos 高性能的关键部分。
  • 日志模块：管理日志分类，日志级别，日志可移植性（尤其避免冲突），日志格式，异常码+帮 助文档。
  • 回调机制：SDK 通知数据，通过统⼀的模式回调用户处理。接口和数据结构需要具备可扩展性。
  • 寻址模式：解决 Server IP 直连，域名访问，Nameserver 寻址、广播等多种寻址模式，需要可 扩展。
  • 推送通道：解决 Server 与存储、Server 间、Server 与 SDK 间高效通信问题。
  • 容量管理：管理每个租户，分组下的容量，防止存储被写爆，影响服务可用性。
  • 流量管理：按照租户，分组等多个维度对请求频率，长链接个数，报文大小，请求流控进行控制。
  • 缓存机制：容灾目录，本地缓存，Server 缓存机制，是 Nacos 高可用的关键。
  • 启动模式：按照单机模式，配置模式，服务模式，DNS 模式模式，启动不同的模块。
  • ⼀致性协议：解决不同数据，不同⼀致性要求情况下，不同⼀致性要求，是 Nacos 做到 AP 协 议的关键。
  • 存储模块：解决数据持久化、非持久化存储，解决数据分片问题。
插件
  • Nameserver：解决 Namespace 到 ClusterID 的路由问题，解决用户环境与 Nacos 物理环境 映射问题。
  • CMDB：解决元数据存储，与三方 CMDB 系统对接问题，解决应用，人，资源关系。
  • Metrics：暴露标准 Metrics 数据，方便与三方监控系统打通。
  • Trace：暴露标准 Trace，方便与 SLA 系统打通，日志白平化，推送轨迹等能力，并且可以和计 量计费系统打通。
  • 接入管理：相当于阿里云开通服务，分配身份、容量、权限过程。
  • 用户管理：解决用户管理，登录，SSO 等问题。
  • 权限管理：解决身份识别，访问控制，角色管理等问题
  • 审计系统：扩展接口方便与不同公司审计系统打通。
  • 通知系统：核心数据变更，或者操作，方便通过 SMS 系统打通，通知到对应人数据变更。

Nacos 配置模型

背景

在单体架构的时候我们可以将配置写在配置文件中，但有⼀个缺点就是每次修改配置都需要重启服 务才能生效。

当应用程序实例比较少的时候还可以维护。如果转向微服务架构有成百上千个实例，每修改⼀次配 置要将全部实例重启，不仅增加了系统的不稳定性，也提高了维护的成本。

 
那么如何能够做到服务不重启就可以修改配置？所有就产生了四个基础诉求：

  • 需要支持动态修改配置
  • 需要动态变更有多实时
  • 变更快了之后如何管控控制变更风险，如灰度、回滚等
  • 敏感配置如何做安全配置

 

概念介绍

配置(Configuration)

在系统开发过程中通常会将⼀些需要变更的参数、变量等从代码中分离出来独立管理，以独立的配 置文件的形式存在。目的是让静态的系统工件或者交付物（如 WAR，JAR 包等）更好地和实际的物 理运行环境进行适配。配置管理⼀般包含在系统部署的过程中，由系统管理员或者运维人员完成这 个步骤。配置变更是调整系统运行时的行为的有效手段之⼀。

配置管理 (Configuration Management)

在Nacos 中，系统中所有配置的存储、编辑、删除、灰度管理、历史版本管理、变更审计等所有 与配置相关的活动统称为配置管理。

配置服务 (Configuration Service)

在服务或者应用运行过程中，提供动态配置或者元数据以及配置管理的服务提供者。

配置项（Configuration Item）

⼀个具体的可配置的参数与其值域，通常以 param-key = param-value 的形式存在。例如我们常 配置系统的日志输出级别（logLevel = INFO | WARN | ERROR） 就是⼀个配置项。

配置集（Configuration Set）

⼀组相关或者不相关的配置项的集合称为配置集。在系统中，⼀个配置文件通常就是⼀个配置集， 包含了系统各个方面的配置。例如，⼀个配置集可能包含了数据源、线程池、日志级别等配置项。

命名空间（Namespace）

用于进行租户粒度的配置隔离。不同的命名空间下，可以存在相同的 Group 或 Data ID 的配置。 Namespace 的常用场景之⼀是不同环境的配置的区分隔离，例如开发测试环境和生产环境的资源 （如数据库配置、限流阈值、降级开关）隔离等。如果在没有指定 Namespace 的情况下，默认使 用 public 命名空间。

配置组（Group）

Nacos 中的⼀组配置集，是配置的维度之⼀。通过⼀个有意义的字符串（如 ABTest 中的实验组、 对照组）对配置集进行分组，从而区分 Data ID 相同的配置集。当您在 Nacos 上创建⼀个配置时， 如果未填写配置分组的名称，则配置分组的名称默认采用 DEFAULT_GROUP 。配置分组的常见场 景：不同的应用或组件使用了相同的配置项，如 database_url 配置和 MQ_Topic 配置。

配置 ID（Data ID）

Nacos 中的某个配置集的 ID。配置集 ID 是划分配置的维度之⼀。Data ID 通常用于划分系统的配 置集。⼀个系统或者应用可以包含多个配置集，每个配置集都可以被⼀个有意义的名称标识。Data ID 尽量保障全局唯⼀，可以参考 Nacos Spring Cloud 中的命名规则：
${prefix}-${spring.profiles.active}-${file-extension}

配置快照（Configuration Snapshot）

Nacos 的客户端 SDK 会在本地生成配置的快照。当客户端无法连接到 Nacos Server 时，可以使 用配置快照显示系统的整体容灾能力。配置快照类似于 Git 中的本地 commit，也类似于缓存，会 在适当的时机更新，但是并没有缓存过期（expiration）的概念。

Nacos 配置模型

基础模型

 
上图是Nacos 配置管理的基础模型：

1、 Nacos提供可视化的控制台，可以对配置进行发布、更新、删除、灰度、版本管理等功能；
2、 SDK可以提供发布配置、更新配置、监听配置等功能；
3、 SDK通过GRPC长连接监听配置变更，Server端对比Client端配置的MD5和本地MD5是否相等，不相等推送配置变更；
4、 SDK会保存配置的快照，当服务端出现问题的时候从本地获取；

配置资源模型

Namespace 的设计就是用来进行资源隔离的，我们在进行配置资源的时候可以从以下两个角度来 看：

从单个租户的角度来看，我们要配置多套环境的配置，可以根据不同的环境来创建 Namespace 。 比如开发环境、测试环境、线上环境，我们就创建对应的 Namespace（dev、test、prod）， Nacos 会自动生成对应的 Namespace Id 。如果同⼀个环境内想配置相同的配置，可以通过 Group 来区分。

如下图所示：

 

从多个租户的角度来看，每个租户都可以有自己的命名空间。我们可以为每个用户创建⼀个命名空 间，并给用户分配对应的权限，比如多个租户（zhangsan、lisi、wangwu），每个租户都想有⼀套 自己的多环境配置，也就是每个租户都想配置多套环境。那么可以给每个租户创建⼀个 Namespac e （zhangsan、lisi、wangwu）。同样会生成对应的 Namespace Id。然后使用 Group 来区分不 同环境的配置。

如下图所示：

 

配置存储模型（ER 图）

 
Nacos 存储配置有几个比较重要的表分别是:

  • config_info 存储配置信息的主表，里面包含 dataId、groupId、content、tenantId、encrypt edDataKey 等数据。
  • config_info_beta 灰度测试的配置信息表，存储的内容和 config_info 基本相似。有⼀个 beta _ips 字段用于客户端请求配置时判断是否是灰度的 ip。
  • config_tags_relation 配置的标签表，在发布配置的时候如果指定了标签，那么会把标签和配置 的关联信息存储在该表中。
  • his_config_info 配置的历史信息表，在配置的发布、更新、删除等操作都会记录⼀条数据，可 以做多版本管理和快速回滚。