Spring Cloud Alibaba 之 Nacos

Nacos

官网

https://nacos.io/zh-cn/docs/what-is-nacos.html

nacos是什么

• 注册中⼼+配置中⼼的组合（Nacos=Eureka+Config+Bus）
• 发现、配置和管理微服务

功能

• 服务发现：支持
  • Spring Cloud RESTful Service
  • gRPC & Dubbo RPC Service
  • Kubernetes Service
• 服务健康检查
• 服务及其元数据管理（
  • 管理平台， nacos也有⼀个ui⻚⾯
  • 可以查询注册的服务及其实例信息（元数据信息）等
  • 支持动态的服务权重调整、动态服务优雅下线
• 动态配置管理
• 动态DNS服务

概念

• 地域：物理的数据中心，资源创建成功后不能更换。
• 可用区：同一地域内，电力和网络互相独立的物理区域。同一可用区内，实例的网络延迟较低。
• 接入点：地域的某个服务的入口域名。
• 命名空间：
  • 用于进行租户粒度的配置隔离。
  • 不同的命名空间下，可以存在相同的 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) 的健康度，从而确认该实例 (Instance) 是否能提供服务。
    • 根据检查结果，实例 (Instance) 会被判断为健康或不健康。对服务发起解析请求时，不健康的实例 (Instance) 不会返回给客户端。
  • 健康保护阈值
    • 为了防止因过多实例 (Instance) 不健康导致流量全部流向健康实例 (Instance) ，
    • 继而造成流量压力把健康实例 (Instance) 压垮并形成雪崩效应，
    • 应将健康保护阈值定义为一个 0 到 1 之间的浮点数。
    • 当域名健康实例数 (Instance) 占总服务实例数 (Instance) 的比例小于该值时，
    • 无论实例 (Instance) 是否健康，都会将这个实例(Instance) 返回给客户端。
    • 这样做虽然损失了一部分流量，但是保证了集群中剩余健康实例 (Instance) 能正常工作。

架构

服务 (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)

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

逻辑架构

组件

• 服务管理：实现服务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一样好用

参考：Nacos 1.3.0 特性以及功能使用文档

关注

• 关注核心功能服务发现和配置管理，忽略边缘功能
• 关注实现思路与原理，暂时忽略细节
• 这样我们关注
  • 底层
    • 寻址模式
      • 单点部署
      • FileConfigMemberLookup：配置文件寻址
        • 在cluster.conf文件中配置集群成员
        • 首次启动读取配置文件，寻找其他成员
        • 向操作系统注册目录监听，支持动态的缩扩容
        • 需要手动去修改每个节点的配置文件
      • AddressServerMemberLookup：
        • 基于一个额外的web服务器来管理cluster.conf
        • 每个节点定期向该web服务器请求cluster.conf的文件内容，然后实现集群节点间的寻址
        • 当需要进行集群扩缩容时，只需要修改cluster.conf文件即可，然后每个节点向地址服务器请求时会自动的得到最新的cluster.conf
    • 一致性协议
      • 抽象统一的一致性协议层，便于统一和提换
      • 不同的模块使用不同的一致性模型
      • 目前使用的raft实现为JRaft，以后可能替换
        • JRaft实现了Raft Group，可以让不同的模块使用不同的Raft Group，隔离影响
        • 提供了JRaft运维接口，在异常情况下可以快速恢复，但是大概率可能造成数据不一致
          
    • 存储模块
      • 基于Derby的分布式关系型存储
      • 背景
        • nacos内部一些元数据信息存储，比如用户信息，命名空间信息
        • 如果配置文件数量较少，在集群模式下需要高可用数据库集群作为支撑的成本太大，期望有一个轻量的分布式关系型存储来解决
      • 设计思路
        • 设计目标，是期望nacos存在两种数据存储模式，用户能够使用命令行参数配置的方式，随意使用这两种数据存储模式
          • 一种是现在的方式，数据存储在外置数据源（关系型数据库）
          • 第二种方式是内嵌存储数据源（Apache Derby）
            
      • 总体：
        • 将一次请求操作涉及的SQL上下文按顺序保存起来。
        • 然后通过一致协议层将本次请求涉及的SQL上下文进行同步，
        • 然后每个节点将其解析并重新按顺序在一次数据库会话中执行。
          
      • 谁可以处理请求
        • 内嵌分布式关系型数据存储时，所有的写操作请求都将路由到Leader节点进行处理
          • 由于Raft状态机的特性，当某一个节点在apply数据库操作请求时发生非SQL逻辑错误引发的异常时，
          • 将导致状态机无法继续正常进行工作
          • 此时将会触发配置管理模块的降级操作
            
          • 所有的操作抽象为sql的增删改查，粗分为两类，查询和更新
          • 配置发布是一个事务，涉及3个操作
            • config_info保存配置信息
            • config_tags_relation保存配置与标签的关联关系
            • his_config_info保存一条配置操作历史记录
          • 不能一个操作提交一次raft，
            • 因为如果后续操作apply失败
            • 就需要回滚之前的操作，这样就变成了分布式事务，增加了问题复杂度
          • 将3个操作打包提交，解决了这个问题
          • 由于Raft协议对于事务日志的处理是串行执行的，因此相当于将数据库的事务隔离级别调整为串行化。
            
      • 存储配置
        
    • 不足
      • 在数据库上层构建一层分布式数据操作同步层，对数据库的操作存在了限制，
        • 比如第一步insert操作，然后select操作，最后在update操作，
        • 这种在数据修改语句中穿插着查询语句的操作顺序是不支持的
      • 限制了数据库的性能，由于间接的将数据库事务隔离级别调整为了串行化，人为的将并发能力降低了
    • 未来
      • 将于Apache Derby官方一起尝试基于Raft实现BingLog的同步复制操作，从底层实现数据库同步能力
  • 服务管理：
  • 配置管理：

领域模型

数据模型

• 概念与用法：
  • Namespace：命名空间，对不同的环境进⾏隔离，⽐如隔离开发环境、测试环境和⽣产环境
  • Group：分组，将若⼲个服务或者若⼲个配置集归为⼀组，通常习惯⼀个系统归为⼀个组
  • Service：某⼀个服务，⽐如简历微服务
  • DataId：配置集或者可以认为是⼀个配置⽂件
  • Namespace + Group + Service唯一定位一个服务，类似于maven的gav
  • Namespace + Group + DataId唯一定位一个配置文件，类似于maven的gav
• Nacos抽象出了Namespace、 Group、 Service、 DataId等概念，具体代表什么取决于怎么⽤

服务领域模型

配置领域模型

数据持久化

• Nacos 默认使⽤嵌⼊式数据库进⾏数据存储，它⽀持改为外部Mysql存储

构建部署模式

• 免费的Nacos 的公有云服务或自己部署
• Nacos 支持将注册中心(Service Registry）与配置中心(Config Center) 在一个进程合并部署或者将2者分离部署的两种模式。