每天记录一下面试八股文，纯属个人记录，答案来源于网站和ChatGPT生成
Nacos 的领域模型主要是按照下述进行划分：
服务领域模型： 采用分层结构，从上到下依次为：
• Namespace（命名空间） ：用于资源隔离，比如区分不同环境或租户，默认值为 “public”。
• Group（分组） ：在同一命名空间下，用于逻辑上组织服务，默认值通常为 “DEFAULT_GROUP”。
• Service（服务） ：具体的业务服务，例如“用户服务”或“订单服务”，是注册中心中最基本的抽象单位。
• Cluster（集群） ：在一个服务下，可以根据部署环境、健康检查策略等要求将实例划分为不同的集群。
• Instance（实例） ：代表具体的服务提供者节点，包含 IP、端口、健康状态、权重等信息。
Nacos 加载配置优先级
在 Spring Cloud Alibaba Nacos 配置中心中，配置的加载和覆盖遵循一套“后加载覆盖先加载”的原则，通常优先级（从低到高）如下：
- 本地配置文件
• 首先加载应用的本地配置文件（如 application.properties 或 application.yml），其中无 profile 的配置加载优先级较低，而 profile 特定的（如 application‑dev.yml）会覆盖无 profile 配置。 - Nacos 配置中心中共享配置（shared-configs）
• 这部分配置通常用来存放多个微服务通用的公共配置，其优先级较低。 - Nacos 配置中心中扩展配置（extension-configs）
• 用于为单个应用提供额外配置，覆盖共享配置。 - 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的动态更新机制
Nacos的临时实例与持久化实例
在 Nacos 中，服务实例分为临时实例和永久实例，两者在注册方式、生命周期管理以及使用场景上存在明显差异：
1. 临时实例
• 动态注册：临时实例通常由服务启动时自动注册到 Nacos。当服务实例上线后，会将自己的相关信息（如 IP、端口、元数据等）注册到 Nacos。
• 心跳机制：这些实例依赖于客户端定期发送的心跳信号。如果在预定时间内未收到心跳，Nacos 会认为该实例不可用，并自动将其从注册中心中移除。
• 适用场景：适合动态上下线的场景，比如微服务在自动扩缩容过程中，实例的频繁变动能够通过心跳机制及时反映到注册中心中，保证服务发现信息的实时性。
2. 永久实例
• 手动或特殊注册：永久实例通常由运维人员或特殊流程注册，不依赖自动心跳。注册后，其信息会被持久化存储在 Nacos 的数据库中。
• 长久保留：即便服务实例本身出现异常或下线，永久实例的信息仍会保留在 Nacos 中，直到明确进行注销或删除。这种设计适合那些需要长期固定标识的服务节点。
• 适用场景：常用于需要稳定注册、手动管理或特定业务需求（例如第三方服务、静态资源服务）的场景，不希望因短暂的网络波动或临时故障导致服务信息丢失。
总结
• 临时实例：更适合动态、实时变动的服务场景，利用心跳机制自动维护服务健康状态。
• 永久实例：适用于稳定、长期的服务注册管理，避免因为心跳丢失而自动移除服务信息。
Nacos的保护阈值与权重
todo
