这是我参与11月更文挑战的第10天，活动详情查看：2021最后一次更文挑战

基本介绍

• Nacos致力于发现,配置和管理微服务
• Nacos提供了一组简单易用的特性集,快速实现动态服务发现,服务配置,服务元数据及流量管理
• Nacos可以更敏捷和容易地构建,交付和管理微服务平台
• Nacos 是构建以 [服务] 为中心的现代应用架构的服务基础设施

Nacos的特性

• 服务Service是Nacos的一等公民
• Nacos支持几乎所有主流类型的 [服务] 的发现,配置和管理
• Nacos的关键特性:
  • 服务发现和服务健康监测
  • 动态配置服务
  • 动态DNS服务
  • 服务及元数据管理

服务发现和服务健康监测

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

动态配置服务

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

动态DNS服务

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

服务及元数据管理

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

基本概念

地域

• 物理的数据中心
• 资源创建成功后不能更换

可用区

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

接入点

• 地域的某个服务的入口域名

命名空间

• 用于进行租户粒度的配置隔离
• 不同的命名空间下,可以存在相同的Group或Data ID的配置
• Namespace的常用场景 : 是不同环境的配置的区分隔离. 比如开发测试环境和生产环境的配置,服务的隔离等

配置

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

配置管理

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

配置项

• 一个具体的可配置的参数与值域,通常以param-key=param-value的形式存在
• 比如我们常配置系统的日志输出级别:

logLevel=INFO|WARN|ERROR

配置集

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

配置集ID

• Nacos中的某个配置集的ID是组织划分配置的维度之一
• Data ID通常用于组织划分系统的配置集
• 一个系统或者应用可以包含多个配置集,每个配置集都可以被一个有意义的名称标识
• Data ID通常采用类Java包的命名规则保证全局唯一性

配置分组

• Nacos中的一组配置集是组织配置的维度之一
• 通过一个有意义的字符串对配置集进行分组,从而区分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能正常工作

Nacos架构

• 服务: 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是名字服务的两大应用场景
• 配置服务: Configuration Service
  • 在服务或者应用运行过程中,提供动态配置或者元数据以及配置管理的服务提供者

Nacos组件

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

Nacos领域模型

数据模型

• Nacos数据模型Key由三元组唯一确定:
  • 命名空间:Namespace. 默认是空串
  • 公共命名空间:public
  • 分组:Group. 默认分组是DEFAULT_GROUP

服务领域模型

配置领域模型

• 配置领域模型,主要有两个关联的实体: 根据ID进行关联
  • 配置变更历史
  • 服务标签
    • 主要用于打标分类,方便索引
      

类视图

Nacos-SDK类视图

Nacos的构建,部署和启动

• Nacos支持标准Docker镜像及zip或者tar.gz压缩包的构建物
• Nacos支持两种启动模式:
  • 注册中心Service Registry与配置中心Config Center在一个进程合并部署
  • 注册中心Service Registry与配置中心Config Center分离部署