Nacos架构

互联网架构发展历史

详情参考https://zhuanlan.zhihu.com/p/136587858

什么是注册中心

注册中心是服务实例信息的存储仓库，也是服务提供者和服务消费者进行交互的桥梁。它主要提供了服务注册和服务发现这两大核心功能

服务提供者把自己注册到注册中心上、服务消费者就可以从注册中心找到该服务提供者的实例信息 从而调用服务提供者的接口获取信息

注册中心产生的原因

1. 分布式架构下，服务越来越多，单靠人工来管理和维护服务及地址的配置信息会越来越困难
2. 服务越来越多，也就意味着服务间的依赖关系越来越复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。 这时，需要自动画出应用间的依赖关系图，以帮助架构师理清关系。
3. 服务的调用量越来越大，服务容量问题暴露出来，这个服务需要多少机器支撑，什么时候改增加机器？为了解决这些问题，第一步，要将服务现在每天的调用量，响应时间，都统计出来，作为容量规划的参考指标。其次，要可以动态调整权重，在线上，将某台机器的权重一直加大，并在加大的过程中记录响应时间的变化，直到响应时间到达阈值，记录此时的访问量，再以此访问量乘以机器数反推总容量。
4. 一旦服务路由或者负载均衡服务器宕机，依赖它提供方服务的所有服务均将失效。

注册中心需要考虑的问题

1.服务注册/下线后，服务如何被被发现；
2.服务异常时，服务如何进行降级；
3.服务发现时，服务如何进行路由；
4.当有多台提供方的服务，消费方如何进行负载均衡消费；
5.服务重新上下后怎么快速恢复
6.可用性怎么保障
7.集群情况下如果出现脑裂怎么办
8.集群节点中数据一致性怎么保障等一系列问题

什么是配置中心

使用微服务就意味着要将单体应用中的业务拆分成一个个的子服务，每个服务的粒度相对较小，因此，系统中将会出现大量的服务。由于每一个服务都需要必要的配置信息才能运行，所以也将会产生大量的配置文件，所以有一套对配置文件进行集中式、动态式的管理的设施就必不可少了。

常见对配置的管理有三种：

传统的配置方式：配置信息分散到系统各个角落方式，配置文件或者在代码中。
集中式配置中心：将应用系统中对配置信息的管理作为一个新的应用功能模块，进行集中统一管理，并且提供额外功能。
分布式配置中心：在分布式、微服务架构中，独立的配置中心服务。

配置中心产生的原因

在单体架构的时候我们可以将配置写在配置文件中，但有⼀个缺点就是每次修改配置都需要重启服务才能生效。
当应用程序实例比较少的时候还可以维护。如果转向微服务架构有成百上千个实例，每修改⼀次配置要将全部实例重启，不仅增加了系统的不稳定性，也提高了维护的成本。

配置中心需要考虑的问题

 需要支持动态修改配置
 需要动态变更有多实时
 变更快了之后如何管控控制变更风险，如灰度、回滚等
 敏感配置如何做安全配置

主流注册中心对比

什么是Nacos

Nacos /nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service的首字母简称，一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

Nacos 致力于帮助您发现、配置和管理微服务。Nacos 提供了一组简单易用的特性集，帮助您快速实现动态服务发现、服务配置、服务元数据及流量管理。

Nacos 帮助您更敏捷和容易地构建、交付和管理微服务平台。 Nacos 是构建以“服务”为中心的现代应用架构 (例如微服务范式、云原生范式) 的服务基础设施。

Nacos起源

Nacos 在阿里巴巴起源于 2008 年五彩石项目（完成微服务拆分和业务中台建设），成长于十年双
十⼀的洪峰考验，沉淀了简单易用、稳定可靠、性能卓越的核心竞争力。 随着云计算兴起，2018
年我们深刻感受到开源软件行业的影响，因此决定将 Nacos（阿里内部 Configserver/Diamond/
Vipserver 内核） 开源，输出阿里十年的沉淀，推动微服务行业发展，加速企业数字化转型！

Nacos定位

Nacos/nɑ:kəʊs/ 是 Dynamic Naming and Configuration Service 的首字母简称；⼀个更易于构
建云原生应用的动态服务发现、配置管理和服务管理平台。

Nacos的优势

易⽤：简单的数据模型，标准的 restfulAPI，易用的控制台，丰富的使用文档。
稳定：99.9% 高可用，脱胎于历经阿里巴巴 10 年生产验证的内部产品，支持具有数百万服务的大规模场景，具备企业级 SLA 的开源产品。
实时：数据变更毫秒级推送生效；1w 级，SLA 承诺 1w 实例上下线 1s，99.9% 推送完成；10w级，SLA 承诺 1w 实例上下线 3s，99.9% 推送完成；100w 级别，SLA 承诺 1w 实例上下线 9s 99.9% 推送完成。
规模：十万级服务/配置，百万级连接，具备强大扩展性。

Nacos架构

设计原则

 极简原则，简单才好用，简单才稳定，简单才易协作。
 架构⼀致性，⼀套架构要能适应开源、内部、商业化（公有云及专有云）3 个场景。
 扩展性，以开源为内核，商业化做基础，充分扩展，方便用户扩展。
 模块化，将通用部分抽象下沉，提升代码复用和健壮性。
 长期主义，不是要⼀个能支撑未来 3 年的架构，而是要能够支撑 10 年的架构。
 开放性，设计和讨论保持社区互动和透明，方便大家协作。

架构分层

整体架构分为用户层、业务层、内核层和插件，用户层主要解决用户使用的易用性问题，业务层主
要解决服务发现和配置管理的功能问题，内核层解决分布式系统⼀致性、存储、高可用等核心问题，
插件解决扩展性问题。

用户层

 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 系统打通，通知到对应人数据变更。