nacos学习（一）——nacos介绍

  • Nacos 起源
  • Nacos 定位
  • Nacos 优势
  • Nacos 生态
  • 设计原则
  • 架构图
    • 用户层
    • 业务层
    • 内核层
    • 插件
  • Nacos 配置模型
    • 背景
    • 概念介绍
      • 配置(Configuration)
      • 配置管理 (Configuration Management)
      • 配置服务 (Configuration Service)
      • 配置项（Configuration Item）
      • 配置集（Configuration Set）
      • 命名空间（Namespace）
      • 配置组（Group）
      • 配置 ID（Data ID）
      • 配置快照（Configuration Snapshot）
    • Nacos 配置模型
    • 配置资源模型
    • 配置存储模型（ER 图）

Nacos 起源


Nacos 在阿里巴巴起源于 2008 年五彩石项目（完成微服务拆分和业务中台建设），成长于十年双 十⼀的洪峰考验，沉淀了简单易用、稳定可靠、性能卓越的核心竞争力。 随着云计算兴起，2018 年阿里开发团队深刻感受到开源软件行业的影响，因此决定将 Nacos（阿里内部 Configserver/Diamond/ Vipserver 内核） 开源，输出阿里十年的沉淀，推动微服务行业发展，加速企业数字化转型！

Nacos 定位

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

官网：https://nacos.io/
仓库：https://github.com/alibaba/nacos

Nacos 优势

易⽤：简单的数据模型，标准的 restfulAPI，易用的控制台，丰富的使用文档。
稳定：99.9% 高可用，脱胎于历经阿里巴巴 10 年生产验证的内部产品，支持具有数百万服务的大 规模场景，具备企业级 SLA 的开源产品。
实时：数据变更毫秒级推送生效；1w 级，SLA 承诺 1w 实例上下线 1s，99.9% 推送完成；10w 级，SLA 承诺 1w 实例上下线 3s，99.9% 推送完成；100w 级别，SLA 承诺 1w 实例上下线 9s 99.9% 推送完成。
规模：十万级服务/配置，百万级连接，具备强大扩展性。

Nacos 生态

Nacos 几乎支持所有主流语言，其中 Java/Golang/Python 已经支持 Nacos 2.0 长链接协议，能 最大限度发挥 Nacos 性能。阿里微服务 DNS（Dubbo+Nacos+Spring-cloud-alibaba/Seata/ Sentinel）最佳实践，是 Java 微服务生态最佳解决方案；除此之外，Nacos 也对微服务生态活跃 的技术做了无缝的支持，如目前比较流行的 Envoy、Dapr 等，能让用户更加标准获取微服务能力。 生态仓库：https://github.com/nacos-group。

设计原则

 极简原则，简单才好用，简单才稳定，简单才易协作。
 架构⼀致性，⼀套架构要能适应开源、内部、商业化（公有云及专有云）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 配置的历史信息表，在配置的发布、更新、删除等操作都会记录⼀条数据，可 以做多版本管理和快速回滚。