一文了解 Nacos

Nacos 在阿里巴巴起源于 $2008$ 年五彩石项目（完成微服务拆分和业务中台建设），成长于十年双十一的洪峰考验，沉淀了简单易用、稳定可靠、性能卓越的核心竞争力。 随着云计算兴起，$2018$ 年 Nacos（阿里内部 Configserver/Diamond/ Vipserver 内核）开源，作为阿里十年的沉淀，推动微服务行业发展，加速企业数字化转型!

1.简介

1.1 概览

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

Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。

Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以 服务 为中心的现代应用架构（例如微服务范式、云原生范式）的服务基础设施。

1.2 什么是 Nacos

服务（Service）是 Nacos 世界的一等公民。Nacos 支持几乎所有主流类型的 “服务” 的发现、配置和管理：

• Kubernetes Service
• gRPC & Dubbo RPC Service
• Spring Cloud RESTful Service

Nacos 的关键特性包括：

• 服务发现和服务健康监测

  • Nacos 支持基于 DNS 和基于 RPC 的服务发现。服务提供者使用 原生SDK、OpenAPI、或一个 独立的 Agent TODO 注册 Service 后，服务消费者可以使用 DNS TODO 或 HTTP&API 查找和发现服务。
  • Nacos 提供对服务的实时的健康检查，阻止向不健康的主机或服务实例发送请求。Nacos 支持传输层 （PING 或 TCP）和应用层（如 HTTP、MySQL、用户自定义）的健康检查。 对于复杂的云环境和网络拓扑环境中（如 VPC、边缘网络等）服务的健康检查，Nacos 提供了 agent 上报模式 和 服务端主动检测 $2$ 种健康检查模式。Nacos 还提供了统一的健康检查仪表盘，帮助您根据健康状态管理服务的可用性及流量。

• 动态配置服务

  • 动态配置服务可以让您以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。
  • 动态配置消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。
  • 配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。
  • Nacos 提供了一个简洁易用的UI（控制台样例 Demo）帮助您管理所有的服务和应用的配置。Nacos 还提供包括配置版本跟踪、金丝雀发布、一键回滚配置以及客户端配置更新状态跟踪在内的一系列开箱即用的配置管理特性，帮助您更安全地在生产环境中管理配置变更和降低配置变更带来的风险。

• 动态 DNS 服务

  • 动态 DNS 服务支持权重路由，让您更容易地实现中间层负载均衡、更灵活的路由策略、流量控制以及数据中心内网的简单 DNS 解析服务。动态 DNS 服务还能让您更容易地实现以 DNS 协议为基础的服务发现，以帮助您消除耦合到厂商私有服务发现 API 上的风险。
  • Nacos 提供了一些简单的 DNS APIs TODO 帮助您管理服务的关联域名和可用的 IP:PORT 列表.

• 服务及其元数据管理

  • Nacos 能让您从微服务平台建设的视角管理数据中心的所有服务及元数据，包括管理服务的描述、生命周期、服务的静态依赖分析、服务的健康状态、服务的流量管理、路由及安全策略、服务的 SLA 以及最首要的 metrics 统计数据。

1.3 Nacos 地图

一图看懂 Nacos，下面架构部分会详细介绍。

• 特性大图：要从功能特性，非功能特性，全面介绍我们要解的问题域的特性诉求。
• 架构大图：通过清晰架构，让您快速进入 Nacos 世界。
• 业务大图：利用当前特性可以支持的业务场景，及其最佳实践。
• 生态大图：系统梳理 Nacos 和主流技术生态的关系。
• 优势大图：展示 Nacos 核心竞争力。
• 战略大图：要从战略到战术层面讲 Nacos 的宏观优势。

1.4 Nacos 生态图

如 Nacos 全景图所示，Nacos 无缝支持一些主流的开源生态，例如

• Spring Cloud
• Apache Dubbo and Dubbo Mesh
• Kubernetes and CNCF

使用 Nacos 简化服务发现、配置管理、服务治理及管理的解决方案，让微服务的发现、管理、共享、组合更加容易。

2.概念

Nacos 引入了一些基本的概念，系统性的了解一下这些概念可以帮助您更好的理解和正确的使用 Nacos 产品。

• 地域：物理的数据中心，资源创建成功后不能更换。

• 可用区：同一地域内，电力和网络互相独立的物理区域。同一可用区内，实例的网络延迟较低。

• 接入点：地域的某个服务的入口域名。

• 命名空间：用于进行租户粒度的配置隔离。不同的命名空间下，可以存在相同的 Group 或 Data ID 的配置。Namespace 的常用场景之一是不同环境的配置的区分隔离，例如开发测试环境和生产环境的资源（如配置、服务）隔离等。

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

• 配置管理：系统配置的编辑、存储、分发、变更管理、历史版本管理、变更审计等所有与配置相关的活动。

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

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

• 配置集 ID：Nacos 中的某个配置集的 ID。配置集 ID 是组织划分配置的维度之一。Data ID 通常用于组织划分系统的配置集。一个系统或者应用可以包含多个配置集，每个配置集都可以被一个有意义的名称标识。Data ID 通常采用类 Java 包（如 com.taobao.tc.refund.log.level）的命名规则保证全局唯一性。此命名规则非强制。

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

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

• 服务：通过预定义接口网络访问的提供给客户端的软件功能。

• 服务名：服务提供的标识，通过该标识可以唯一确定其指代的服务。

• 服务注册中心：存储服务实例和服务负载均衡策略的数据库。

• 服务发现：在计算机网络上，（通常使用服务名）对服务下的实例的地址和元数据进行探测，并以预先定义的接口提供给客户端进行查询。

• 元信息：Nacos 数据（如配置和服务）描述信息，如服务版本、权重、容灾策略、负载均衡策略、鉴权配置、各种自定义标签（label），从作用范围来看，分为服务级别的元信息、集群的元信息及实例的元信息。

• 应用：用于标识服务提供方的服务的属性。

• 服务分组：不同的服务可以归类到同一分组。

• 虚拟集群：同一个服务下的所有服务实例组成一个默认集群, 集群可以被进一步按需求划分，划分的单位可以是虚拟集群。

• 实例：提供一个或多个服务的具有可访问网络地址（IP:Port）的进程。

• 权重：实例级别的配置。权重为浮点数。权重越大，分配给该实例的流量越大。

• 健康检查：以指定方式检查服务下挂载的实例（Instance）的健康度，从而确认该实例是否能提供服务。根据检查结果，实例会被判断为健康或不健康。对服务发起解析请求时，不健康的实例不会返回给客户端。

• 健康保护阈值：为了防止因过多实例不健康导致流量全部流向健康实例，继而造成流量压力把健康实例压垮并形成雪崩效应，应将健康保护阈值定义为一个 0 到 1 之间的浮点数。当域名健康实例数占总服务实例数的比例小于该值时，无论实例是否健康，都会将这个实例返回给客户端。这样做虽然损失了一部分流量，但是保证了集群中剩余健康实例能正常工作。

3.架构

3.1 基本架构及概念

• 服务（Service）：服务是指一个或一组软件功能（例如特定信息的检索或一组操作的执行），其目的是不同的客户端可以为不同的目的重用（例如通过跨进程的网络调用）。Nacos 支持主流的服务生态，如 Kubernetes Service、gRPC|Dubbo RPC Service 或者 Spring Cloud RESTful Service。

• 服务注册中心（Service Registry）：服务注册中心，它是服务，其实例及元数据的数据库。服务实例在启动时注册到服务注册表，并在关闭时注销。服务和路由器的客户端查询服务注册表以查找服务的可用实例。服务注册中心可能会调用服务实例的健康检查 API 来验证它是否能够处理请求。

• 服务元数据（Service Metadata）：服务元数据是指包括服务端点（endpoints）、服务标签、服务版本号、服务实例权重、路由规则、安全策略等描述服务的数据。

• 服务提供方（Service Provider）：是指提供可复用和可调用服务的应用方。

• 服务消费方（Service Consumer）：是指会发起对某个服务调用的应用方。

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

• 配置管理（Configuration Management）：在数据中心中，系统中所有配置的编辑、存储、分发、变更管理、历史版本管理、变更审计等所有与配置相关的活动统称为配置管理。

• 名字服务（Naming Service）：提供分布式系统中所有对象（Object）、实体（Entity）的 “名字” 到关联的元数据之间的映射管理服务，例如 ServiceName -> Endpoints Info，Distributed Lock Name -> Lock Owner/Status Info，DNS Domain Name -> IP List，服务发现和 DNS 就是名字服务的 $2$ 大场景。

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

3.2 逻辑架构及其组件介绍

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

3.3 领域模型

（1）数据模型

Nacos 数据模型 Key 由三元组唯一确定，Namespace 默认是空串，公共命名空间（public），分组默认是 DEFAULT_GROUP。

（2）服务领域模型

（3）配置领域模型

围绕配置，主要有两个关联的实体，一个是配置变更历史，一个是服务标签（用于打标分类，方便索引），由 ID 关联。

（4）类视图

Nacos-SDK 类视图（服务部分待续）

3.4 构建物、部署及启动模式

• 两种交付工件：Nacos 支持标准 Docker 镜像（TODO: $0.2$ 版本开始支持）及 zip（tar.gz）压缩包的构建物。

• 两种启动模式：Nacos 支持将注册中心（Service Registry）与配置中心（Config Center）在一个进程合并部署或者将2者分离部署的两种模式。

• 免费的公有云服务模式：除了您自己部署和启动 Nacos 服务之外，在云计算时代，Nacos 也支持公有云模式，在阿里云公有云的商业产品（如 ACM，EDAS）中会提供 Nacos 的免费的公有云服务。我们也欢迎和支持其他的公有云提供商提供 Nacos 的公有云服务。