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)
- 设计目标,是期望nacos存在两种数据存储模式,用户能够使用命令行参数配置的方式,随意使用这两种数据存储模式
- 总体:
- 将一次请求操作涉及的SQL上下文按顺序保存起来。
- 然后通过一致协议层将本次请求涉及的SQL上下文进行同步,
- 然后每个节点将其解析并重新按顺序在一次数据库会话中执行。
- 谁可以处理请求
- 内嵌分布式关系型数据存储时,所有的写操作请求都将路由到Leader节点进行处理
- 由于Raft状态机的特性,当某一个节点在apply数据库操作请求时发生非SQL逻辑错误引发的异常时,
- 将导致状态机无法继续正常进行工作
- 此时将会触发配置管理模块的降级操作
- 所有的操作抽象为sql的增删改查,粗分为两类,查询和更新
- 配置发布是一个事务,涉及3个操作
- config_info保存配置信息
- config_tags_relation保存配置与标签的关联关系
- his_config_info保存一条配置操作历史记录
- 不能一个操作提交一次raft,
- 因为如果后续操作apply失败
- 就需要回滚之前的操作,这样就变成了分布式事务,增加了问题复杂度
- 将3个操作打包提交,解决了这个问题
- 由于Raft协议对于事务日志的处理是串行执行的,因此相当于将数据库的事务隔离级别调整为串行化。
- 内嵌分布式关系型数据存储时,所有的写操作请求都将路由到Leader节点进行处理
- 存储配置
- 不足
- 在数据库上层构建一层分布式数据操作同步层,对数据库的操作存在了限制,
- 比如第一步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者分离部署的两种模式。