一、简介

na co架构图_na co架构图


打开NaCos的官网主页,可知道Nacos是一款易于构建云原生应用的动态服务发现、配置管理和服务管理的平台软件。相关的配置管理软件还有:ZooKeeper/Eureka;最新版本V1.4.2 版本及对应文档V2.0.2再2021年06月11日发布。

NaCos可帮助用户发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集,可快速实现动态服务发现、服务配置、服务元数据及流量管理,方便用户更敏捷和容易地构建、交付和管理微服务平台; Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施,即它以服务(Service)为管理单元,Nacos 支持几乎所有主流类型的“服务”的发现、配置和管理。另,阿里云公有云的商业产品(如ACM, EDAS) 中也提供 Nacos 的免费的公有云服务,如果不行部署,可直接订购阿里云产品使用。

na co架构图_元数据_02


官方文档:Nacos

二、架构

2.1、Nacos 生态

Nacos 无缝支持一些主流的开源生态,例如Spring Cloud、Apache Dubbo and Dubbo Mesh、Kubernetes and CNCF。

na co架构图_Nacos_03

2.2、架构

na co架构图_元数据_04


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

na co架构图_na co架构图_05

☯ 服务注册中心 (Service Registry)

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

na co架构图_配置管理_06

☯ Nacos Server:

Nacos服务提供者,里面包含的Open API是功能访问入口,Conig Service、Naming Service 是Nacos提供的配置服务、命名服务模块。Consitency Protocol是一致性协议,用来实现Nacos集群节点的数据同步,这里使用的是Raft算法(Etcd、Redis哨兵选举)

☯ 服务元数据 (Service Metadata)

服务元数据是指包括:服务端点(endpoints)、服务标签、服务版本号、服务实例权重、路由规则、安全策略等描述服务的数据

☯ 服务提供方 (Service Provider)

是指提供可复用和可调用服务的应用方

☯ 服务消费方 (Service Consumer)

是指会发起对某个服务调用的应用方

☯ 配置 (Configuration)

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

☯ 配置管理 (Configuration Management)

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

Nacos同时支持动态配置管理,通过动态配置服务,可以在所有环境中以集中和动态的方式管理所有应用程序或服务的配置信息。

动态配置中心可以实现配置更新时无需重新部署应用程序和服务即可使相应的配置信息生效,这极大了增加了系统的运维能力。

☯ 名字服务 (Naming Service)

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

Name Server:通过VIP(Virtual IP)或DNS的方式实现Nacos高可用集群的服务路由。

☯ 配置服务 (Configuration Service)

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

2.3、逻辑架构及其组件

na co架构图_配置管理_07


☯ 服务管理:实现服务CRUD,域名CRUD,服务健康状态检查,服务权重管理等功能。CRUD(增加(Create)、检索(Retrieve)、更新(Update)和删除(Delete))。

☯ 配置管理:实现配置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一样好用

2.4、数据模型

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

na co架构图_架构_08

2.5、配置模型

Nacos配置,主要有两个关联的实体,一个是配置变更历史,一个是服务标签(用于打标分类,方便索引),由 ID 关联。

na co架构图_元数据_09

2.6 Nacos-SDK 类关系

na co架构图_na co架构图_10

2.7、部署及启动模式

na co架构图_Nacos_11


1)交付方式:

Nacos 支持标准 Docker 镜像(TODO: 0.2版本开始支持)及 zip(tar.gz)压缩包方式交付。

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

2.8、服务注册中心

na co架构图_元数据_12


1)服务实例在启动时会注册到服务注册表,并在关闭时注销

2)服务消费者查询服务注册表,获得可用实例

3)服务注册中心需要调用服务实例的健康检查API来验证它是否能够处理请求

2.9、配置中心

na co架构图_na co架构图_13