简要介绍
Nacos 是由阿里巴巴开源的一个动态服务发现、配置和服务管理平台，专为微服务架构设计。它帮助开发者实现云原生应用的动态服务发现和配置管理，提供了轻量级的服务注册和发现机制以及动态的服务配置功能。
核心功能
- 服务发现与注册：
- Nacos 支持 DNS-based 和 RPC-based 服务发现，提供实时健康检查，确保服务的可用性。服务实例上线或下线时，Nacos 会自动处理服务列表，客户端通过订阅服务列表获取最新的服务实例信息。
- 动态配置管理：
- Nacos 提供中心化的配置管理服务，允许动态地管理应用配置，而无需重启服务。它支持配置自动更新，服务在运行时可以根据配置变化进行自适应调整。
- 服务元数据和流量管理：
- Nacos 支持存储服务的元数据，如权重、负载均衡策略等，这些元数据可以用于服务调度和流量管理。
- 支持多种配置格式：
- Nacos 支持多种配置格式，包括但不限于 properties、YAML、JSON等。
- 支持多种环境：
- Nacos 支持多环境、多租户的配置管理，助力于微服务的多环境隔离。
存储结构
服务注册信息主要存储在服务器的内存中，以便快速响应服务发现的请求。这部分是服务注册的核心存储机制。
对于配置管理，Nacos 提供了两种存储方式：
- 内存中：为了快速访问，配置数据也会被缓存于内存中。
- 持久化存储：在持久化模式下，Nacos 支持使用外部数据库来存储配置数据。
常见问题
1、Nacos 是怎么发现新进来的微服务实例的？
当一个微服务实例启动时，首先在 yml 文件中配置 Nacos 注册中心的地址，然后在启动类上添加服务发现 @EnableDiscoveryClient 注解。这样它会自动向 Nacos Server 注册当前服务实例。这个过程通常是通过调用 Nacos Server 的 API，将自己的服务名称、实例ID、IP地址、端口号等信息发送给 Nacos Server。注册成功之后，Nacos 并能感知到这个实例的存在。
2、Nacos 是如何发现一个服务不可用的？
Nacos Server 会定时发送心跳检查请求到每一个已注册的服务实例，以确认它们是否还存活。如果在一定时间内（默认是30秒）没有收到某个服务实例的心跳响应，Nacos 会认为这个服务实例已经不可用，并将其从服务列表中剔除。
3、当一个服务要调用另一个服务时，流程是哪样子的？
- 当服务 A 想要调用服务 B 时，服务 A 首先会向服务注册中心（Nacos）请求服务 B 的实例信息。
- 服务注册中心接收到响应，然后返回服务 B 所有可用实例列表给服务A。
- 服务 A 通过集成的客户端负载均衡器（如Ribbon），根据某种负载均衡策略（如轮询、随机、权重等）选择一个服务B的实例。
- 服务 A 通过选定的服务 B 实例的网络地址发起对服务 B 的调用。通常通过 HTTP 或其他 RPC 协议实现。
- 如果调用失败，服务A可以选择另一个服务B的实例进行重试。
- 被调用的服务 B 实例接收请求，处理业务逻辑，并返回响应给服务 A。
4、灰度发布和蓝绿部署是什么意思？
- 灰度发布：是指新版本的服务逐渐替代旧版本的过程，初期只有少部分用户使用新版本，如果新版本稳定，再逐渐扩大到所有用户。这样可以确保新版本的稳定性，并减少因新版本引入的问题对所有用户的影响。
- 蓝绿部署：是指同时部署两个版本的服务，蓝色代表旧版本，绿色代表新版本。所有的流量首先路由到蓝色版本，当绿色版本准备好并经过测试后，流量可以切换到绿色版本。这样可以快速回滚到蓝色版本，如果绿色版本有问题。
5、Nacos 和 Gateway 之间是怎么样的关系？
- Nacos 主要负责
服务的注册与发现以及配置管理。而Gateway 是API网关，负责处理外部请求并将其路由到相应的微服务。 - 当 Gateway 需要路由请求到某个服务时，它会向服务注册中心查询这个服务的实例列表，然后通过集成的负载均衡器，根据负载均衡策略选择一个实例进行调用。
6、Nacos 集群之间是怎么同步的？
Nacos 集群中的数据同步主要依靠 Raft 协议来保证一致性。这是一种分布式计算中用于实现多节点间一致性的协议，常用于多副本数据的一致性保障。
- 领导选举（Leader Election）：
- 当 Nacos 集群启动时，或者领导者节点失效时，集群会通过 Raft 协议进行新的领导者选举。
- 所有的写操作（比如更新配置信息或服务注册信息）都必须通过领导者来进行。
- 日志复制（Log Replication）：
- 当领导者节点接收到一个更新请求（比如配置更新或服务注册），它首先将这个请求作为一个新的日志条目添加到它的日志中。
- 然后，领导者将这个日志条目发送给其他的追随者节点。
- 追随者节点将该日志条目添加到它们各自的日志中，并向领导者确认接收成功。
- 数据提交：
- 一旦领导者节点从大多数追随者那里收到了确认，它就会提交该日志条目，并将更新应用到系统状态上。
- 领导者之后会通知追随者已经提交了哪些日志条目，追随者随后也会将这些条目提交并应用到各自的系统状态。
- 读取操作：
- 对于读操作，可以直接由任何一个节点处理，但为了保证读到的数据是最新的，通过读操作也会通过领导者节点来进行。
CAP
CAP 理论指出，一个分布式系统不可能同时满足以下三点：
- 一致性（Consistency）：每次读取都能得到最新的写入或错误响应。
- 可用性（Availability）：每次请求都能得到响应，无论成功或失败。
- 分区容错性（Partition tolerance）：系统中任何信息的丢失或失败都不会影响系统的继续运行。
Nacos 的 CAP 配置
Nacos 提供了两种运行模式，可以根据需要在一致性和可用性之间进行选择，确保系统按需求正确运行：
在CAP理论中，Nacos可以配置为更偏向于“一致性（C）”和“分区容错性（P）”，也可以配置为更偏向于“可用性（A）”和“分区容错性（P）”，这取决于具体的使用场景和配置。
不同的运行模式：
AP 模式：
当运行在 AP 模式下，Nacos 更偏向于高可用性和分区容错性。这在大多数服务发现场景是可取的，因为在这种情况下，即使在网络分区或部分系统故障的情况下，服务仍然需要被发现和消费。
在 AP 模式下，Nacos 可能会牺牲一致性来保证高可用性。也就是说，服务的注册和发现可能不会立即反映最新状态，但服务的发现和路由功能仍然是可用的。
作为服务注册中心：
- 当Nacos用作服务注册中心时，它通常运行在AP模式。这是因为在服务发现的场景中，可用性和分区容错性通常被视为更重要。即使在网络分区或部分服务不可用的情况下，服务注册和发现功能仍然可以正常工作，尽管这可能会导致短暂的数据不一致。
CP 模式：
当运行在 CP 模式下，Nacos 更注重一致性和分区容错性。这适用于配置管理场景，因为配置信息的正确性和一致性是非常重要的。
在 CP 模式下，Nacos 会确保配置的一致性，即使这可能意味着在网络分区或其他问题发生时，对配置的访问可能会受到影响。
作为配置中心：
- 当Nacos用作配置中心时，它通常运行在CP模式。在配置管理场景下，一致性是非常关键的，因为配置信息需要在所有服务实例之间保持一致。Nacos 确保即使在网络分区或故障的情况下，所有服务实例也能获取到一致的配置信息。
