## 一、Eureka宕机让我们全站瘫痪

2019年双十一后的凌晨3点，我接到告警电话：订单服务大面积超时。

登上服务器一看，Eureka Server的进程不见了。查看日志，发现是内存泄漏导致OOM崩溃。

虽然Eureka有客户端缓存机制，但问题在于：
- 我们的Eureka Client配置的`registryFetchIntervalSeconds=30s`
- 缓存有效期只有30秒，过期后客户端需要重新拉取
- Eureka Server挂了，拉取失败，本地缓存变空
- 所有服务发现调用返回空列表，RPC调用开始大面积失败

更悲剧的是，我们的熔断器配置了"当实例数为0时直接熔断"，导致整个服务链路瞬间熔断，用户下单全部失败。

**故障复盘时我们意识到：**

> Eureka的AP模型虽然保证了可用性，但牺牲了一致性。当Eureka Server宕机后，客户端缓存的过期策略反而成了故障扩散的原因。

从那以后，我们开始重新评估注册中心的选型，最终迁移到了Nacos。

---

## 二、注册中心对比

```
┌─────────────────────────────────────────────────────────────────┐
│                  注册中心对比                                      │
│                                                                  │
│  特性        │ Eureka     │ Nacos      │ Consul     │ ZooKeeper │
│  ─────────────────────────────────────────────────────────────  │
│  CAP        │ AP         │ AP/CP      │ CP         │ CP        │
│  健康检查    │ 客户端心跳 │ 心跳+TCP   │ Agent+HTTP │ 会话      │
│  配置中心    │ 否         │ 是         │ 是(KV)     │ 否        │
│  雪崩保护    │ 是         │ 是         │ 否         │ 否        │
│  自动注销    │ 否(等过期) │ 是         │ 是         │ 是        │
│  一致性协议  │ 无         │ Distro/Raft│ Raft       │ ZAB       │
│  K8s集成    │ 否         │ 是         │ 是         │ 否        │
│  管理界面    │ 简陋       │ 完善       │ 完善       │ 无        │
│  社区活跃    │ 停更       │ 活跃       │ 活跃       │ 活跃      │
│                                                                  │
└──────────────────────────────────────────────────────────────────┘
```

### 2.1 Eureka的优缺点

**优点：**
- Spring Cloud原生支持，开箱即用
- AP模型，保证可用性
- 简单易用，学习成本低

**缺点：**
- **已停止维护**（2.x版本官方宣布不再开源）
- 只支持AP，不适合强一致性场景
- 管理界面简陋，排查问题困难
- 健康检查依赖客户端心跳，不够精准

### 2.2 Nacos的优缺点

**优点：**
- 同时支持AP和CP模式，可切换
- 集成配置中心，一石二鸟
- 管理界面完善，服务治理方便
- 阿里开源，社区活跃，国内生态好
- 支持DNS协议，K8s集成友好

**缺点：**
- 功能多意味着复杂度高
- 配置项繁多，需要理解透彻
- 集群部署相对复杂

### 2.3 Consul的优缺点

**优点：**
- CP模型，强一致性
- 自带服务网格（Connect）
- 支持多数据中心
- K8s集成原生支持

**缺点：**
- 需要部署Agent，运维成本高
- 国内社区相对小众
- 配置中心能力较弱（只有KV）

### 2.4 ZooKeeper的优缺点

**优点：**
- CP模型，强一致性
- 成熟稳定，久经考验
- Hadoop/Kafka等大数据生态默认选择

**缺点：**
- 不是专门的服务发现组件，使用复杂
- 无管理界面，调试困难
- 性能较差，不适合大规模服务

---

## 三、Nacos实战

### 3.1 服务注册

```java
/**
 * Nacos服务注册配置
 */
@Configuration
public class NacosRegisterConfig {
    
    @Bean
    @LoadBalanced
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

# bootstrap.yml
spring:
  application:
    name: order-service
  cloud:
    nacos:
      discovery:
        server-addr: nacos:8848
        namespace: production
        group: DEFAULT_GROUP
        cluster-name: HZ
        weight: 1
        metadata:
          version: v2
          region: hangzhou
```

### 3.2 服务发现

```java
/**
 * 服务发现使用
 */
@Service
@Slf4j
public class ServiceDiscoveryService {
    
    @Autowired
    private DiscoveryClient discoveryClient;
    
    @Autowired
    private NacosServiceManager nacosServiceManager;
    
    /**
     * 获取服务实例
     */
    public List<ServiceInstance> getInstances(String serviceId) {
        return discoveryClient.getInstances(serviceId);
    }
    
    /**
     * 获取所有服务
     */
    public List<String> getServices() {
        return discoveryClient.getServices();
    }
    
    /**
     * 订阅服务变更
     */
    public void subscribe(String serviceId, EventListener listener) {
        nacosServiceManager.getNamingService().subscribe(
            serviceId, 
            event -> {
                if (event instanceof NamingEvent) {
                    NamingEvent namingEvent = (NamingEvent) event;
                    log.info("服务变更: service={}, instances={}", 
                        serviceId, namingEvent.getInstances().size());
                }
            }
        );
    }
}
```

### 3.3 Nacos配置中心

```java
/**
 * Nacos配置中心使用
 */
@Service
@Slf4j
public class NacosConfigService {
    
    /**
     * 动态配置
     */
    @NacosValue(value = "${order.max-retry:3}", autoRefreshed = true)
    private int maxRetry;
    
    /**
     * 配置变更监听
     */
    @NacosConfigListener(dataId = "order-service.properties", groupId = "DEFAULT_GROUP")
    public void onConfigChange(String newConfig) {
        log.info("配置变更: {}", newConfig);
        // 刷新本地配置
    }
}
```

### 3.4 集群部署配置

```bash
# Nacos集群配置 cluster.conf
192.168.1.1:8848
192.168.1.2:8848
192.168.1.3:8848

# 使用MySQL存储（生产环境必须）
spring.datasource.platform=mysql
db.num=1
db.url.0=jdbc:mysql://mysql:3306/nacos?characterEncoding=utf8&connectTimeout=1000&socketTimeout=3000&autoReconnect=true&useUnicode=true&useSSL=false&serverTimezone=UTC
db.user.0=nacos
db.password.0=nacos
```

---

## 四、踩坑实录

### 坑1：临时实例vs持久实例

> **问题**：Nacos默认使用临时实例（ephemeral=true），靠心跳保活。服务假死时心跳线程可能还在运行，注册中心不会剔除，流量打到假死实例上。

**踩坑场景**：
我们有个服务因为死锁卡住了，但心跳线程还在，Nacos认为服务健康，继续把流量打过去，导致大量请求超时。

**解决方案**：
```yaml
spring:
  cloud:
    nacos:
      discovery:
        # 配置健康检查
        heart-beat-interval: 5000  # 心跳间隔5秒
        heart-beat-timeout: 15000  # 心跳超时15秒
        # 或者使用持久实例
        ephemeral: false
```

### 坑2：注册信息不完整

> **问题**：只注册了IP和端口，没注册权重、版本等元数据，导致灰度路由失败。

**踩坑场景**：
我们要做灰度发布，按版本号路由流量，结果发现服务实例没有注册version元数据，灰度规则全部失效。

**解决方案**：
```yaml
spring:
  cloud:
    nacos:
      discovery:
        metadata:
          version: v2.0.0
          region: hangzhou
          env: gray
          weight: 80
```

### 坑3：注册中心集群脑裂

> **问题**：Nacos集群网络分区，出现两个Leader，服务注册信息不一致。

**踩坑场景**：
机房网络抖动，Nacos集群出现脑裂，不同客户端看到的服务列表不一致，导致请求时好时坏。

**解决方案**：
```properties
# 切换到CP模式（强一致性）
nacos.core.protocol.raft.data.enabled=true

# 增加选举超时时间
nacos.core.protocol.raft.data.election-timeout-ms=5000
```

### 坑4：服务下线不优雅

> **问题**：服务直接kill，注册中心等心跳超时才剔除，期间请求还在打到已下线的实例。

**踩坑场景**：
发布时直接kill进程，客户端还在调用下线实例，报大量连接拒绝错误。

**解决方案**：
```java
@Bean
public GracefulShutdown gracefulShutdown() {
    return new GracefulShutdown();
}

// 或使用Spring Boot的优雅关闭
server:
  shutdown: graceful
spring:
  lifecycle:
    timeout-per-shutdown-phase: 30s
```

### 坑5：Nacos写入压力

> **问题**：1000个服务同时上线，Nacos写入压力大，出现写入延迟。

**踩坑场景**：
凌晨批量发布，几百个服务同时启动注册，Nacos扛不住，注册延迟长达30秒，导致服务启动后找不到依赖。

**解决方案**：
- 分批上线，错峰启动
- 增加Nacos集群节点
- 调整写入批处理参数

### 坑6：命名空间隔离不彻底

> **问题**：以为用了namespace就能完全隔离，结果配置还是串了。

**踩坑场景**：
我们用namespace区分dev/test/prod环境，但有个服务的配置没指定namespace，默认用了public，结果覆盖了其他环境的配置。

**解决方案**：
```yaml
spring:
  cloud:
    nacos:
      discovery:
        namespace: ${NACOS_NAMESPACE:public}
      config:
        namespace: ${NACOS_NAMESPACE:public}
```

---

## 五、选型建议

### 5.1 按场景选型

| 场景 | 推荐方案 | 理由 |
|------|----------|------|
| Spring Cloud生态 | **Nacos** | 无缝集成，功能全面 |
| Kubernetes原生 | **Consul** | 原生支持，多数据中心 |
| 简单Demo项目 | Eureka | 开箱即用（但不推荐生产） |
| 强一致性要求 | **ZooKeeper** | CP模型，金融场景 |
| 国内团队 | **Nacos** | 中文文档，社区活跃 |

### 5.2 最佳实践

1. **优先选择Nacos**（功能完善、社区活跃、国内生态好）
2. **注册时携带完整元数据**（版本、区域、权重、环境等）
3. **配置合理的健康检查**（心跳间隔、超时时间、健康检查URL）
4. **优雅上下线**（主动注销、优雅关闭、预热）
5. **做好注册中心监控**（服务数量、实例健康率、注册延迟）
6. **多环境隔离**（使用namespace隔离dev/test/prod）
7. **集群部署**（至少3节点，使用MySQL存储）

---

## 六、血的教训

> **注册中心是微服务的基础设施，选型要慎重。**

我们当初从Eureka迁移到Nacos，花了整整两周：
- 改造所有服务的注册配置
- 迁移配置中心
- 重新设计灰度发布流程
- 全链路测试

迁移成本极高，选型时一定要考虑长远。

> **Eureka已经停止维护了，新项目千万别用。**

---

## 七、思考题

1. 你的系统用了什么注册中心？选型时考虑了哪些因素？
2. 遇到过注册中心故障吗？怎么解决的？
3. 你认为注册中心最重要的是什么？可用性还是一致性？

---

*个人观点，仅供参考*

登上服务器一看，Eureka Server的进程不见了。查看日志，发现是内存泄漏导致OOM崩溃。

【架构实战】注册中心选型：Nacos vs Eureka vs Consul

研发部经理

架构设计

开发工具

后端

Eureka宕机导致全站瘫痪，注册中心选型至关重要。Nacos支持AP/CP模式，集成配置中心，管理界面完善，适合国内团队。Consul强一致性，ZooKeeper成熟稳定但复杂。迁移注册中心成本高，建议优先选择Nacos，注意健康检查、优雅上下线、多环境隔离等最佳实践。

数据中心

服务网格

Kubernetes

服务器

大数据

Hadoop 

路由

MySQL

Kafka

Agent

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

【架构实战】注册中心选型：Nacos vs Eureka vs Consul-腾讯云开发者社区-腾讯云

【架构实战】注册中心选型：Nacos vs Eureka vs Consul

【架构实战】注册中心选型：Nacos vs Eureka vs Consul

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐