Nacos学习笔记 Nacos基础核心特性

Posted 2022-12-21 鮀城小帅

内容： Nacos架构及其核心特性，包括服务注册、服务发现、发布与获取配置特性，以及Nacos Spring关键特性。

本文内容，参考 Nacos 官网与 《Nacos架构&原理》一书。

1. Nacos 架构

详情推荐参考：

（1）官网：Nacos架构

（2）《Nacos架构&原理》的 【Nacos总体设计】、【Nacos内核设计】两个小章节。

1.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)

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

1.2 逻辑架构与组件

用户层

• 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 系统打通，通知到对应人数据变更

2. Nacos特性 -- 服务定义

详情参考：《Nacos架构&原理》的 【Nacos服务发现模块】章节。

2.1 服务

在服务发现领域中，服务指的是由应用程序提供的⼀个或⼀组软件功能的⼀种抽象概念（例如上述例子的登陆或支付）。它和应用有所不同，应用的范围更广，和服务属于包含关系，即⼀个应用可能会提供多个服务。为了能够更细粒度地区分和控制服务，Nacos 选择服务作为注册中心的最基本概念。

而服务实例（以下简称实例）是某个服务的具体提供能力的节点，⼀个实例仅从属于⼀个服务，而一个服务可以包含一个或多个实例。在许多场景下，实例又被称为服务提供者（Provider），而使用该服务的实例被称为服务消费者（Consumer）。

2.2 服务的定义

在 Nacos 中，服务的定义包括以下几个内容：

命名空间（Namespace）：Nacos 数据模型中最顶层、也是包含范围最广的概念，用于在类似环境或租户等需要强制隔离的场景中定义。Nacos的服务也需要使用命名空间来进行隔离。
属性，分组属于⼀个弱隔离概念，主要用于逻辑区分⼀些服务使用场景或不同应用的同名服务，最常用的情况主要是同⼀个服务的测试分组和生产分组、或者将应用名作为分组以防止不同应用提供的服务重名。

服务名（Name）：该服务实际的名字，⼀般用于描述该服务提供了某种功能或能力。

        之所以 Nacos 将服务的定义拆分为命名空间、分组和服务名，除了方便隔离使用场景外，还有方便用户发现唯⼀服务的优点。在注册中心的实际使用场景上，同个公司的不同开发者可能会开发出类似作用的服务，如果仅仅使用服务名来做服务的定义和表示，容易在⼀些通用服务上出现冲突，比如登陆服务等。

2.3 服务元数据

服务的定义只是为服务设置了⼀些基本的信息，用于描述服务以及方便快速的找到服务，而服务的元数据是进⼀步定义了 Nacos 中服务的细节属性和描述信息。

• 健康保护阈值（ProtectThreshold）：为了防止因过多实例故障，导致所有流量全部流入剩余实例，继而造成流量压力将剩余实例被压垮形成的雪崩效应。
• 实例选择器（Selector）：用于在获取服务下的实例列表时，过滤和筛选实例。
• 拓展数据(extendData)：用于用户在注册实例时自定义扩展的元数据内容，形式为 K-V 。

2.4 定义实例

Nacos实例主要包括以下内容：

• 网络 IP 地址：该实例的 IP 地址，在 Nacos2.0 版本后支持设置为域名。
• 网络端口：该实例的端口信息。
• 健康状态（Healthy）：用于表示该实例是否为健康状态，会在 Nacos 中通过健康检查的手段进行维护，具体内容将在 Nacos 健康检查机制章节中详细说明，读者目前只需要该内容的含义即可。
• 集群（Cluster）：用于标示该实例归属于哪个逻辑集群，有关于集群的相关内容，将在后文详细说明。
• 拓展数据(extendData)：用于用户自定义扩展的元数据内容，形式为 K-V。可以在实例中拓展该实例的元数据信息，方便用户实现自己的自定义逻辑和标示该实例。

 2.5 实例元数据

实例的元数据主要作用于实例运维相关的数据信息。主要包含：

• 权重（Weight）：实例级别的配置。权重为浮点数，范围为 0-10000。权重越大，分配给该实例的流量越大。
• 上线状态（Enabled）：标记该实例是否接受流量，优先级大于权重和健康状态。用于运维人员在不变动实例本身的情况下，快速地手动将某个实例从服务中移除。
• 拓展数据(extendData)：不同于实例定义中的拓展数据，这个拓展数据是给予运维人员在不变动实例本身的情况下，快速地修改和新增实例的扩展数据，从而达到运维实例的作用。

2.6 持久化属性

Nacos 提供两种类型的服务：持久化服务和非持久化服务，分别给类 DNS 的基础的服务组件场景和上层实际业务服务场景使用。

3. Nacos特性 -- 服务注册

在 Nacos 中，发起服务注册有两种方式，⼀种是直接创建服务，⼀种是注册实例时自动创建服务。

Nacos中，实例有两种：临时实例、永久实例。

（1）临时实例

在 Nacos 中，用户可以通过两种方式进行临时实例的注册，通过 Nacos 的 OpenAPI 进行服务注册或通过 Nacos 提供的 SDK 进行服务注册。

OpenAPI 的注册方式实际是用户根据自身需求调用 Http 接口对服务进行注册，然后通过 Http 接口发送心跳到注册中心。在注册服务的同时会注册⼀个全局的客户端心跳检测的任务。在服务⼀段时间没有收到来自客户端的心跳后，该任务会将其标记为不健康，如果在间隔的时间内还未收到心跳，那么该任务会将其剔除。

SDK 的注册方式实际是通过 RPC 与注册中心保持连接（Nacos 2.x 版本中，旧版的还是仍然通过OpenAPI 的方式），客户端会定时的通过 RPC 连接向 Nacos 注册中心发送心跳，保持连接的存活。如果客户端和注册中心的连接断开，那么注册中心会主动剔除该 client 所注册的服务，达到下线的效果。同时 Nacos 注册中心还会在注册中心启动时，注册⼀个过期客户端清除的定时任务，用于删除那些健康状态超过⼀段时间的客户端。

（2）永久实例

Nacos 中使用 SDK 对于永久实例的注册实际也是使用 OpenAPI 的方式进行注册，这样可以保证即使是客户端下线后也不会影响永久实例的健康检查。

对于永久实例的的监看检查，Nacos 采用的是注册中心探测机制，注册中心会在永久服务初始化时根据客户端选择的协议类型注册探活的定时任务。Nacos 现在内置提供了三种探测的协议，即
Http、TCP 以及 mysql 。⼀般而言 Http 和 TCP 已经可以涵盖绝大多数的健康检查场景。

访问数据库是否为主库时，那么我们此时的健康检查接口，是⼀个检查数据库是否为主库的 MySQL命令。

4. Nacos特性 -- 服务发现

服务消费者（Nacos Client）在调用服务提供者的服务时，会发送一个REST请求给Nacos Server，获取上面注册的服务清 单，并且缓存在Nacos Client本地，同时会在Nacos Client本地开启一个定时任务定时拉取服务端最新的注册表信息更新到本地缓存。

5. Nacos特性 -- 发布与获取配置

待补充