从源码到生产：基于开源项目 Nacos 的服务注册与配置中心实战落地指南

Nacos 在国内 Java 微服务体系里几乎绕不过去：做服务注册与发现，很多团队会选它；做配置中心，也常常是它。我这篇文章不打算停留在“会用控制台点点点”的层面，而是按**“为什么这样设计 → 源码里怎么实现 → 本地怎么跑起来 → 生产怎么落地”**的顺序，带你走一遍。

如果你已经会用 Spring Cloud Alibaba，但总感觉：

注册中心能用，但心跳、临时实例、健康检查这些概念有点混；
配置中心能拉到配置，但长轮询、动态刷新、灰度发布不太敢上线；
本地开发没问题，一上生产就会碰到集群、数据库、鉴权、性能问题；

那这篇文章就是写给你的。

背景与问题

在微服务拆分之后，最先暴露出来的两个痛点通常是：

服务地址不稳定
- 服务实例会扩缩容、重启、漂移；
- 调用方不能写死 IP 和端口；
- 需要一个地方统一管理“谁在线、谁可用”。
配置变更成本高
- 数据库地址、开关项、限流阈值不能写死在包里；
- 多环境、多人协作下，配置版本很容易混乱；
- 想要不重启服务就让配置生效。

Nacos 正是为这两件事而生：

Naming 模块：服务注册与发现
Config 模块：配置管理与动态推送

但真正落地时，仅仅知道“客户端注册到服务端”还不够。我们还得回答这些问题：

服务实例是怎么保活的？
为什么有临时实例和持久化实例？
配置更新为什么不是客户端一直疯狂轮询？
Spring 应用收到配置后，哪些 Bean 能自动刷新，哪些不能？
集群部署后数据存在什么地方？一致性怎么保证？

先别急，我们一步步来。

前置知识与环境准备

本文默认你具备这些基础：

会写 Spring Boot 应用
知道 Maven/Gradle 的基本使用
理解 HTTP、JSON、YAML
对微服务调用链有基本认识

环境版本建议

为了保证示例可运行，我建议使用：

JDK 8 或 11
Maven 3.6+
Nacos 2.x
Spring Boot 2.6.x
Spring Cloud Alibaba 2021.x 对应版本

版本兼容非常关键。我踩过的一个坑就是：Spring Boot、Spring Cloud、Spring Cloud Alibaba、Nacos Client 四者版本随手一配，结果启动时报一堆自动装配异常。
生产里一定要按官方版本矩阵来。

核心原理

这一部分我不想只是“概念罗列”，而是从运行过程看 Nacos 的设计。

1. 服务注册与发现的工作流

当一个服务启动时，会向 Nacos 注册自己的实例信息，比如：

服务名：user-service
IP：192.168.1.10
端口：8081
集群：DEFAULT
是否临时实例：true

调用方则按服务名去 Nacos 查询可用实例列表，再通过负载均衡选一个发请求。

flowchart LR
    A[Provider 启动] --> B[向 Nacos 注册实例]
    B --> C[Nacos 保存服务实例]
    D[Consumer 发起调用] --> E[向 Nacos 查询实例列表]
    E --> C
    C --> F[返回健康实例]
    F --> G[Consumer 负载均衡选择目标实例]
    G --> H[发起 RPC/HTTP 调用]

2. 为什么 Nacos 要区分临时实例和持久化实例

这点很多人第一次接触时容易忽略。

临时实例 `ephemeral=true`

依赖客户端主动上报心跳；
心跳超时后，Nacos 会把实例剔除；
适合绝大多数微服务应用。

持久化实例 `ephemeral=false`

不靠客户端心跳自动剔除；
更多依赖服务端探测或人工维护；
适合一些特殊场景，比如外部系统接入。

从源码设计角度看，这个区分影响了实例的生命周期管理逻辑。
临时实例更轻量，也更符合云原生弹性场景。

3. 心跳与健康检查机制

服务注册不是“一次注册，永久有效”。Nacos 要知道实例是不是还活着。

简化理解是这样的：

客户端注册实例；
客户端定时发送心跳；
服务端更新该实例最后活跃时间；
超过阈值没心跳，实例先标记不健康；
再超过阈值，实例可能被摘除。

sequenceDiagram
    participant App as 服务实例
    participant Nacos as Nacos Server
    participant Consumer as 调用方

    App->>Nacos: 注册实例
    loop 定时心跳
        App->>Nacos: heartbeat
        Nacos-->>App: ok
    end

    Consumer->>Nacos: 查询实例列表
    Nacos-->>Consumer: 返回健康实例

    Note over App,Nacos: 如果长时间无心跳
    Nacos->>Nacos: 标记实例不健康/摘除

4. 配置中心为什么用长轮询

如果客户端每秒来拉一次配置，那服务器和网络都会很累；如果每分钟拉一次，配置变更又不够实时。Nacos 的典型方案是长轮询：

客户端发起请求，告诉服务端“我当前持有的配置 MD5 是什么”
如果配置没变，服务端先不返回，挂起一段时间
一旦配置变化，或超时到达，服务端立即返回最新结果
客户端更新本地缓存，并触发监听器

这是一种在实时性与资源开销之间比较平衡的方式。

sequenceDiagram
    participant Client as 应用客户端
    participant Server as Nacos Config

    Client->>Server: 长轮询请求(携带本地MD5)
    alt 配置未变化
        Server-->>Client: 挂起请求直到超时
    else 配置已变化
        Server-->>Client: 返回变更的 DataId
        Client->>Server: 拉取最新配置内容
        Server-->>Client: 返回最新配置
        Client->>Client: 更新缓存并触发监听器
    end

5. 从源码视角理解 Nacos 的两个关键点

这里不展开逐行源码，而是抓核心设计。

Naming 侧关注点

服务 Service
实例 Instance
心跳处理
健康状态维护
订阅与推送

Config 侧关注点

配置三元组：dataId、group、namespace
本地快照缓存
长轮询任务
变更监听器
与 Spring Environment 的桥接

你会发现，Nacos 的设计其实很朴素：

Naming 解决“服务在哪”
Config 解决“参数是什么”

但这两个模块都离不开一个核心能力：变化感知。
服务变化了，要尽快通知调用方；配置变化了，要尽快通知应用。

实战代码（可运行）

下面我们做一个最小可运行示例：

一个 provider-service 注册到 Nacos
一个 consumer-service 从 Nacos 发现 provider
provider 同时从 Nacos 读取动态配置

为了控制篇幅，我用 Maven + Spring Boot 演示。

第一步：启动 Nacos

如果你本机已经装了 Nacos，可以跳过。这里用 Docker 最直接。

docker run --name nacos-standalone \
  -e MODE=standalone \
  -e NACOS_AUTH_ENABLE=false \
  -p 8848:8848 \
  -d nacos/nacos-server:v2.2.3

启动后访问：

http://localhost:8848/nacos

默认账号密码通常是：

nacos / nacos

本地学习时可以关鉴权，生产环境千万别这么干，后面会讲。

第二步：创建 Provider 服务

1. `pom.xml`

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
         http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.example</groupId>
    <artifactId>provider-service</artifactId>
    <version>1.0.0</version>

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.6.13</version>
    </parent>

    <properties>
        <java.version>8</java.version>
        <spring-cloud.version>2021.0.5</spring-cloud.version>
        <spring-cloud-alibaba.version>2021.0.5.0</spring-cloud-alibaba.version>
    </properties>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-dependencies</artifactId>
                <version>${spring-cloud.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
            <dependency>
                <groupId>com.alibaba.cloud</groupId>
                <artifactId>spring-cloud-alibaba-dependencies</artifactId>
                <version>${spring-cloud-alibaba.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

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

2. `bootstrap.yml`

使用 Nacos Config 时，配置初始化通常放在 bootstrap.yml 更稳妥。

server:
  port: 8081

spring:
  application:
    name: provider-service
  cloud:
    nacos:
      server-addr: 127.0.0.1:8848
      discovery:
        namespace: public
        group: DEFAULT_GROUP
      config:
        namespace: public
        group: DEFAULT_GROUP
        file-extension: yaml
        refresh-enabled: true

3. `ProviderApplication.java`

package com.example.provider;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;

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

4. `HelloController.java`

package com.example.provider;

import org.springframework.beans.factory.annotation.Value;
import org.springframework.cloud.context.config.annotation.RefreshScope;
import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;

@RestController
@RefreshScope
public class HelloController {

    @Value("${app.message:default-message}")
    private String message;

    @GetMapping("/hello")
    public String hello() {
        return "provider says: " + message;
    }
}

5. 在 Nacos 控制台添加配置

新增配置：

Data ID: provider-service.yaml
Group: DEFAULT_GROUP

配置内容：

app:
  message: hello from nacos config

6. 启动服务

mvn spring-boot:run

启动后你可以在 Nacos 控制台看到 provider-service 已注册。

访问：

http://localhost:8081/hello

返回类似：

provider says: hello from nacos config

第三步：创建 Consumer 服务

1. `pom.xml`

<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0
         http://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.example</groupId>
    <artifactId>consumer-service</artifactId>
    <version>1.0.0</version>

    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>2.6.13</version>
    </parent>

    <properties>
        <java.version>8</java.version>
        <spring-cloud.version>2021.0.5</spring-cloud.version>
        <spring-cloud-alibaba.version>2021.0.5.0</spring-cloud-alibaba.version>
    </properties>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.springframework.cloud</groupId>
                <artifactId>spring-cloud-dependencies</artifactId>
                <version>${spring-cloud.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
            <dependency>
                <groupId>com.alibaba.cloud</groupId>
                <artifactId>spring-cloud-alibaba-dependencies</artifactId>
                <version>${spring-cloud-alibaba.version}</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

    <dependencies>
        <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>
        <dependency>
            <groupId>org.springframework.cloud</groupId>
            <artifactId>spring-cloud-starter-loadbalancer</artifactId>
        </dependency>
    </dependencies>
</project>

2. `application.yml`

server:
  port: 8082

spring:
  application:
    name: consumer-service
  cloud:
    nacos:
      server-addr: 127.0.0.1:8848
      discovery:
        namespace: public
        group: DEFAULT_GROUP

3. `ConsumerApplication.java`

package com.example.consumer;

import org.springframework.boot.SpringApplication;
import org.springframework.boot.autoconfigure.SpringBootApplication;
import org.springframework.cloud.client.loadbalancer.LoadBalanced;
import org.springframework.context.annotation.Bean;
import org.springframework.web.client.RestTemplate;

@SpringBootApplication
public class ConsumerApplication {

    public static void main(String[] args) {
        SpringApplication.run(ConsumerApplication.class, args);
    }

    @Bean
    @LoadBalanced
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

4. `CallController.java`

package com.example.consumer;

import org.springframework.web.bind.annotation.GetMapping;
import org.springframework.web.bind.annotation.RestController;
import org.springframework.web.client.RestTemplate;

@RestController
public class CallController {

    private final RestTemplate restTemplate;

    public CallController(RestTemplate restTemplate) {
        this.restTemplate = restTemplate;
    }

    @GetMapping("/call")
    public String call() {
        return restTemplate.getForObject("http://provider-service/hello", String.class);
    }
}

5. 启动并验证

mvn spring-boot:run

访问：

http://localhost:8082/call

provider says: hello from nacos config

到这里，一个最小闭环已经打通：

provider 注册到 Nacos
consumer 从 Nacos 发现 provider
provider 的返回内容来自 Nacos 配置中心

第四步：验证动态配置刷新

很多教程到这里就结束了，但我建议你一定亲手做这一步，因为这才是配置中心真正的价值所在。

修改 Nacos 配置

把 provider-service.yaml 改成：

app:
  message: config updated without restart

发布后，再访问：

http://localhost:8081/hello

理论上会看到：

provider says: config updated without restart

如果没刷新，优先检查：

Controller 是否加了 @RefreshScope
是否正确引入了 spring-cloud-starter-alibaba-nacos-config
Data ID 是否与应用名和扩展名匹配
配置加载是否真的发生在启动早期

逐步验证清单

我建议实际项目接入时，按下面顺序验证，不要一步到位：

注册中心验证

Nacos 控制台可正常登录
Provider 启动后实例出现在服务列表
Consumer 能通过服务名访问 Provider
停掉 Provider 后实例会变为不健康或被剔除
多实例启动后 Consumer 能轮询访问

配置中心验证

应用启动时能读到 Nacos 配置
本地配置与远程配置优先级符合预期
修改配置后无需重启即可刷新
错误配置发布后有回滚方案
配置变更有审计记录

上线前验证

生产落地：推荐的命名与隔离策略

Nacos 的配置组织模型是：

namespace：环境隔离
group：业务逻辑分组
dataId：具体配置项

我的建议是：

namespace 按环境隔离

dev
test
staging
prod

group 按业务域或团队分组

ORDER_GROUP
USER_GROUP
PAY_GROUP

dataId 按服务名命名

provider-service.yaml
consumer-service.yaml
gateway-service.yaml

这样做的好处是：

环境不会串；
不同业务线配置边界清晰；
排查时更容易定位。

我见过一些团队把所有配置都塞在 DEFAULT_GROUP/public 下，前期省事，后面配置数量一多，查找和权限控制都会很痛苦。

常见坑与排查

这一节我尽量写得“接地气”一点，都是实际项目中高频遇到的问题。

1. 服务明明启动了，但 Nacos 控制台看不到实例

常见原因

server-addr 配错
服务名为空或重复
客户端依赖版本不兼容
网络不通，尤其是容器环境下地址映射不对

排查方法

看应用启动日志里是否有 Nacos 注册成功信息；
curl 目标 Nacos 地址确认网络连通；

检查应用名是否正确：

spring:
  application:
    name: provider-service

检查容器内注册的 IP 是否可达。

在 Docker/K8s 场景中，注册 IP 错误是高频问题。
比如注册成了容器内部地址，结果其他节点根本访问不到。

2. Consumer 调用报 `No instances available for provider-service`

常见原因

Provider 没注册成功
namespace/group 不一致
服务名写错
实例不健康

排查方法

在 Nacos 控制台确认服务名完全一致；
检查 Consumer 和 Provider 的 namespace/group 是否一致；
查看实例是否健康；
打开客户端日志，确认服务发现缓存是否更新。

3. 配置修改后不生效

常见原因

@RefreshScope 没加
Data ID 不匹配
使用了 application.yml 导致加载时机不对
读取配置的 Bean 不是可刷新的

正确示例

@RestController
@RefreshScope
public class DemoController {

    @Value("${demo.key:default}")
    private String demoKey;

    @GetMapping("/demo")
    public String demo() {
        return demoKey;
    }
}

额外提醒

不是所有场景都适合动态刷新。
例如：

数据源连接池参数
线程池核心参数
某些初始化后不可变的第三方客户端

这些配置改了即使推送成功，也不一定真正生效，有时还会引发状态不一致。

4. 本地好好的，生产集群频繁掉线

常见原因

心跳链路不稳定
节点时间不同步
Nacos 集群节点之间通信异常
数据库性能瓶颈拖慢服务端处理

排查建议

检查 NTP 时间同步；
检查 Nacos 集群节点日志；
观察数据库慢 SQL；
检查服务端 CPU、内存、GC 情况。

5. 配置误发布导致线上故障

这不是“会不会发生”的问题，而是“什么时候发生”的问题。

止血建议

配置发布前做格式校验；
关键配置双人审核；
保留历史版本，一键回滚；
对高风险配置采用灰度发布，不要全量秒推。

安全/性能最佳实践

这部分很重要。很多团队把 Nacos 当成“内部工具”，结果生产环境安全边界做得很弱。

安全最佳实践

1. 一定开启鉴权

本地开发可以关闭，生产必须开启。

至少做到：

控制台登录鉴权
OpenAPI 鉴权
最小权限分配

2. 按 namespace/group 做权限隔离

不要让所有人都能改生产配置。
建议把：

开发环境
测试环境
生产环境

彻底分开，并绑定不同角色。

3. 敏感配置不要明文裸奔

像这些内容：

数据库密码
Redis 密码
AccessKey/SecretKey
第三方令牌

不要直接明文放配置中心。至少要结合：

加密存储
启动时解密
权限控制
审计日志

4. 配置变更必须可审计

要能回答这些问题：

谁改了配置？
什么时候改的？
改了什么？
何时回滚的？

如果这些问题答不上来，出故障时排查会非常被动。

性能最佳实践

1. 不要把 Nacos 当数据库用

Nacos 适合放：

应用配置
开关项
规则参数

不适合放：

大体量业务数据
高频变更的明细数据
超大文件内容

2. 控制配置粒度

配置拆得太细，会增加维护成本；拆得太粗，又容易互相影响。

经验上建议：

一个服务一个主配置文件
公共配置单独抽出
高风险配置单独隔离

3. 多实例订阅时关注推送风暴

如果一个配置被几百上千个实例监听，频繁更新会带来明显压力。

建议：

降低高频配置变更次数；
把“频繁变化”的内容迁到更适合的系统；
做分批发布或灰度。

4. Nacos 集群至少三节点

生产推荐：

3 个或 5 个 Nacos 节点
外挂 MySQL
前置 SLB / VIP

这样可以兼顾可用性和运维复杂度。

一个典型生产部署示意

flowchart TB
    A[应用实例A] --> LB[SLB/VIP]
    B[应用实例B] --> LB
    C[应用实例C] --> LB

    LB --> N1[Nacos Node 1]
    LB --> N2[Nacos Node 2]
    LB --> N3[Nacos Node 3]

    N1 --> DB[(MySQL)]
    N2 --> DB
    N3 --> DB

从源码到生产的关键理解：别把“能跑”当“可用”

很多人学习 Nacos 的过程是：

跑个单机版；
配一下 server-addr；
服务注册成功；
觉得“我会了”。

但真正生产可用，还差很远。你至少要补上这几个认知：

1. 注册成功不等于调用可靠

服务发现只是第一步，真正调用可靠还依赖：

超时
重试
熔断
限流
负载均衡策略

2. 配置可刷新不等于可以随便改

动态配置是能力，不是鼓励“线上手改一切”。
越核心的配置，越要有：

变更流程
灰度机制
回滚预案

3. 单机能跑不等于集群稳定

Nacos 自己也是一个分布式系统。
你要考虑：

节点数量
存储后端
网络连通性
监控告警
数据备份

建议的生产接入步骤

如果你准备把 Nacos 真正接到业务系统里，我建议按这个顺序推进：

第 1 阶段：开发环境验证

跑通单机版 Nacos
完成注册发现和配置拉取
验证动态刷新

第 2 阶段：测试环境规范化

统一 namespace/group/dataId 命名
开启鉴权
建立配置发布流程
引入变更审计

第 3 阶段：预生产压测

模拟服务实例扩缩容
模拟节点重启
模拟配置频繁变更
观察客户端恢复能力

第 4 阶段：生产灰度

先接入低风险服务
验证监控、告警、回滚链路
再逐步扩大范围

这个顺序看起来慢一点，但比“全量一把梭”稳很多。

总结

Nacos 之所以流行，不只是因为“能做注册中心和配置中心”，而是它把微服务里最基础、最高频的两类变化统一管理了：

服务实例变化
应用配置变化

你如果想真正掌握它，可以抓住三条主线：

理解原理
- 注册、心跳、摘除、订阅
- 长轮询、监听、刷新、本地缓存
跑通最小示例
- 一个 provider
- 一个 consumer
- 一份可动态刷新的配置
按生产标准补齐能力
- 鉴权
- 隔离
- 审计
- 集群
- 回滚
- 监控

最后给几个可执行建议，方便你落地：

新项目接入时，优先使用临时实例；
配置命名提前定规范，别等配置爆炸了再整理；
不要把所有动态配置都想成“立刻可热更新”；
生产环境必须开启鉴权和审计；
上线前一定做一次“配置误发布 + 快速回滚”的演练。

如果你把这几件事做好，Nacos 就不只是“会用”，而是真的能在生产环境里帮你扛住服务治理和配置管理的基本盘。

《从源码到生产：基于开源项目 Nacos 的服务注册与配置中心实战落地指南》

从源码到生产：基于开源项目 Nacos 的服务注册与配置中心实战落地指南

背景与问题

前置知识与环境准备

环境版本建议

核心原理

1. 服务注册与发现的工作流

2. 为什么 Nacos 要区分临时实例和持久化实例

临时实例 ephemeral=true

持久化实例 ephemeral=false

3. 心跳与健康检查机制

4. 配置中心为什么用长轮询

5. 从源码视角理解 Nacos 的两个关键点

Naming 侧关注点

Config 侧关注点

实战代码（可运行）

第一步：启动 Nacos

第二步：创建 Provider 服务

1. pom.xml

2. bootstrap.yml

3. ProviderApplication.java

4. HelloController.java

5. 在 Nacos 控制台添加配置

6. 启动服务

第三步：创建 Consumer 服务

1. pom.xml

2. application.yml

3. ConsumerApplication.java

4. CallController.java

5. 启动并验证

第四步：验证动态配置刷新

修改 Nacos 配置

逐步验证清单

注册中心验证

配置中心验证

上线前验证

生产落地：推荐的命名与隔离策略

namespace 按环境隔离

group 按业务域或团队分组

dataId 按服务名命名

常见坑与排查

1. 服务明明启动了，但 Nacos 控制台看不到实例

常见原因

排查方法

2. Consumer 调用报 No instances available for provider-service

常见原因

排查方法

3. 配置修改后不生效

常见原因

正确示例

额外提醒

4. 本地好好的，生产集群频繁掉线

常见原因

排查建议

5. 配置误发布导致线上故障

止血建议

安全/性能最佳实践

安全最佳实践

1. 一定开启鉴权

2. 按 namespace/group 做权限隔离

3. 敏感配置不要明文裸奔

4. 配置变更必须可审计

性能最佳实践

1. 不要把 Nacos 当数据库用

2. 控制配置粒度

3. 多实例订阅时关注推送风暴

4. Nacos 集群至少三节点

一个典型生产部署示意

从源码到生产的关键理解：别把“能跑”当“可用”

1. 注册成功不等于调用可靠

2. 配置可刷新不等于可以随便改

3. 单机能跑不等于集群稳定

建议的生产接入步骤

第 1 阶段：开发环境验证

第 2 阶段：测试环境规范化

第 3 阶段：预生产压测

第 4 阶段：生产灰度

总结

临时实例 `ephemeral=true`

持久化实例 `ephemeral=false`

1. `pom.xml`

2. `bootstrap.yml`

3. `ProviderApplication.java`

4. `HelloController.java`

1. `pom.xml`

2. `application.yml`

3. `ConsumerApplication.java`

4. `CallController.java`

2. Consumer 调用报 `No instances available for provider-service`