Spring Cloud Alibaba整合Nacos实战：服务注册与配置管理详解

1. 环境准备与版本选型：Nacos中和Spring Cloud Alibaba版本搭配

1.1 Nacos Server部署

在动手写业务代码之前，先把Nacos Server跑起来。这一步看着简单，但版本坑最多。我用的是Nacos 2.2.0版本，部署方式选的是单机模式，官方文档里写的是需要MySQL数据库支持，2.x版本默认使用内嵌数据库Derby，但生产环境强烈建议切换成MySQL。安装部署具体步骤如下：

• 去Nacos官方GitHub下载2.2.0版本的压缩包，解压到指定目录，这里以Linux服务器为例，目录结构为/opt/nacos。
• 修改配置文件conf/application.properties，把数据源改成MySQL，需要新建数据库，库名可以叫nacos_config，然后执行conf/mysql-schema.sql初始化脚本。
• 单机模式启动命令：sh startup.sh -m standalone，这里的-m参数指定模式，standalone表示单机。启动后访问http://127.0.0.1:8848/nacos，默认账号密码都是nacos，首次登录后建议立刻修改。

1024是新手第一次接触Nacos最容易犯的错误，就是直接用官方默认包启动后发现控制台打不开，或者是登录密码不对。这里补充说明：Nacos 2.2.0的登录逻辑和1.x版本不一样，默认的用户名密码是nacos/nacos，这个很多老文章没讲清楚。还有一点，启动前检查一下磁盘空间，Nacos的日志增长很快，尤其是登录失败时会产生大量的鉴权日志，磁盘被写满导致服务挂掉的案例我见过不止一次。

1.2 Spring Cloud Alibaba版本对应关系

Spring Cloud Alibaba和各组件版本对应关系，这块是整合踩坑的重灾区，建议直接对照官方Wiki的版本说明。我自己项目里最终确定的版本组合是Spring Boot 2.6.11加Spring Cloud 2021.0.3加Spring Cloud Alibaba 2021.0.5.0，这几个版本是经过了多次验证的，搭配起来问题最少。

版本选择背后的逻辑值得展开讲讲。Spring Cloud Alibaba是在2020版本之后把版本号改为以年份命名的，2021.0.5.0对应的是Spring Cloud 2021.0.x系列的版本，而Nacos客户端则是由Spring Cloud Alibaba自己维护的。如果Spring Boot版本低于2.4，或者Spring Cloud版本低于2020.0.0，很多动态刷新和配置绑定的功能支持就不完整，比如bootstrap.yml的加载机制在Spring Boot 2.4之后默认是关闭的，需要单独引入依赖或者配置开启。当前项目接口用到了Web功能，所以引入的starter选择spring-cloud-starter-alibaba-nacos-discovery和spring-cloud-starter-alibaba-nacos-config这两个核心依赖。

这段选型是整个项目能否顺利跑起来的关键。我见过太多人随便选了一个版本，然后出现注册不上、配置读取不到等问题，最后排查半天发现是版本不兼容。所以如果你跟我一样用的是Spring Boot 2.6.x，建议直接复制我这份组合，不要自己乱配版本号。

2. 服务注册与发现实现：搭建Provider和Consumer

2.1 搭建服务提供者Provider

服务注册的代码看起来简单，但工程结构布局是课堂教学里不会强调的事情。我习惯把服务拆成nacos-provider和nacos-consumer两个独立的Spring Boot工程。Provider对外提供接口，Consumer通过Nacos发现Provider并调用接口。

先看Provider的具体实现。新建一个Spring Boot项目，引入依赖，核心依赖如下：

<dependency> <groupId>com.alibaba.cloud</groupId> <artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency>

配置文件application.yml里最关键的是注册中心地址，这段配置要注意：

spring: application: name: nacos-provider cloud: nacos: discovery: server-addr: 127.0.0.1:8848 register-enabled: true service: ${spring.application.name} server: port: 8081

这里解释几个关键配置项的含义。spring.application.name必须配置，这是服务注册到Nacos之后的服务名，如果没配置，注册中心的列表里会看不到服务。server-addr是Nacos服务端的地址，端口默认是8848。register-enabled默认就是true，其实可以不写，但写出来比较直观，方便后续做灰度发布时设置为false。service这个参数是服务注册名，默认取${spring.application.name}，显式配置是为了防止有些场景下取错。

Provider核心接口代码：

@RestController @RequestMapping("/provider") public class ProviderController { @GetMapping("/hello") public String hello(@RequestParam String name) { return "Hello, " + name + ", this is nacos-provider!"; } }

2.2 搭建服务消费者Consumer

Consumer同样引入nacos-discovery依赖，配置文件里服务名改成nacos-consumer，端口改成8082。Consumer调用Provider的方式有两种，一种是RestTemplate配合@LoadBalanced注解，另一种是OpenFeign。我推荐用OpenFeign，因为代码更优雅，声明式接口很好维护。

OpenFeign需要额外引入依赖：

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

Consumer启动类增加@EnableFeignClients注解，然后定义一个FeignClient接口：

@FeignClient(name = "nacos-provider") public interface ProviderClient { @GetMapping("/provider/hello") String hello(@RequestParam("name") String name); }

Controller里直接注入这个Client：

@RestController @RequestMapping("/consumer") public class ConsumerController { @Autowired private ProviderClient providerClient; @GetMapping("/call") public String call(@RequestParam String name) { return providerClient.hello(name); } }

2.3 验证与原理分析

启动Nacos，再依次启动Provider和Consumer，打开Nacos控制台，在服务列表里可以看到两个服务，服务名是nacos-provider和nacos-consumer，集群数默认是单机，实例数是各一个。

服务注册的原理值得聊一聊。Nacos客户端启动后，会通过心跳机制向注册中心发送注册请求，默认是每5秒发送一次心跳。Nacos 2.x版本的通信协议改用gRPC之后，长连接维护比以前更好，在控制台能看到健康状态显示为“上线”。如果你在控制台看不到服务，先不要怀疑代码写错了，用curl命令检查注册中心是否正常：

curl -X GET "http://127.0.0.1:8848/nacos/v1/ns/service/list?pageNo=1&pageSize=10"

返回结果里如果能看到服务名，说明注册中心没问题，问题出在客户端。再通过curl -X GET查看实例详情：

curl -X GET "http://127.0.0.1:8848/nacos/v1/ns/instance/list?serviceName=nacos-provider"

这里要说一下负载均衡的处理。Feign调用默认集成了Ribbon的负载均衡能力，因为Spring Cloud 2021.0.x移除了Ribbon的自动配置，Spring Cloud LoadBalancer已经替代了它，@LoadBalanced和@FeignClient会自动适配，不需要额外引入Ribbon依赖。如果要用用户自定义的负载均衡策略，可以通过实现ServiceInstanceListSupplier接口来定制，这个后续文章可以展开讲。

3. 配置管理实战：Nacos Config动态刷新与共享配置

3.1 引入配置中心依赖

服务注册搞定之后，接下来做配置管理。这是Nacos比较核心的能力。Spring Cloud Alibaba整合Nacos配置管理，需要额外引入依赖：

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

3.2 bootstrap配置与动态刷新机制

环境配置最头疼的是Spring Boot 2.4版本以后的加载顺序变化。Spring Boot 2.4之前，bootstrap.yml是自动加载的；Spring Boot 2.4之后，默认不再加载bootstrap.yml了，必须通过在pom.xml里引入依赖或者在配置文件手动开启。

我很推荐在pom.xml里引入spring-cloud-starter-bootstrap依赖来开启：

<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-bootstrap</artifactId> </dependency>

然后新建bootstrap.yml配置文件：

spring: application: name: nacos-provider cloud: nacos: config: server-addr: 127.0.0.1:8848 file-extension: yaml group: DEFAULT_GROUP

这里重点说两个细节。第一，file-extension支持properties和yaml两种格式，在Nacos控制台新建配置时，Data ID要写成${spring.application.name}.yaml这种格式，比如nacos-provider.yaml，只有这样客户端才知道去哪里找对应文件。第二，group默认就是DEFAULT_GROUP，如果没有特殊需求可以先不配，但在真正的多环境管理时需要区分。

Nacos配置管理最吸引人的地方是动态刷新，不用重启服务就能修改配置。做法如下：

• 在Nacos控制台的配置管理界面，新建配置nacos-provider.yaml，内容里放一个测试配置项，比如user.name=test-user-from-nacos。
• 在代码里用@Value读取这个配置：

@RestController @RequestMapping("/config") public class ConfigController { @Value("${user.name}") private String userName; @GetMapping("/get") public String get() { return userName; } }

• 启动服务后，第一次访问/config/get返回的是Nacos里的值，然后去控制台修改配置内容，再刷新接口，发现返回的是新值，根本没重启应用。

这个机制背后的原理是：Nacos客户端会基于长轮询机制，默认每30秒向服务端发一次请求，但这个请求不是立即返回的，服务端会hold住30秒左右，如果在这个时间段内配置发生了变化，服务端立刻返回变化的通知，客户端收到通知后立即更新本地配置，整个响应时间大概在1到3秒之间，不需要等30秒。这其实是一种很高效的长轮询方案。

3.3 多环境与共享配置实现

动态刷新做通了就要面对更实际的场景：多环境配置。开发环境、测试环境、生产环境的数据库地址、日志级别肯定不一样，Nacos解决这个问题提供了三种途径。

第一种是通过spring.profiles.active来区分。启动时加上--spring.profiles.active=dev，Nacos客户端就会去加载nacos-provider-dev.yaml这个配置。前提是Data ID要提前准备好。好处是配置隔离非常清晰，比如nacos-provider-dev.yaml、nacos-provider-test.yaml、nacos-provider-prod.yaml三个文件各管各的环境。

第二种是通过group区分。同一个Data ID可以有不同的group，通过bootstrap.yml里的group: DEV切换。这种方式通常用于按业务域或团队来隔离配置的场景。

第三种是extension-configs，用于加载公共的共享配置。比如多个服务都要使用同一个Redis配置或数据源配置，就可以把这部分配置单独放在一个common.yaml文件里，然后在每个服务的bootstrap.yml中引用：

spring: cloud: nacos: config: extension-configs: ->