nacos学习----day01

目录

一、nacos简介

二、nacos设计

2.1 nacos总体架构设计​

2.2 nacos内核设计 

---

 一、nacos简介

        Nacos 是 Dynamic Naming and Configuration Service 的首字母简称；⼀个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。引用官网简介：Nacos 致力于帮助您发现、配置和管理微服务。Nacos提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。 Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式)的服务基础设施。是阿里DNS（Dubbo+Nacos+Spring- cloud-alibaba/Seata/Sentinel）微服务最佳实践。

官网：https://nacos.io/ 仓库：https://github.com/alibaba/nacos

二、nacos设计

2.1 nacos总体架构设计

        nacos的整体架构分为用户层、业务层、内核层和插件

        用户层：主要解决用户使用的易用性问题

• 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.2 nacos内核设计 

2.2.1 一致性模型：AP+CP

        为什么需要一致性协议：nacos在内部实现了数据存储，用于存储持久化的服务元数据，在单机模式下时，只需要内嵌关系型数据库就可以，但是为了实现高可用，正式环境都会部署集群环境，就需要考虑到如何保障各个节点之间的数据一致性和数据同步，因此需要引入共识算法，而nacos选择了Raft协议（CP模式）和Distro协议（AP模式）。

        这里会有一个问题，为什么nacos在一个集群中同时运行了AP和CP协议，主要是针对nacos的配置管理和服务注册两者来考虑：

服务注册：

        服务注册发现中心组件是一个十分重要的组件，服务之间感知对方服务的当前可正常提供服务的实例信息，必须从服务发现注册中心进行获取。nacos服务分为两种：非持久化服务（需要客户端上报心跳进行服务实例续约）；持久化服务。

        针对非持久化服务而言，服务注册发现中心组件必须实现高可用，尽最大可能保证服务注册发现能力可以对外提供服务，所以服务注册发现中心组件只能使用CP（最终一致性）算法，CP可能会造成一定的数据丢失，因此nacos针对数据丢失也提出了解决方案，采取了心跳可自动完成服务数据补偿的机制。

        而针对持久化服务而言，因为所有的数据都是直接使用调用Nacos服务端直接创建，因此需要由 Nacos 保障数据在各个节点之间的强⼀致性，所以这里nacos使用了强一致性算法。

配置管理：

        配置数据也都是直接调用Nacos服务端进行创建和管理的，必须保证大部分的节点都保存了此配置数据才能认为配置成功保存，因此配置管理也是有了强一致性算法。