当前位置：首页 > article >正文

Java重要面试名词整理（十七）：Nacos

article 2025/1/4 8:24:24

文章目录

- 架构演化
- - 技术选型
- 概念
- - - 相关核心概念
    - 核心功能
  - 设计
- 注册中心CP架构分析
- - BASE理论
- 配置中心

架构演化

我们认为架构发展历史经历了这样一个过程：单体架构——>垂直架构 ——> SOA 面向服务架构 ——> 微服务架构。

SOA（Service-Oriented Architecture），面向服务的架构。在SOA中，会采用ESB（企业服务总线）来作为系统和服务之间的通信桥梁，ESB本身还提供服务地址的管理、不同系统之间的协议转化和数据格式转化等。调用端不需要关心目标服务的位置，从而使得服务之间的交互是动态的，这样做的好处是实现了服务的调用者和服务的提供者之间的高度解耦。

微服务架构在某种程度上是面向服务的架构SOA继续发展的下一步，它更加强调服务的"彻底拆分"。面向服务（SOA）和微服务本质上都是服务化思想的一种体现。如果SOA是面向服务开发思想的雏形，那么微服务就是针对可重用业务服务的更进一步优化，我们可以把SOA看成微服务的超集，也就是多个微服务可以组成一个SOA服务

微服务架构就是将每个具体的业务服务构成可独立运行的微服务，每个微服务只关注某个特定的功能，服务之间采用轻量级通信机制REST API进行通信。

技术选型

业内比较主流的微服务解决方案进行分析，主要包括：

Spring Cloud Netflix
Spring Cloud Alibaba

什么是Spring Cloud全家桶

Spring Cloud提供了一些可以让开发者快速构建微服务应用的工具，比如配置管理、服务发现、熔断、智能路由等，这些服务可以在任何分布式环境下很好地工作。Spring Cloud主要致力于解决如下问题：

Distributed configuration，分布式配置
Service registration and discovery，服务注册与发现
Routing，服务路由
Service-to-service calls，服务调用
Load balancing，负载均衡
Circuit Breakers，断路器
Distributed messaging，分布式消息

概念

服务注册中心的作用就是服务注册与发现

服务注册，就是将提供某个服务的模块信息(通常是这个服务的ip和端口)注册到1个公共的组件上去。
服务发现，就是新注册的这个服务模块能够及时的被其他调用者发现。不管是服务新增和服务删减都能实现自动发现。

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

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

核心功能

服务注册：Nacos Client会通过发送REST请求的方式向Nacos Server注册自己的服务，提供自身的元数据，比如ip地址、端口等信息。Nacos Server接收到注册请求后，就会把这些元数据信息存储在一个双层的内存Map中。

服务心跳：在服务注册后，Nacos Client会维护一个定时心跳来持续通知Nacos Server，说明服务一直处于可用状态，防止被剔除。默认5s发送一次心跳。

服务同步：Nacos Server集群之间会互相同步服务实例，用来保证服务信息的一致性。

服务发现：服务消费者（Nacos Client）在调用服务提供者的服务时，会发送一个REST请求给Nacos Server，获取上面注册的服务清单，并且缓存在Nacos Client本地，同时会在Nacos Client本地开启一个定时任务定时拉取服务端最新的注册表信息更新到本地缓存

服务健康检查：Nacos Server会开启一个定时任务用来检查注册服务实例的健康情况，对于超过15s没有收到客户端心跳的实例会将它的healthy属性置为false(客户端服务发现时不会发现)，如果某个实例超过30秒没有收到心跳，直接剔除该实例(被剔除的实例如果恢复发送心跳则会重新注册)

设计

Namespace 隔离设计

命名空间(Namespace)用于进行租户（用户）粒度的隔离，Namespace 的常用场景之一是不同环境的隔离，例如开发测试环境和生产环境的资源（如配置、服务）隔离等。

group服务分组

不同的服务可以归类到同一分组，group也可以起到服务隔离的作用。yml中可以通过spring.cloud.nacos.discovery.group参数配置。group更多应用场景是配置分组。

注册中心CP架构分析

我们使用nacos的时候，有一个关于节点类型的配置：

cloud:
    nacos:
      discovery:
        server-addr: 192.168.131.172:8848
        ephemeral: true

ephemeral：true：临时节点，写在内存中，效率较高，这种是AP架构；
ephemeral：false：持久化节点，会写在文件中（不会写到mysql中，mysql是为了存储配置信息的，和注册没关系），同时在内存中同步一份，这种是CP架构。
不同的模块，可以使用不同的架构，Nacos支持混合架构。

作为注册中心，我们一般都会使用AP架构，一般都要求性能更高一点。

BASE理论

BA（Basically Available）：基本可用；
S（Soft State）：软状态；
E（Eventual Consistency）：最终一致性。
BASE原则是CAP的折中，C、A、P三个都要，但不用100%的保证每一个原则。分布式系统肯定优先保证P，多数时候在C和A之间做权衡选择。

满足AP的系统在一定程度上也可以说是复合BASE原则的，比如Eureka集群。三个节点挂了两个，系统还是基本能用的（BA）。此时如果有系统来注册了，因为挂了两个节点，这是整个系统的各节点间的数据是不一致的，但是等另外两个节点恢复了，数据会同步过去（E），对于中间暂时的数据不一致状态可以成为软状态（S）。

Distro：AP架构实现协议;
Raft：CP架构实现协议，与Zookeeper的ZAB协议类似。

Raft和ZAB都是分布式一致性协议Paxos的简化，两者很类似，主要包括两部分：

1、leader选举（半数以上节点投票同意）
2、集群写入数据同步（两阶段提交，半数以上节点写入成功）

集群：同一个业务，部署在多个服务器上

分布式：

分布式部署：一个业务拆分成多个子业务，每个子业务分别部署在不同的服务器上；
分布式存储：存储在一台机器上的数据被拆分成多分存储在不同的机器上（Kafka分区、RecketMQ）;

微服务：就是一种分布式部署架构。

配置中心

配置中心就是一种统一管理各种应用配置的基础服务组件。配置中心的出现，可以解决这些问题，使得配置信息集中管理，易于维护，并且可以动态更新配置，使得分布式系统更加稳定可靠。

Nacos 提供用于存储配置和其他元数据的 key/value 存储，为分布式系统中的外部化配置提供服务器端和客户端支持。使用 Spring Cloud Alibaba Nacos Config，您可以在 Nacos Server 集中管理你 Spring Cloud 应用的外部属性配置。

DateID

Nacos 中的某个配置集的 ID。配置集 ID 是组织划分配置的维度之一。Data ID 通常用于组织划分系统的配置集。一个系统或者应用可以包含多个配置集，每个配置集都可以被一个有意义的名称标识。

Group

Nacos 中的一组配置集，是组织配置的维度之一。通过一个有意义的字符串（如 Buy 或 Trade ）对配置集进行分组，从而区分 Data ID 相同的配置集。当您在 Nacos 上创建一个配置时，如果未填写配置分组的名称，则配置分组的名称默认采用 DEFAULT_GROUP 。配置分组的常见场景：不同的应用或组件使用了相同的配置类型，如 database_url 配置和 MQ_topic 配置。

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

支持profile粒度的配置

spring-cloud-starter-alibaba-nacos-config 在加载配置的时候，不仅仅加载了以 dataid 为 ${spring.application.name}.${file-extension:properties} 为前缀的基础配置，还加载了dataid为 ${spring.application.name}-${profile}.${file-extension:properties} 的基础配置。在日常开发中如果遇到多套环境下的不同配置，可以通过Spring 提供的 ${spring.profiles.active} 这个配置项来配置。

spring.profiles.active=dev

支持自定义 namespace 的配置

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

在没有明确指定 ${spring.cloud.nacos.config.namespace} 配置的情况下，默认使用的是 Nacos 上 Public 这个namespace。如果需要使用自定义的命名空间，可以通过以下配置来实现：

spring.cloud.nacos.config.namespace=71bb9785-231f-4eca-b4dc-6be446e12ff8

支持自定义 Group 的配置

Group是组织配置的维度之一。通过一个有意义的字符串（如 Buy 或 Trade ）对配置集进行分组，从而区分 Data ID 相同的配置集。当您在 Nacos 上创建一个配置时，如果未填写配置分组的名称，则配置分组的名称默认采用 DEFAULT_GROUP 。配置分组的常见场景：不同的应用或组件使用了相同的配置类型，如 database_url 配置和 MQ_topic 配置。

在没有明确指定 ${spring.cloud.nacos.config.group} 配置的情况下，默认是DEFAULT_GROUP 。如果需要自定义自己的 Group，可以通过以下配置来实现：

spring.cloud.nacos.config.group=DEVELOP_GROUP

支持自定义扩展的 Data Id 配置

Data ID 是组织划分配置的维度之一。Data ID 通常用于组织划分系统的配置集。一个系统或者应用可以包含多个配置集，每个配置集都可以被一个有意义的名称标识。Data ID 通常采用类 Java 包（如 com.taobao.tc.refund.log.level）的命名规则保证全局唯一性。此命名规则非强制。

在实际的业务场景中应用和共享配置间的关系可能如下：

从单个应用的角度来看：应用可能会有多套(develop/beta/product)发布环境，多套发布环境之间有不同的基础配置，例如数据库。
从多个应用的角度来看：多个应用间可能会有一些共享通用的配置，比如多个应用之间共用一套zookeeper集群。

通过自定义扩展的 Data Id 配置，既可以解决多个应用间配置共享的问题，又可以支持一个应用有多个配置文件。

通过 spring.cloud.nacos.config.shared-configs[n].data-id 来支持多个共享 Data Id 的配置，多个之间用逗号隔开。多个共享配置间的一个优先级的关系我们约定：按照配置出现的先后顺序，即后面的优先级要高于前面。如果没有明确配置，默认情况下所有共享配置的 Data Id 都不支持动态刷新。
通过spring.cloud.nacos.config.extension-configs[n].data-id 的配置方式来支持多个 Data Id 的配置。多个 Data Id 同时配置时，他的优先级关系是 n 的值越大，优先级越高。
通过spring.cloud.nacos.config.extension-configs[n].group 的配置方式自定义 Data Id 所在的组，不明确配置的话，默认是 DEFAULT_GROUP。
通过spring.cloud.nacos.config.extension-configs[n].refresh 的配置方式来控制该 Data Id 在配置变更时，是否支持应用中可动态刷新，感知到最新的配置值。默认是不支持的。

配置的优先级

Spring Cloud Alibaba Nacos Config 目前提供了三种配置能力从 Nacos 拉取相关的配置。

A: 通过 spring.cloud.nacos.config.shared-configs 支持多个共享 Data Id 的配置
B: 通过 spring.cloud.nacos.config.extension-configs[n].data-id 的方式支持多个扩展 Data Id 的配置
C: 通过内部相关规则(应用名、应用名+ Profile )自动生成相关的 Data Id 配置

当三种方式共同使用时，他们的一个优先级关系是:A < B < C

通过 Nacos Config 对外暴露的 Endpoint查看相关的配置

Nacos Config 内部提供了一个 Endpoint, 对应的 endpoint id 为 nacosconfig。

Endpoint 暴露的 json 中包含了三种属性: