Nacos注册中心：服务注册、发现、健康检测
Nacos注册中心：服务注册、发现、健康检测
微服务世界里，服务之间打招呼的方式不是"你好"，而是"你在哪？你的 IP 是多少？"——这就是注册中心干的事。
一、注册中心到底解决什么问题？
单体架构里，服务 A 调服务 B，直接new一个对象就行，因为都在一个进程里。但微服务拆开后，订单服务要调商品服务的接口，商品服务的 IP 可能随时变化（扩容、重启、迁移），你总不能把 IP 写死在代码里吧？
注册中心就是来解决这个问题的。它的核心职责有三条：
- 服务地址管理：每个服务启动后把自己注册上去，调用方从注册中心获取可用实例列表
- 负载均衡基础：同一个服务有多个实例，注册中心提供列表，客户端做负载均衡选择
- 服务健康监控：持续检测服务是否存活，挂掉的实例自动剔除
┌──────────┐ 1.注册(IP:PORT) ┌──────────┐ │ 商品服务-A │ ──────────────────→ │ │ └──────────┘ │ Nacos │ ┌──────────┐ 1.注册(IP:PORT) │ 注册中心 │ │ 商品服务-B │ ──────────────────→ │ │ └──────────┘ └────┬─────┘ │ 2.拉取实例列表 ┌──────────┐ ▼ │ 订单服务 │ ◄────────────────────────┘ └──────────┘ 3.负载均衡选择一个实例调用二、Nacos简介：注册中心+配置中心，两合一
Nacos =Naming +Configuration +Service。阿里开源，一个组件干两件事：
- 注册中心：服务注册与发现（对标 Eureka）
- 配置中心：统一配置管理与动态刷新（对标 Spring Cloud Config）
为什么选 Nacos 而不是 Eureka？除了 Eureka 停更这个硬伤，Nacos 还有几个杀手锏：
| 特性 | Eureka | Nacos |
|---|---|---|
| 配置中心 | 不支持 | 内置 |
| 健康检测 | 客户端心跳 | 心跳 + 服务端主动探测 |
| 实例类型 | 临时实例 | 临时实例 + 永久实例 |
| 一致性协议 | AP（AP 模式） | AP + CP 可切换 |
| 控制台 | 简陋 | 功能丰富可视化管理 |
三、Nacos安装启动：Docker 一行搞定
生产环境建议用集群模式，但开发和学习阶段，Docker 起一个 standalone 实例最方便：
# 拉取 Nacos 2.x 镜像dockerpull nacos/nacos-server:v2.3.0# 单机模式启动（standalone）dockerrun-d\--namenacos\-eMODE=standalone\-eJVM_XMS=256m\-eJVM_XMX=256m\-p8848:8848\-p9848:9848\nacos/nacos-server:v2.3.0注意：Nacos 2.x 新增了 gRPC 通信端口，默认是主端口 + 1000 偏移。8848 对应的 gRPC 端口是 9848，别忘了一起映射，否则客户端连接会报错。
启动后访问控制台：http://localhost:8848/nacos，默认账号密码都是nacos。
四、SpringBoot 整合 Nacos：三步注册
以无人售货柜的商品服务（product-service）为例，整合 Nacos 注册中心。
第一步：添加依赖
<dependency><groupId>com.alibaba.cloud</groupId><artifactId>spring-cloud-starter-alibaba-nacos-discovery</artifactId></dependency>第二步：application.yml 配置
spring:application:name:product-service# 服务名，注册到 Nacos 的名称cloud:nacos:discovery:server-addr:127.0.0.1:8848# Nacos 地址namespace:public# 命名空间，默认 publicgroup:DEFAULT_GROUP# 分组，默认 DEFAULT_GROUP第三步：启动类加注解（SpringBoot 3.x 可省略）
@SpringBootApplication@EnableDiscoveryClient// SpringBoot 3.x + SpringCloud 2023 可省略，自动装配publicclassProductServiceApplication{publicstaticvoidmain(String[]args){SpringApplication.run(ProductServiceApplication.class,args);}}启动服务后，打开 Nacos 控制台 → 服务管理 → 服务列表，就能看到product-service注册上去了。
五、服务发现：两种方式调别人
还是无人售货柜项目，订单服务（order-service）要调用商品服务的接口。有两种方式：
5.1 DiscoveryClient + RestTemplate（手动拉取）
@RestControllerpublicclassOrderController{@AutowiredprivateRestTemplaterestTemplate;@AutowiredprivateDiscoveryClientdiscoveryClient;// Spring Cloud 提供的发现客户端@GetMapping("/order/create")publicStringcreateOrder(){// 从 Nacos 拉取 product-service 的实例列表List<ServiceInstance>instances=discoveryClient.getInstances("product-service");if(instances.isEmpty()){thrownewRuntimeException("商品服务不可用");}// 简单负载均衡：取第一个（实际应轮询）ServiceInstanceinstance=instances.get(0);Stringurl=instance.getUri()+"/product/info?productId=1001";returnrestTemplate.getForObject(url,String.class);}}这种方式比较原始，适合理解原理。实际开发中用下面的方式。
5.2 @LoadBalanced + RestTemplate（自动负载均衡）
@ConfigurationpublicclassRestConfig{@Bean@LoadBalanced// 关键注解！加上这个，RestTemplate 自动具备负载均衡能力publicRestTemplaterestTemplate(){returnnewRestTemplate();}}调用时直接用服务名替代 IP：
@GetMapping("/order/create")publicStringcreateOrder(){// 直接用服务名 product-service，不用关心 IP 和端口Stringurl="http://product-service/product/info?productId=1001";returnrestTemplate.getForObject(url,String.class);}@LoadBalanced注解背后的原理是拦截器拦截 HTTP 请求，把 URL 中的服务名替换成从 Nacos 拉取的实际 IP:PORT，再用轮询策略选一个实例。底层负载均衡器从 Ribbon 换成了 Spring Cloud LoadBalancer（2023.x 版本）。
六、健康检测机制：心跳保活
Nacos 区分两种实例类型，健康检测方式不同：
| 实例类型 | 健康检测方式 | 不健康后 | 适用场景 |
|---|---|---|---|
| 临时实例（默认） | 客户端心跳上报（5秒一次） | 超时自动剔除 | 需要弹性伸缩的服务 |
| 永久实例 | Nacos 服务端主动探测 | 标记为不健康，不剔除 | 数据库、缓存等基础服务 |
临时实例心跳机制详解：
客户端 Nacos │ │ │──── 心跳上报（每 5 秒）─────────→│ 实例状态：健康 │ │ │ （15 秒未收到心跳） │ │ │ 实例状态：不健康 │ │ │ （30 秒未收到心跳） │ │ │ 实例状态：删除- 5 秒：客户端上报一次心跳，确认自己活着
- 15 秒：未收到心跳，标记实例为不健康（healthy=false）
- 30 秒：仍未收到心跳，彻底删除实例
这也就是为什么你 kill 掉一个服务后，Nacos 控制台里的实例不会立刻消失——它需要等心跳超时。
七、集群模式：高可用的关键
生产环境不能只跑一个 Nacos 实例，挂了全盘皆输。Nacos 集群至少 3 个节点，推荐 5 个（奇数个，Raft 协议投票需要多数派）。
集群搭建核心要点：
- 数据存储用 MySQL：standalone 模式用嵌入式数据库，集群模式必须外接 MySQL
- 节点配置一致：cluster.conf 文件里写上所有节点 IP
- 前面挂 Nginx：客户端连 Nginx 地址，Nginx 转发到后端 Nacos 集群
┌─────────┐ 客户端 ──────────│ Nginx │ └────┬────┘ ┌───────┬────┴────┬───────┐ ▼ ▼ ▼ ▼ ┌──────┐ ┌──────┐ ┌──────┐ │Nacos1│ │Nacos2│ │Nacos3│ └──┬───┘ └──┬───┘ └──┬───┘ └────────┼────────┘ ▼ ┌──────────┐ │ MySQL │ ← 集群数据持久化 └──────────┘cluster.conf配置示例：
192.168.1.101:8848 192.168.1.102:8848 192.168.1.103:8848八、Nacos 控制台：可视化管理
Nacos 控制台提供了完整的可视化管理界面：
- 服务列表：查看所有注册的服务、实例数量、健康实例数
- 实例详情：点击服务名查看每个实例的 IP、端口、权重、健康状态
- 上下线操作：可以手动将实例标记为下线（healthy=false），流量不再路由到该实例，常用于灰度发布和优雅停机
权重配置是一个实用功能：给不同实例设置不同权重，权重高的实例分配更多流量。比如新版本的实例先设置低权重，逐步调高，实现灰度发布。
九、常见问题排查
问题1：服务注册不上 Nacos
排查步骤：
- 确认 Nacos 服务正常运行：
curl http://localhost:8848/nacos/v1/ns/operator/metrics - 确认
spring.application.name已配置 - 确认
spring.cloud.nacos.discovery.server-addr地址正确 - 查看启动日志中是否有 Nacos 注册相关报错
问题2：服务注册上了但被频繁剔除
常见原因是心跳间隔过大或网络抖动。可以检查：
spring:cloud:nacos:discovery:heart-beat-interval:5000# 心跳间隔（毫秒），默认 5000heart-beat-timeout:15000# 心跳超时（毫秒），默认 15000如果服务在 Kubernetes 环境中，还要注意 Pod 的 liveness probe 和 Nacos 心跳的冲突问题。
十、总结
注册中心是微服务架构的基石。Nacos 一个组件同时搞定注册中心和配置中心，standalone 模式开发够用，集群模式生产够稳。核心记住三点：服务通过spring.application.name注册、调用方用@LoadBalanced+ 服务名调用、健康靠 5 秒心跳保活。