SpringCloudAlibaba系列(二)：注册中心、Nacos特性及基本概念和模型

Nacos：是 阿里开源的一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

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

注册中心

注册中心：是微服务架构中不可或缺的基础组件，为服务调用提供 服务注册和服务发现，这两个是注册中心的核心功能。还提供服务上下线通知，支持集群部署实现自身的高可用。

服务发现

注册中心必然提供服务发现功能。

服务发现是微服务架构体系中最关键的组件之一。如果尝试着用手动的方式来给每一个客户端来配置所有服务提供者的服务列表是一件非常困难的事，而且也不利于服务的动态扩缩容。

Nacos Discovery Starter 可以帮助您将服务自动注册到 Nacos 服务端并且能够动态感知和刷新某个服务实例的服务列表。

除此之外，Nacos Discovery Starter 也将服务实例自身的一些元数据信息，例如 host，port，健康检查URL，主页等注册到 Nacos 。

相关组件

目前常见的注册中心有：

• Spring Cloud Eureka
• Spring Cloud Zookeeper
• Spring Cloud Consul
• Spring Cloud Alibaba Nacos

特性对比总览：

CAP 原则

• C：Consistency，一致性，所有节点的数据副本一致性。
• A：Availability，可用性，一部分节点故障后，集群整体仍能提供服务。
• P：Partition tolerance，分区容错，一个节点挂了，并不影响其它节点。

在一个分布式系统中，基于网络的不稳定性，分区容错（P）是必须保证的，一致性（A）和可用性（P）两者是存在矛盾的，只能选其一，没有那个好坏，而是要根据实现的业务场景来选择最适用的来进行架构设计。

比如金融行业，就要求一致性多一点，可选择 Consul、Zookeeper；比如电商系统，就要求可用性多一点，可选择 Eureka。

Nacos

以下资料全部来自于官网。个人倾向于对其所有概念仔细看一遍，并做一遍记录，形成自己的记忆。

概览

Nacos：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

服务（Service）是 Nacos 世界的一等公民。Nacos 支持几乎所有主流类型的“服务”的发现、配置和管理：

• Kubernetes Service
• gRPC & Dubbo RPC Service
• Spring Cloud RESTful Service

使用 Nacos 简化服务发现、配置管理、服务治理及管理的解决方案，让微服务的发现、管理、共享、组合更加容易。

关键特性

Nacos 的关键特性包括：

• 服务发现和服务健康监测

  Nacos 支持基于 DNS 和基于 RPC 的服务发现。Nacos 为服务提供了原生SDK、OpenAPI；消费者可以使用DNS TODO 或 HTTP&API查找和发现服务。

• 动态配置服务

  Nacos 提供对服务的实时的健康检查，阻止向不健康的主机或服务实例发送请求。

  Nacos 支持传输层 (PING 或 TCP)和应用层 (如 HTTP、MySQL、用户自定义）的健康检查。

  Nacos 还提供了统一的健康检查仪表盘，可以根据健康状态管理服务的可用性及流量。

  动态配置服务可以让你以中心化、外部化和动态化的方式管理所有环境的应用配置和服务配置。

  动态配置消除了配置变更时重新部署应用和服务的需要，让配置管理变得更加高效和敏捷。

  配置中心化管理让实现无状态服务变得更简单，让服务按需弹性扩展变得更容易。

  Nacos 提供了一个简洁易用的UI 帮助管理所有的服务和应用的配置。

  Nacos 还提供包括配置版本跟踪、金丝雀发布、一键回滚配置以及客户端配置更新状态跟踪在内的一系列开箱即用的配置管理特性，帮助更安全地在生产环境中管理配置变更和降低配置变更带来的风险。

• 动态DNS服务

  动态 DNS 服务支持权重路由，让您更容易地实现中间层负载均衡、更灵活的路由策略、流量控制以及数据中心内网的简单DNS解析服务。动态DNS服务还能让您更容易地实现以 DNS 协议为基础的服务发现，以帮助您消除耦合到厂商私有服务发现 API 上的风险。

• 服务及其元数据管理

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

Nacos地图

基本概念

• 地域：物理的数据中心，资源创建成功后不能更换。
• 可用区：同一地域内，电力和网络互相独立的物理区域。同一可用区内，实例的网络延迟较低。
• 接入点：地域的某个服务的入口域名。

• 命名空间：用于进行租户粒度的配置隔离。不同的命名空间下，可以存在相同的 Group 或 Data ID 的配置。Namespace 的常用场景之一是不同环境的配置的区分隔离，例如开发测试环境和生产环境的资源（如配置、服务）隔离等。

• 权重：实例级别的配置。权重为浮点数。权重越大，分配给该实例的流量越大。

• 元信息：Nacos数据（如配置和服务）描述信息，如服务版本、权重、容灾策略、负载均衡策略、鉴权配置、各种自定义标签 (label)，从作用范围来看，分为服务级别的元信息、集群的元信息及实例的元信息。

服务

• 服务：通过预定义接口网络访问的提供给客户端的软件功能。
• 服务名：服务提供的标识，通过该标识可以唯一确定其指代的服务。
• 服务注册中心：存储服务实例和服务负载均衡策略的数据库。
• 服务发现：在计算机网络上，（通常使用服务名）对服务下的实例的地址和元数据进行探测，并以预先定义的接口提供给客户端进行查询。
• 应用：用于标识服务提供方的服务的属性。
• 服务分组：不同的服务可以归类到同一分组。
• 虚拟集群：同一个服务下的所有服务实例组成一个默认集群, 集群可以被进一步按需求划分，划分的单位可以是虚拟集群。
• 实例：提供一个或多个服务的具有可访问网络地址（IP:Port）的进程。

配置

• 配置：在系统开发过程中，开发者通常会将一些需要变更的参数、变量等从代码中分离出来独立管理，以独立的配置文件的形式存在。

  目的是让静态的系统工件或者交付物（如 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）的概念。

健康检测

• 健康检查：以指定方式检查服务下挂载的实例 (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)

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

• 名字服务 (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 数据模型 Key 由三元组唯一确定, Namespace 默认是空串，公共命名空间（public），分组默认是 DEFAULT_GROUP。

领域模型

配置领域模型

围绕配置，主要有两个关联的实体，一个是配置变更历史，一个是服务标签（用于打标分类，方便索引），由 ID 关联。

类视图

Nacos-SDK 类视图

两种交付工件

Nacos 支持标准 Docker 镜像(TODO: 0.2版本开始支持）及 zip(tar.gz)压缩包的构建物。

两种启动模式

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

相关参考

• 服务注册中心对比