Nacos相关面试题(上)

91 阅读5分钟

每天记录一下面试八股文,纯属个人记录,答案来源于网站和ChatGPT生成

Nacos 的领域模型主要是按照下述进行划分:

服务领域模型: 采用分层结构,从上到下依次为:
Namespace(命名空间) :用于资源隔离,比如区分不同环境或租户,默认值为 “public”。
Group(分组) :在同一命名空间下,用于逻辑上组织服务,默认值通常为 “DEFAULT_GROUP”。
Service(服务) :具体的业务服务,例如“用户服务”或“订单服务”,是注册中心中最基本的抽象单位。
Cluster(集群) :在一个服务下,可以根据部署环境、健康检查策略等要求将实例划分为不同的集群。
Instance(实例) :代表具体的服务提供者节点,包含 IP、端口、健康状态、权重等信息。

Nacos 加载配置优先级

在 Spring Cloud Alibaba Nacos 配置中心中,配置的加载和覆盖遵循一套“后加载覆盖先加载”的原则,通常优先级(从低到高)如下:

  1. 本地配置文件
    • 首先加载应用的本地配置文件(如 application.properties 或 application.yml),其中无 profile 的配置加载优先级较低,而 profile 特定的(如 application‑dev.yml)会覆盖无 profile 配置。
  2. Nacos 配置中心中共享配置(shared-configs)
    • 这部分配置通常用来存放多个微服务通用的公共配置,其优先级较低。
  3. Nacos 配置中心中扩展配置(extension-configs)
    • 用于为单个应用提供额外配置,覆盖共享配置。
  4. Nacos 内部规则生成的配置
    • Nacos 会根据应用名称和激活的 profile 自动生成对应的 dataId(如 user-service‑dev.yml),这部分配置具有最高优先级,会覆盖前面加载的所有配置。

总结就是: 因为先加载会被后加载的覆盖,所以越晚加载,优先级越高,远程的nacos配置会覆盖本地相同的配置。 properties(文件优先级高,加载顺序晚) > yml > yaml 因为yml会在yaml之后加载,所以yml的配置会覆盖yaml的重名key的值。 排序如图 最开始加载 ---> 最后加载

  • bootstrap.yaml
  • bootstrap.yml
  • bootstrap.properties
  • bootstrap-dev.yaml
  • bootstrap-dev.yml
  • bootstrap-dev.properties
  • application.yaml
  • application.yml
  • application.properties
  • nacos的共享配置
  • nacos的服务配置

Nacos的探活机制

在 Nacos 1.0 版本中,客户端的探活(健康检查)机制主要依赖于定时的 HTTP 心跳请求:
心跳机制:每个注册的实例会按照预定间隔(例如每 5 秒)向 Nacos 服务端发送一次 HTTP 心跳请求;
超时与摘除:如果在一定的超时时间内(如 30 秒)未收到心跳,服务端会将该实例标记为不健康并最终摘除。

而在 Nacos 2.0 版本中,客户端探活机制发生了较大变化,主要体现在以下几点:
长连接(gRPC)机制:客户端与服务端之间采用 gRPC 长连接而非单次 HTTP 请求,这种方式可以持续保持连接,降低网络开销;
实时性提升:长连接使得服务端能够更快感知到客户端的异常断连或网络波动,从而更及时地更新实例的健康状态;
架构优化:2.0 版本在实例元数据管理上进行了改进,使得探活逻辑与实例注册分离,既支持临时实例也支持持久化实例的管理,整体稳定性和扩展性更高。

总的来说,Nacos 2.0 通过引入 gRPC 长连接探活机制,相较于 1.0 版本的定时 HTTP 心跳,不仅提高了实时性和可靠性,也更适合大规模分布式环境下的使用。

Nacos的动态更新机制

image.png

Nacos的临时实例与持久化实例

在 Nacos 中,服务实例分为临时实例永久实例,两者在注册方式、生命周期管理以及使用场景上存在明显差异:
1. 临时实例
动态注册:临时实例通常由服务启动时自动注册到 Nacos。当服务实例上线后,会将自己的相关信息(如 IP、端口、元数据等)注册到 Nacos。
心跳机制:这些实例依赖于客户端定期发送的心跳信号。如果在预定时间内未收到心跳,Nacos 会认为该实例不可用,并自动将其从注册中心中移除。
适用场景:适合动态上下线的场景,比如微服务在自动扩缩容过程中,实例的频繁变动能够通过心跳机制及时反映到注册中心中,保证服务发现信息的实时性。

2. 永久实例
手动或特殊注册:永久实例通常由运维人员或特殊流程注册,不依赖自动心跳。注册后,其信息会被持久化存储在 Nacos 的数据库中。
长久保留:即便服务实例本身出现异常或下线,永久实例的信息仍会保留在 Nacos 中,直到明确进行注销或删除。这种设计适合那些需要长期固定标识的服务节点。
适用场景:常用于需要稳定注册、手动管理或特定业务需求(例如第三方服务、静态资源服务)的场景,不希望因短暂的网络波动或临时故障导致服务信息丢失。

总结
临时实例:更适合动态、实时变动的服务场景,利用心跳机制自动维护服务健康状态。
永久实例:适用于稳定、长期的服务注册管理,避免因为心跳丢失而自动移除服务信息。

Nacos的保护阈值与权重

todo