Nacos注册中心：从服务注册到负载均衡

一、引言

微服务规模扩大后，服务动态上下线难感知、流量集中易过载成痛点，注册中心成关键枢纽。Alibaba 开源的 Nacos，凭 “服务发现 + 配置管理” 一体化能力、高可用设计快速出圈。本文将拆解 Nacos 服务注册的底层逻辑，剖析它与负载均衡组件的协同路径，看其如何打通 “注册 - 分发” 链路，支撑微服务稳定运行。

二、Nacos 核心概念

2.1 服务名（Service Name）

在 Nacos 的世界里，服务名是服务在注册中心的逻辑标识，就像是我们每个人的名字，用于唯一区分不同的服务。在一个电商系统中，订单服务可以命名为 “order-service”，商品服务可以命名为 “product-service”。所有提供相同功能的服务实例，都以同一个服务名进行注册。这样，当消费者需要调用某个服务时，只需要知道服务名，而无需关心具体的 IP 地址和端口号，大大提高了服务调用的灵活性和可维护性。

2.2 实例 

实例是服务的物理运行单元，它包含了服务运行所需的关键信息，如 IP 地址、端口、权重等元数据。可以把实例想象成一个个具体的服务器节点，一个服务名可以对应多个实例，从而实现服务的水平扩展。继续以电商系统的订单服务为例，为了应对高并发的订单请求，我们可以将 “order-service” 部署在多台服务器上，每台服务器上运行的订单服务就是一个实例。这些实例共同提供订单服务，通过负载均衡算法，将请求分发到不同的实例上，提高系统的整体性能和可用性。同时，Nacos 会实时监控每个实例的状态，确保消费者调用的都是健康的实例。

2.3 权重 

权重是 Nacos 中一个非常重要的概念，它用于控制实例接收请求的比例。权重的取值范围是 0 - 100，默认值为 100。我们可以根据服务器的配置、性能等因素，为不同的实例设置不同的权重。配置较高、性能较好的服务器，可以设置较高的权重，如 80；而配置较低、性能相对较弱的服务器，可以设置较低的权重，如 20。这样，当请求到来时，Nacos 会根据实例的权重，按比例将请求分发到不同的实例上，从而实现更合理的流量分配，优化资源利用。而且，在 Nacos 控制台中，我们可以非常直观地调整实例的权重，并且修改会实时生效，无需重启服务，非常方便。

2.4 健康检查

健康检查是 Nacos 保证服务可用性的重要机制。Nacos 通过主动检查（如发送 HTTP 请求到实例的健康检查 URL）或被动心跳（客户端定期向 Nacos 上报心跳）的方式，来验证实例的健康状态。默认情况下，Nacos 每 5 秒接收一次客户端的心跳，如果 15 秒内未收到某个实例的心跳，Nacos 会将该实例标记为不健康；如果 30 秒内仍未收到心跳，Nacos 则会将该实例从服务列表中移除。这样，消费者在调用服务时，就不会被分配到故障的实例上，从而保障了系统的稳定性和可靠性。

三、实操指南

理论知识储备完毕，接下来就进入实战环节，让我们一步步在项目中实现 Nacos 的服务注册与发现，并体验负载均衡的强大功能。为了更好地演示，我们将以一个简单的电商系统为例，包含订单服务（order-service，作为服务消费者）和商品服务（product-service，作为服务提供者）。

3.1 服务注册

1. 客户端集成（Spring Cloud Alibaba）

首先，在商品服务（product-service）的项目中，我们需要引入 nacos-discovery 依赖，让项目具备与 Nacos 交互的能力。在pom.xml文件中添加如下依赖：

<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId>
</dependency>

接着，配置服务名和 Nacos 地址。在application.yml文件中添加以下配置：

spring.application.name=product-service
server.port=8081spring.cloud.nacos.config.server-addr=127.0.0.1:8848
spring.config.import[0]=nacos:product-service.yaml?group=DEFAULT_GROUP

最后，在商品服务的启动类上添加@EnableDiscoveryClient注解，开启服务发现功能。这样，商品服务就完成了与 Nacos 的集成配置，具备了向 Nacos 注册的能力。

2. 控制台验证注册状态

完成上述配置后，启动 Nacos 服务器（如果还未启动），默认端口是 8848，访问http://localhost:8848/nacos，使用默认账号密码nacos/nacos登录 Nacos 控制台。

启动商品服务，然后在 Nacos 控制台中，进入 “服务管理 - 服务列表” 页面。在这里，我们可以找到刚刚注册的服务名 “product-service”，点击服务名进入详情页面，可以看到该服务的实例列表。确认实例的 IP、端口、权重、健康状态等信息是否正确，确保实例注册成功。如果一切正常，我们就能看到商品服务的实例信息，这表明商品服务已经成功在 Nacos 中 “亮相” ，随时准备为其他服务提供商品相关的数据。

3.2 服务发现

1. RestTemplate 调用（含负载均衡）

在订单服务（order-service）中，我们可以使用RestTemplate来调用商品服务。首先，配置RestTemplate并添加@LoadBalanced注解，使其具备基于服务名的负载均衡调用能力：

@Configuration
@LoadBalancerClient(name = "product-service")
public class RestTemplateConfig {public RestTemplate restTemplate() {return new RestTemplate();}
}

然后，在订单服务的业务代码中，通过RestTemplate调用商品服务：

@RestController
public class OrderController {@Autowiredprivate RestTemplate restTemplate;@GetMapping("/order/getProduct")public String getProduct() {return restTemplate.getForObject("http://product-service/product/info", String.class);}
}

2. OpenFeign 调用：声明式服务调用​

除了RestTemplate，我们还可以使用 OpenFeign 来实现服务间的调用，OpenFeign 是一种声明式的服务调用客户端，它让服务调用变得更加简单和直观。​

首先，在订单服务（order-service）的pom.xml文件中引入 openfeign 依赖：

<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-openfeign</artifactId><version>4.3.0</version>
</dependency>

接着，在订单服务的启动类上添加@EnableFeignClients注解，开启 OpenFeign 功能：

@SpringBootApplication
@EnableFeignClients
public class OrderServiceApplication {public static void main(String[] args) {SpringApplication.run(OrderServiceApplication.class, args);}
}

然后，创建一个 Feign 客户端接口，通过@FeignClient指定要调用的服务名 “product-service”：

@Autowiredprivate ProductClient productClient;@GetMapping("/order/getProductByFeign")public String getProductByFeign() {return productClient.getProductInfo();}

通过 OpenFeign，我们只需要定义一个接口，使用@FeignClient注解指定服务名，并在接口中声明要调用的方法和路径，就可以像调用本地方法一样调用远程服务，大大简化了服务调用的代码，提高了代码的可读性和可维护性。

3. 权重配置

Nacos 的权重配置功能可以让我们根据实际需求，精准地控制请求在不同实例之间的分配比例。

在 Nacos 控制台的 “服务管理 - 服务列表” 中，找到 “product-service” 的实例列表，点击实例右侧的 “编辑” 按钮，可以看到权重设置选项。假设我们有两个商品服务实例，实例 A 和实例 B，我们将实例 A 的权重设置为 80，实例 B 的权重设置为 20。

接下来，通过 Postman 或 curl 工具多次调用订单服务的/order/getProduct或/order/getProductByFeign接口（这两个接口分别对应使用RestTemplate和 OpenFeign 调用商品服务）。在多次请求后，我们可以观察到请求会按照 4:1（80:20）的比例分发到实例 A 和实例 B 上，从而验证了权重配置对负载均衡效果的影响。通过这种方式，我们可以根据服务器的性能、资源状况等因素，合理地分配流量，优化系统的整体性能 。

四、原理剖析

通过前面的实战，我们已经初步领略了 Nacos 在服务注册与发现以及负载均衡方面的强大功能。接下来，让我们深入到 Nacos 的底层，剖析其服务注册与发现的核心原理，了解这些功能背后的运行机制，这将有助于我们在实际项目中更好地使用 Nacos，优化系统性能 。​

1. 服务注册流程

服务注册是服务提供者向 Nacos 注册中心告知自己的存在和相关信息的过程，以便服务消费者能够发现并调用它。这一过程就像是新员工到公司人力资源部门登记入职信息，方便后续工作中的协作与沟通。下面我们来详细拆解 Nacos 的服务注册流程。​

• 客户端注册：服务启动时，Nacos 客户端会读取配置文件中关于 Nacos 服务器的地址等关键信息，并与 Nacos 服务端建立连接。这个连接就像是搭建了一条沟通的桥梁，让服务提供者能够将自己的信息传递给注册中心。接着，客户端将服务名、IP、端口、权重等重要信息封装成 HTTP 请求（对于临时实例，也可以使用 gRPC 请求），发送至 Nacos 服务端。这些信息就像是员工的姓名、工号、所在部门、岗位重要程度等，是服务注册的关键元数据。以我们之前的商品服务为例，其注册请求中会包含 “product-service” 服务名，以及该服务运行所在服务器的 IP 地址、端口号，可能还会根据服务器性能设置相应的权重等信息 。​
• 服务端存储：Nacos 服务端接收客户端发送的注册请求后，会对请求进行一系列的处理。首先，它会将实例信息存入内存，以便能够快速响应服务发现的请求，就像将员工信息先记录在一个便于查找的临时表格中。同时，为了保证数据的持久化和可靠性，服务端还会将这些信息持久化到数据库中，如同将员工信息存入公司的正式档案库。并且，服务端会建立起服务名到实例列表的映射关系，这就好比在档案库中建立了一个索引，通过服务名就能快速找到对应的服务实例列表，大大提高了查询效率 。​
• 心跳维护：为了确保服务实例的状态实时更新，Nacos 采用了心跳机制。客户端默认每 5 秒发送一次心跳包，这个心跳包中包含了实例的状态等信息，就像是员工定期向人力资源部门汇报自己的工作状态。Nacos 服务端会维护一个 “心跳超时计数器”，如果 15 秒内未收到某个实例的心跳，服务端就会将该实例标记为不健康，如同公司发现某个员工长时间没有汇报工作，会对其工作状态产生怀疑。如果 30 秒内仍未收到心跳，服务端则会将该实例从实例列表中移除，就像公司会将长期失联的员工从在职名单中除名。通过这种心跳机制，Nacos 能够及时发现故障的服务实例，保证服务列表中的实例都是健康可用的，为服务消费者提供可靠的服务调用目标 。​

2. 服务发现机制

服务发现是服务消费者获取服务提供者实例信息的过程，这是实现服务间通信的关键步骤。Nacos 采用了一种 “推拉结合” 的服务发现机制，确保服务消费者能够实时获取最新的服务实例信息，同时减少不必要的网络开销 。​

• 客户端拉取：当服务消费者启动时，它会向 Nacos 服务端发送请求，获取所需服务的实例列表。这个过程就像是新员工到公司后，向人力资源部门询问某个项目组的成员信息。默认情况下，消费者会每 30 秒定时向 Nacos 服务端拉取最新的服务实例列表，并将其更新到本地缓存中。本地缓存就像是员工自己记录的一份项目组成员信息表，方便随时查看调用。通过这种定时拉取的方式，即使在服务端推送出现问题的情况下，消费者也能定期获取最新的实例信息，保证服务调用的正常进行 。​
• 服务端推送：Nacos 服务端不仅仅是被动地等待客户端拉取实例信息，当服务实例发生新增、删除或权重变更等重要变化时，服务端会主动向订阅了该服务的消费者推送变更通知。这就好比公司的人力资源部门在员工岗位变动、新员工入职或老员工离职时，主动通知相关项目组。消费者接收到推送的变更通知后，会立即触发本地缓存的更新，确保本地缓存中的实例信息始终是最新的。这种服务端主动推送的机制，大大提高了信息的实时性，让消费者能够第一时间感知到服务实例的变化，做出相应的调整 。​
• 负载均衡选择：服务消费者从本地缓存中获取到服务实例列表后，会根据一定的负载均衡策略选择一个目标实例来发起调用。Nacos 提供了多种负载均衡策略，如轮询、随机、权重等。以权重策略为例，我们在前面实战中设置了商品服务不同实例的权重，消费者在调用时，会根据这些权重按比例选择实例。这就像是在分配工作任务时，根据员工的能力和工作量分配不同的任务量，让能力强、效率高的员工承担更多的任务，从而实现资源的合理利用和系统性能的优化。通过负载均衡策略，Nacos 能够将请求均匀地分发到各个服务实例上，避免单个实例负载过高，提高系统的整体吞吐量和可用性 。

五、 小结

在我们梳理完 Nacos 从服务注册到负载均衡的全链路逻辑，不难发现其核心价值在于用 “一体化设计” 解决微服务治理的核心痛点：从服务实例通过 “双模式注册”（临时 / 非临时）接入集群，到依托 “推拉结合” 的发现机制实现秒级状态同步，再到通过 “客户端 + 服务端” 双层架构落地轮询、权重、灰度等负载均衡策略，每一步都围绕 “高效” 与 “稳定” 展开。对开发人员而言，Nacos 简化了服务治理的复杂度 —— 无需单独搭建配置中心，通过 AP/CP 双模切换即可适配不同业务一致性需求，动态权重调整、灰度路由等特性更是让业务迭代更灵活；对运维人员来说，Raft 协议的一致性保障、“心跳 + 探测” 的双健康检查、跨区域部署方案，为集群稳定筑起了多道防线，大幅降低了运维成本。

无论是快速启动的中小型微服务项目，还是需要支撑高并发、跨机房的大型分布式系统，Nacos 都以 “轻量易用” 和 “生产级可靠” 的双重特质，成为连接服务与流量的关键枢纽。它不仅是技术层面的 “服务治理工具”，更是业务层面的 “弹性扩展支撑”，持续助力企业在微服务转型中少走弯路，实现业务的稳定运行与高效迭代。

Tips: 为了大家快速高效的学习，已经将文章提交到了git仓库，涵盖后端大部分技术，以及后端学习路线，仓库内容会持续更新，建议 Star 收藏 以便随时查看https://gitee.com/bxlj/java-article。