一：为什么要有nacos，它帮助我们解决什么问题？

在微服务架构中，各个微服务独立开发、部署和运行，服务之间通过网络进行通信。这就需要一个机制来管理服务的注册与发现，让服务消费者能够找到服务提供者的地址。同时，配置管理也是一个关键问题，不同环境（开发、测试、生产）下的配置可能不同，而且在运行时也可能需要动态调整配置。Nacos 正好在这些方面发挥了重要作用。

它用来代替Eureka/Consul做服务注册中心，替代（config+Bus）/Consul做服务配置中心和满足动态刷新广播通知（热更新）

在控制器类加入@RefreshScope注解是当前类下的配置支持nacos的动态刷新

他还存在历史版本，能够让我们进行回滚

nacos默认是AP模式，但也可以切换为CP，我们一般用AP

二：nacos是怎们帮助我们解决问题的，它的工作原理？

1.首先我们了解他的数据模型

1.1 服务（Service）

在 Nacos 中，服务是指一个可以被其他组件调用的具有特定功能的逻辑单元 ，是 Nacos 世界的一等公民。在微服务架构里，一个大型应用会被拆分成多个微小服务，每个服务都专注于完成一项具体任务，服务之间通过网络进行通信协作。比如在一个电商系统中，用户服务负责管理用户信息，包括用户注册、登录、信息修改等操作；商品服务负责管理商品信息，如商品的添加、查询、库存管理等。这些不同的功能模块都可以看作是一个个独立的服务。

服务在微服务架构中的作用举足轻重。它实现了业务功能的模块化和独立化，使得每个服务可以独立开发、测试、部署和扩展，降低了系统的耦合度，提高了开发效率和系统的可维护性。当业务需求发生变化时，只需要对相应的服务进行修改和调整，而不会影响到其他服务，极大地增强了系统的灵活性和可扩展性。

1.2 实例（Instance）

实例是服务的具体运行实体，每个服务可以有多个实例。继续以电商系统的用户服务为例，为了应对高并发的用户请求，可能会部署多个用户服务实例，这些实例分布在不同的服务器上，每个实例都有自己的 IP 地址和端口号 。这些实例共同提供用户服务的功能，通过负载均衡机制，将用户请求分发到不同的实例上进行处理，从而提高系统的并发处理能力和可用性。

实例与服务的关系紧密相连。实例是服务的具体执行者，服务通过多个实例来实现高可用和负载均衡。当一个服务的某个实例出现故障时，负载均衡器可以将请求转发到其他正常的实例上，保证服务的正常运行。同时，通过增加或减少实例的数量，可以灵活地调整服务的处理能力，以适应不同的业务负载。

1.3 配置（Configuration）

配置是指应用程序在运行时所依赖的各种参数和设置，如数据库连接信息、日志级别、系统参数等。Nacos 的配置管理功能允许将这些配置集中存储和管理，应用程序在启动时可以从 Nacos 获取配置信息，并在运行时动态更新配置，而无需重启应用。

以数据库连接配置为例，在传统的应用部署中，数据库连接配置通常写在应用的配置文件中。当数据库的地址、用户名或密码发生变化时，需要修改配置文件并重启应用才能生效。而使用 Nacos 配置管理后，可以将数据库连接配置存储在 Nacos 中。应用启动时，从 Nacos 读取配置信息来建立数据库连接。当数据库配置发生变化时，只需在 Nacos 中修改配置，Nacos 会将新的配置推送给应用，应用可以实时感知并更新配置，实现了配置的动态管理，大大提高了系统的运维效率和灵活性。

1.4 命名空间（Namespace）

命名空间是 Nacos 用于隔离不同环境下的配置和服务的逻辑概念 。在实际的开发和部署中，通常会有开发、测试、生产等多个环境，不同环境下的服务和配置可能存在差异。通过命名空间，可以将不同环境的服务和配置进行隔离，避免相互干扰。

例如，在开发环境中，我们可以创建一个名为 “dev” 的命名空间，将开发环境的所有服务和配置都放在这个命名空间下。在测试环境中，创建 “test” 命名空间，生产环境则创建 “prod” 命名空间。这样，不同环境的服务和配置就可以通过命名空间进行区分和管理，当需要对某个环境的服务或配置进行修改时，不会影响到其他环境，提高了系统的稳定性和安全性。

1.5 分组（Group）

分组是对配置和服务进行进一步细分的概念，用于将相关的配置或服务组织在一起，方便管理。在一个大型项目中，可能有多个业务模块，每个业务模块都有自己的配置和服务。通过分组，可以将同一业务模块的配置和服务划分到同一个组中。

比如，在一个电商系统中，用户模块的所有配置可以划分到 “user - group” 组，商品模块的配置划分到 “product - group” 组。这样，在管理配置和服务时，可以按照分组进行分类管理，提高管理的效率和便捷性。同时，分组也可以用于实现不同业务模块之间的权限控制和访问隔离，增强系统的安全性和可维护性。

2.主要功能（工作原理）

3.1 服务发现与健康检测

Nacos 的服务发现功能允许服务提供者将自己的服务信息注册到 Nacos 服务器，服务消费者则可以从 Nacos 服务器获取服务提供者的地址列表，从而实现服务之间的通信。这一过程极大地简化了微服务架构中服务之间的调用关系，避免了硬编码服务地址带来的不便和维护成本。

以一个简单的电商系统为例，订单服务作为服务消费者，需要调用商品服务（服务提供者）来获取商品信息以完成订单创建。当商品服务启动时，它会向 Nacos 服务器发送注册请求，请求中包含商品服务的名称、IP 地址、端口号等元数据。Nacos 服务器接收到注册请求后，会将这些信息存储在其内部维护的服务列表中，并根据需要更新相关缓存。此时，订单服务在运行过程中，通过 Nacos 提供的 API 向 Nacos 服务器发送查询请求，请求中指定要获取的商品服务名称 。Nacos 服务器根据请求，从服务列表中查找对应的商品服务实例信息，并将这些信息返回给订单服务。订单服务得到商品服务的实例列表后，根据内置的负载均衡策略（如轮询、随机、权重等），从实例列表中挑选一个实例的地址，进而向该地址发起调用，获取商品信息。

为了确保服务的可用性，Nacos 还提供了健康检测功能，通过该功能，Nacos 可以实时监控服务实例的运行状态，防止向不健康的实例发送请求，从而保证整个系统的稳定性和可靠性。Nacos 支持多种健康检查方式，包括传输层的 PING 或 TCP 检查，以及应用层的 HTTP、MySQL、用户自定义检查等。

对于应用层的 HTTP 健康检查，假设商品服务提供了一个用于健康检查的 HTTP 接口，如 “/health”。Nacos 服务器会定期向商品服务的这个接口发送 HTTP 请求。如果商品服务正常运行，它会返回一个表示健康状态的响应，例如 HTTP 状态码 200。Nacos 服务器接收到正常响应后，会认为该商品服务实例处于健康状态。相反，如果 Nacos 服务器在多次尝试后仍无法收到正常响应，或者收到的 HTTP 状态码表示服务异常（如 500 内部服务器错误），Nacos 服务器会将该商品服务实例标记为不健康。当订单服务向 Nacos 服务器获取商品服务实例列表时，Nacos 服务器只会返回健康状态的实例，从而保证订单服务调用的可靠性。

在复杂的云环境和网络拓扑环境中，如 VPC（虚拟私有云）、边缘网络等，Nacos 提供了 agent 上报模式和服务端主动检测两种健康检查模式。agent 上报模式下，每个服务实例上会运行一个 agent，agent 负责定期检测所在实例的健康状态，并主动将状态信息上报给 Nacos 服务器。这种模式适用于网络环境复杂，服务端难以直接访问服务实例的情况。而服务端主动检测模式则是 Nacos 服务器主动向服务实例发起健康检查请求，直接获取服务实例的健康状态。

3.2 动态配置管理

Nacos 的动态配置管理功能允许将应用程序的配置信息集中存储在 Nacos 服务器上，实现配置的中心化、外部化和动态化管理。应用程序在启动时可以从 Nacos 获取配置信息，并在运行时动态更新配置，无需重启应用，这大大提高了系统的灵活性和运维效率。

以一个分布式应用的数据库连接配置为例，在传统的配置管理方式下，数据库连接信息通常写在应用的配置文件中。当数据库的地址、用户名、密码等配置发生变化时，需要手动修改配置文件，并重启应用才能使新的配置生效。这在生产环境中，尤其是对高可用性要求较高的系统来说，是非常不便的，可能会导致服务中断，影响用户体验。

使用 Nacos 的动态配置管理后，数据库连接配置被存储在 Nacos 服务器上 。应用启动时，通过 Nacos 客户端从 Nacos 服务器读取数据库连接配置信息，从而建立数据库连接 。当数据库配置发生变化时，只需在 Nacos 控制台或通过 API 在 Nacos 服务器上修改相应的配置 。Nacos 服务器会记录下配置的变更，并通过长轮询机制通知所有订阅了该配置的应用客户端。

具体来说，当应用客户端启动时，会向 Nacos 服务器发起一个长轮询请求，建立一个持久的 HTTP 连接。在没有配置更新时，Nacos 服务器会将这个请求挂起，不立即响应 。一旦数据库连接配置发生变更，Nacos 服务器会立刻唤醒挂起的请求，并将最新的配置信息发送给应用客户端。应用客户端收到通知后，会从 Nacos 服务器拉取最新的配置，并应用到应用中，实现配置的动态更新。同时，为了提高响应速度和减少网络请求，应用客户端会在本地缓存配置信息。当收到配置更新通知时，客户端不仅会更新其本地缓存，还会进行必要的同步和验证，以确保缓存的一致性。

Nacos 还提供了一系列开箱即用的配置管理特性，如配置版本跟踪、金丝雀发布、一键回滚配置以及客户端配置更新状态跟踪等。配置版本跟踪功能可以记录每次配置的变更历史，方便查看配置的修改记录和进行问题排查。金丝雀发布允许将新的配置先发布给一小部分用户或服务实例，进行灰度测试，确保新配置的稳定性后再逐步推广到全部用户或实例。一键回滚配置功能则在新配置出现问题时，可以快速将配置回滚到上一个稳定版本，降低配置变更带来的风险。客户端配置更新状态跟踪可以让管理员实时了解各个应用客户端是否成功更新了配置，便于及时发现和解决配置更新过程中出现的问题。

3.3 动态服务路由

动态服务路由是指 Nacos 能够根据不同的业务场景和条件，动态调整服务调用的路由策略，将请求转发到最合适的服务实例上 。这种功能使得服务调用更加灵活和智能，能够满足复杂多变的业务需求。

以一个面向全国用户的电商平台为例，平台的商品服务在不同地区部署了多个服务节点，以提高服务的响应速度和用户体验。当用户发起商品查询请求时，Nacos 可以根据用户的地域信息动态选择服务节点。如果用户位于华东地区，Nacos 会将请求路由到位于华东地区的商品服务节点，因为该节点距离用户更近，网络延迟更低，能够更快地响应用户请求。而如果华东地区的服务节点出现故障或负载过高，Nacos 可以自动将请求路由到其他地区（如华南、华北）的健康且负载较低的服务节点上，确保服务的可用性和稳定性。

实现这一功能，Nacos 首先需要获取用户的地域信息。这可以通过用户的 IP 地址解析来实现，Nacos 可以集成 IP 地址库，根据用户请求的源 IP 地址解析出用户所在的地域。然后，Nacos 根据预先配置的路由规则和服务节点的健康状态、负载情况等信息，动态计算出最优的服务节点。在实际路由过程中，Nacos 可以通过修改请求的目标地址或使用负载均衡器的动态配置功能，将请求转发到选定的服务节点上。

除了根据地域信息进行路由，Nacos 还可以根据其他业务场景和条件进行动态服务路由。例如，根据用户的会员等级进行路由，为高级会员提供更优质的服务节点；根据请求的时间进行路由，在业务高峰期将请求路由到性能更强的服务节点上；根据服务的版本号进行路由，实现不同版本服务的灰度发布和版本管理等。通过这些灵活的路由策略，Nacos 能够更好地优化服务调用，提高系统的整体性能和用户满意度。

3.4 多环境支持

在软件开发和部署过程中，通常会涉及多个环境，如开发环境、测试环境、生产环境等。不同环境下的应用配置和服务可能存在差异，例如数据库连接信息、日志级别、接口访问权限等。Nacos 的多环境支持功能可以很好地解决这一问题，它通过命名空间和分组的概念，实现不同环境下配置和服务的隔离与管理。

命名空间是 Nacos 用于隔离不同环境的逻辑单元，每个命名空间都有一个唯一的 ID。通过创建不同的命名空间，可以将不同环境的配置和服务分开管理 。例如，创建一个名为 “dev” 的命名空间用于开发环境，一个 “test” 命名空间用于测试环境，以及 “prod” 命名空间用于生产环境。在每个命名空间下，可以独立地进行配置管理和服务注册与发现。

分组则是在命名空间内对配置和服务进行进一步的细分，将相关的配置或服务组织在一起，方便管理。以不同环境的数据库配置为例，在开发环境的 “dev” 命名空间下，可以创建一个 “db - config - group” 分组，将开发环境的数据库连接配置（如数据库地址为 “dev - db.example.com”，用户名 “dev_user”，密码 “dev_password”）放在这个分组中。在测试环境的 “test” 命名空间下，同样创建 “db - config - group” 分组，但其中的数据库配置信息为测试环境的数据库地址（如 “test - db.example.com”）、用户名和密码 。生产环境的 “prod” 命名空间下的 “db - config - group” 分组则存放生产环境的数据库配置。

当应用程序启动时，可以通过配置指定要使用的命名空间和分组。例如，在开发环境的应用配置文件中设置命名空间为 “dev”，分组为 “db - config - group”，应用在启动时就会从 “dev” 命名空间的 “db - config - group” 分组中获取数据库配置信息 。这样，不同环境的应用就可以根据各自的配置获取到相应环境的数据库连接信息，实现了环境的隔离和配置的独立管理。

通过这种方式，不仅可以避免不同环境之间配置和服务的相互干扰，提高系统的稳定性和安全性，还便于在不同环境下进行开发、测试和部署工作，提高开发效率和运维管理的便捷性。同时，Nacos 还支持对命名空间和分组进行权限控制，进一步增强了多环境配置管理的安全性和灵活性。

服务注册：

Nacos Client会通过发送REST请求的方式向Nacos Server注册自己的服务，提供自身的元数据，比如ip地址、端口等信息。

Nacos Server接收到注册请求后，就会把这些元数据信息存储在一个双层的内存Map中，即Map<namespace, Map<group::serviceName, Service>>

服务发现：

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

Nacos Client服务心跳：

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

Nacos Server服务健康检查：

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

服务同步：

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

三：nacos总结

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

Nacos 作为一款功能强大的动态服务发现、配置管理和服务管理平台，在微服务架构中扮演着至关重要的角色。通过本文的全面介绍，我们深入了解了 Nacos 的核心概念，包括服务、实例、配置、命名空间和分组等，这些概念构成了 Nacos 强大功能的基石。

Nacos 的主要功能，如服务发现与健康检测、动态配置管理、动态服务路由和多环境支持，为微服务架构提供了全面的解决方案 。在服务发现与健康检测方面，Nacos 实现了服务的自动注册与发现，保障了服务的高可用性；动态配置管理使得配置的集中化、动态化管理成为现实，提高了系统的灵活性和运维效率；动态服务路由根据业务场景和条件智能调整路由策略，优化了服务调用；多环境支持通过命名空间和分组实现了不同环境下配置和服务的隔离与管理。

从应用场景来看，Nacos 在电商系统、分布式系统等领域都有着广泛的应用。在电商系统中，它确保了各个微服务之间的稳定通信和灵活配置，提升了系统的整体性能和用户体验；在分布式系统中，作为配置中心和服务注册与发现工具，Nacos 为系统的可靠性和可扩展性提供了有力支持。