🗺️ 服务注册与发现：Eureka、Nacos、Consul大对比

面试官：服务注册与发现了解吗？
候选人：用过Eureka...
面试官：Eureka和Nacos有什么区别？为什么现在大家都用Nacos？
候选人：😰💦（这...）

别慌！今天我们深入对比三大服务注册中心的原理和特性！

---

🎬 第一章：为什么需要服务注册与发现？

单体应用时代

用户 → Nginx → 应用服务器（固定IP:端口）

配置：
upstream backend {
    server 192.168.1.100:8080;
}

问题：IP地址写死，不灵活

微服务时代

用户 → 网关 → 订单服务(?)
              → 商品服务(?)
              → 用户服务(?)

问题：
1. 服务实例动态变化（扩缩容）
2. IP地址不固定（容器化、云环境）
3. 服务数量多（几十上百个）
4. 如何知道服务的地址？

🎭 生活比喻：电话簿

传统方式（写死IP）：
- 记住每个朋友的电话号码
- 朋友换号了，你打不通 ❌

服务注册中心（电话簿）：
- 朋友换号后，更新电话簿 ✅
- 你打电话前，先查电话簿
- 朋友不在线，电话簿会告诉你

类比：
服务 = 朋友
IP:端口 = 电话号码
注册中心 = 电话簿
健康检查 = 确认朋友在不在

---

🌸 第二章：Eureka - Netflix的经典之作

架构原理

┌─────────────────────────────────────────┐
│         Eureka Server（注册中心）          │
│                                          │
│  ┌────────────────────────────────┐     │
│  │   服务注册表                    │     │
│  │   - 订单服务: [实例1, 实例2]    │     │
│  │   - 商品服务: [实例1, 实例2]    │     │
│  └────────────────────────────────┘     │
└─────────────────────────────────────────┘
         ↑ 注册              ↑ 拉取
         │                   │
    ┌────┴────┐         ┌───┴─────┐
    │ 订单服务 │         │ 网关服务 │
    └─────────┘         └─────────┘

核心特性

1️⃣ AP模型（可用性优先）

CAP定理：
- C (一致性)：所有节点数据一致
- A (可用性)：每个请求都有响应
- P (分区容错)：网络分区时仍能工作

Eureka选择：AP（牺牲一致性，保证可用性）

场景：
Eureka Server A：订单服务有3个实例
Eureka Server B：订单服务有2个实例（网络延迟，还没同步）

客户端：可能拿到不同的实例列表，但服务不会中断 ✅

2️⃣ 自我保护机制

问题：网络抖动导致心跳丢失

普通做法：
心跳丢失 → 剔除服务 → 可能误杀大量正常服务 ❌

Eureka做法：
15分钟内心跳失败比例 > 85% 
→ 触发自我保护模式
→ 不剔除任何服务
→ 宁可保留错误信息，也不误杀 ✅

3️⃣ 三级缓存

ReadOnlyCacheMap（只读缓存）
    ↓ 每30秒同步
ReadWriteCacheMap（读写缓存）
    ↓ 实时更新
Registry（注册表）

好处：
- 减少Registry压力
- 提升读取性能

坏处：
- 最多30秒延迟（最终一致性）

💻 代码示例

Eureka Server

// pom.xml
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-server</artifactId>
</dependency>

// application.yml
server:
  port: 8761

eureka:
  instance:
    hostname: localhost
  client:
    register-with-eureka: false  # 自己不注册到Eureka
    fetch-registry: false         # 不拉取注册信息
  server:
    enable-self-preservation: true  # 开启自我保护
    eviction-interval-timer-in-ms: 60000  # 清理间隔60秒

// 启动类
@SpringBootApplication
@EnableEurekaServer
public class EurekaServerApplication {
    public static void main(String[] args) {
        SpringApplication.run(EurekaServerApplication.class, args);
    }
}

Eureka Client

// pom.xml
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
</dependency>

// application.yml
spring:
  application:
    name: order-service  # 服务名

eureka:
  client:
    service-url:
      defaultZone: http://localhost:8761/eureka/  # 注册中心地址
  instance:
    prefer-ip-address: true  # 使用IP注册
    lease-renewal-interval-in-seconds: 30  # 心跳间隔30秒
    lease-expiration-duration-in-seconds: 90  # 90秒未心跳则剔除

// 启动类
@SpringBootApplication
@EnableDiscoveryClient
public class OrderServiceApplication {
    public static void main(String[] args) {
        SpringApplication.run(OrderServiceApplication.class, args);
    }
}

// 使用服务发现
@RestController
public class OrderController {
    
    @Autowired
    private DiscoveryClient discoveryClient;
    
    @GetMapping("/services")
    public List<String> getServices() {
        // 获取所有服务名
        return discoveryClient.getServices();
    }
    
    @GetMapping("/instances/{serviceName}")
    public List<ServiceInstance> getInstances(@PathVariable String serviceName) {
        // 获取指定服务的所有实例
        return discoveryClient.getInstances(serviceName);
    }
}

⚖️ 优缺点

✅ 优点

1. 成熟稳定：Netflix生产验证
2. 自我保护：网络抖动不误杀
3. 简单易用：Spring Cloud生态

❌ 缺点

1. 只支持Java：其他语言不友好
2. AP模型：数据可能不一致
3. 已停更：Eureka 2.x停止开发

---

🔵 第三章：Nacos - 阿里的新星

架构原理

┌──────────────────────────────────────────┐
│          Nacos Server                     │
│                                           │
│  ┌────────────┐  ┌──────────────┐       │
│  │ 服务注册表  │  │  配置管理     │       │
│  └────────────┘  └──────────────┘       │
│                                           │
│  支持：临时实例（AP）+ 持久化实例（CP）    │
└──────────────────────────────────────────┘
         ↑                        ↑
         │ 注册/配置              │
    ┌────┴────┐            ┌─────┴─────┐
    │ 订单服务 │            │  网关服务  │
    └─────────┘            └───────────┘

核心特性

1️⃣ 双模型（AP + CP）

// 临时实例（AP模型）- 默认
@NacosInjected
private NamingService namingService;

namingService.registerInstance("order-service", "192.168.1.1", 8080);
// 需要定期发送心跳，否则自动注销
// 适合：微服务（实例动态变化）

// 持久化实例（CP模型）
namingService.registerInstance("order-service", "192.168.1.1", 8080, false);
// 不需要心跳，手动注销才删除
// 适合：数据库、中间件（实例固定）

2️⃣ 配置管理

# Nacos既是注册中心，又是配置中心！

# bootstrap.yml
spring:
  application:
    name: order-service
  cloud:
    nacos:
      config:
        server-addr: 127.0.0.1:8848
        namespace: dev  # 环境隔离
        group: DEFAULT_GROUP
        file-extension: yml
      discovery:
        server-addr: 127.0.0.1:8848

// 动态配置刷新
@RestController
@RefreshScope  // 关键注解！
public class ConfigController {
    
    @Value("${app.max-connections:100}")
    private int maxConnections;
    
    @GetMapping("/config")
    public int getConfig() {
        // Nacos配置变化时，自动刷新
        return maxConnections;
    }
}

3️⃣ 健康检查模式

客户端上报（临时实例）：
客户端 → 定期发送心跳 → Nacos
优点：Nacos压力小
缺点：客户端故障无法上报

服务端探测（持久化实例）：
Nacos → 定期健康检查 → 服务
优点：更准确
缺点：Nacos压力大

💻 代码示例

// pom.xml
<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>

// application.yml
spring:
  application:
    name: order-service
  cloud:
    nacos:
      discovery:
        server-addr: 127.0.0.1:8848
        namespace: dev
        group: DEFAULT_GROUP
        ephemeral: true  # 临时实例（默认）
        heart-beat-interval: 5000  # 心跳间隔5秒
        
// 使用服务发现
@Service
public class OrderService {
    
    @Autowired
    private RestTemplate restTemplate;
    
    @Autowired
    private LoadBalancerClient loadBalancer;
    
    public String createOrder() {
        // 方式1：通过LoadBalancerClient手动选择实例
        ServiceInstance instance = loadBalancer.choose("product-service");
        String url = String.format("http://%s:%d/product/1", 
            instance.getHost(), instance.getPort());
        
        // 方式2：使用@LoadBalanced的RestTemplate（推荐）
        String url2 = "http://product-service/product/1";
        return restTemplate.getForObject(url2, String.class);
    }
}

// RestTemplate配置
@Configuration
public class RestTemplateConfig {
    
    @Bean
    @LoadBalanced  // 关键注解：启用负载均衡
    public RestTemplate restTemplate() {
        return new RestTemplate();
    }
}

⚖️ 优缺点

✅ 优点

1. 功能全面：注册中心+配置中心
2. 双模型：AP和CP可选
3. 支持多语言：Java、Go、Python等
4. 动态配置：实时推送配置变更
5. 持续更新：阿里维护

❌ 缺点

1. 相对年轻：生态不如Eureka成熟
2. 学习曲线：功能多，配置复杂

---

🏛️ 第四章：Consul - HashiCorp的全能选手

架构原理

┌────────────────────────────────────────┐
│        Consul Server Cluster            │
│                                         │
│  ┌──────┐  ┌──────┐  ┌──────┐         │
│  │Server│  │Server│  │Server│  (Raft) │
│  └──────┘  └──────┘  └──────┘         │
│                                         │
│  功能：                                 │
│  - 服务注册                             │
│  - 健康检查                             │
│  - KV存储                               │
│  - 多数据中心                           │
└────────────────────────────────────────┘
         ↑                       ↑
         │                       │
    ┌────┴────┐             ┌───┴─────┐
    │Consul   │             │Consul   │
    │Agent    │             │Agent    │
    └────┬────┘             └────┬────┘
         │                       │
    ┌────┴────┐             ┌───┴─────┐
    │订单服务  │             │商品服务  │
    └─────────┘             └─────────┘

核心特性

1️⃣ CP模型（一致性优先）

基于Raft协议：
- 保证强一致性
- Leader选举
- 日志复制

场景：
网络分区时，少数派节点不可用
→ 保证数据一致性 ✅
→ 牺牲可用性

2️⃣ 多数据中心

数据中心A（北京）    数据中心B（上海）
   Consul Cluster      Consul Cluster
        ↓                     ↓
    订单服务              订单服务

支持：
- 跨数据中心服务发现
- 多数据中心配置同步

3️⃣ 健康检查丰富

支持多种健康检查：
1. HTTP检查：GET /health
2. TCP检查：检测端口连通性
3. gRPC检查：gRPC health protocol
4. Script检查：执行自定义脚本
5. Docker检查：检查容器状态

💻 代码示例

// pom.xml
<dependency>
    <groupId>org.springframework.cloud</groupId>
    <artifactId>spring-cloud-starter-consul-discovery</artifactId>
</dependency>

// application.yml
spring:
  application:
    name: order-service
  cloud:
    consul:
      host: localhost
      port: 8500
      discovery:
        enabled: true
        instance-id: ${spring.application.name}:${random.value}
        service-name: ${spring.application.name}
        health-check-interval: 10s  # 健康检查间隔
        health-check-path: /actuator/health
        health-check-critical-timeout: 30s

// 健康检查端点
@RestController
public class HealthController {
    
    @GetMapping("/actuator/health")
    public Map<String, String> health() {
        return Map.of("status", "UP");
    }
}

⚖️ 优缺点

✅ 优点

1. 强一致性：CP模型，数据可靠
2. 功能丰富：服务网格、KV存储
3. 多语言支持：HTTP API
4. 多数据中心：天然支持

❌ 缺点

1. 复杂度高：部署运维复杂
2. 性能较低：强一致性牺牲性能
3. 不适合大规模：节点过多时性能下降

---

📊 第五章：三者对比

对比表

维度	Eureka	Nacos	Consul
CAP模型	AP	AP+CP可选	CP
一致性协议	-	Distro(AP)/Raft(CP)	Raft
健康检查	客户端心跳	客户端心跳+服务端探测	多种方式
负载均衡	Ribbon	Ribbon/自带	Fabio
配置中心	❌	✅	✅(KV)
多语言	❌(仅Java)	✅	✅
Spring Cloud	✅原生	✅	✅
界面	简陋	美观强大	美观
学习曲线	简单	中等	复杂
社区活跃度	低(已停更)	高	中

性能对比

QPS测试（10万服务实例）：

Eureka:  6000 QPS
Nacos:   15000 QPS (临时实例)
Consul:  3000 QPS

结论：Nacos性能最好 ✅

选型建议

graph TD
    A[开始选型] --> B{需要强一致性?}
    B -->|是| C[选择Consul]
    B -->|否| D{需要配置中心?}
    D -->|是| E{Spring Cloud生态?}
    D -->|否| F{已有Eureka?}
    E -->|是| G[选择Nacos]
    E -->|否| C
    F -->|是| H[继续用Eureka]
    F -->|否| G

---

💼 第六章：实战经验

场景1：服务优雅下线

@RestController
public class ShutdownController {
    
    @Autowired
    private DiscoveryClient discoveryClient;
    
    @PreDestroy
    public void gracefulShutdown() {
        // 1. 先从注册中心注销
        if (discoveryClient instanceof EurekaDiscoveryClient) {
            EurekaDiscoveryClient client = (EurekaDiscoveryClient) discoveryClient;
            client.shutdown();
        }
        
        // 2. 等待30秒，让调用方感知
        try {
            Thread.sleep(30000);
        } catch (InterruptedException e) {
            Thread.currentThread().interrupt();
        }
        
        // 3. 停止接收新请求
        // 4. 等待现有请求处理完
    }
}

场景2：多环境隔离

# Nacos命名空间隔离

开发环境: namespace=dev
测试环境: namespace=test
生产环境: namespace=prod

配置：
spring:
  cloud:
    nacos:
      discovery:
        namespace: ${ENV:dev}  # 环境变量控制

场景3：灰度发布

// Nacos支持元数据
spring:
  cloud:
    nacos:
      discovery:
        metadata:
          version: v2  # 版本标识
          region: beijing  # 地域标识

// 自定义负载均衡规则
@Component
public class VersionLoadBalancer implements ReactorLoadBalancer<ServiceInstance> {
    
    @Override
    public Mono<Response<ServiceInstance>> choose(Request request) {
        // 优先选择相同版本的实例
        String targetVersion = request.getContext().toString();
        
        List<ServiceInstance> instances = // 获取实例列表
        
        return instances.stream()
            .filter(i -> targetVersion.equals(i.getMetadata().get("version")))
            .findFirst()
            .map(Response::new)
            .orElse(new EmptyResponse());
    }
}

---

🎓 第七章：面试高分回答

问题：Eureka、Nacos、Consul有什么区别？

标准回答：

"这三个都是服务注册中心，但各有特点：

Eureka（Netflix）：

• CAP模型：AP（可用性优先）
• 自我保护机制，防止网络抖动误杀
• 只支持Java，已停止更新
• 适合：对一致性要求不高的场景

Nacos（阿里）：

• CAP模型：AP+CP可选
• 临时实例（AP）：客户端心跳，适合微服务
• 持久化实例（CP）：服务端探测，适合数据库
• 同时支持配置中心
• 性能最好（15000 QPS）
• 适合：大多数场景，是我们的首选

Consul（HashiCorp）：

• CAP模型：CP（一致性优先）
• 基于Raft协议，强一致性
• 支持多数据中心
• 功能丰富，但复杂度高
• 适合：对数据一致性要求高的场景

我们项目的选择： 从Eureka迁移到了Nacos，因为：

1. Eureka已停更
2. Nacos功能更强大（配置中心）
3. 性能更好
4. 支持多语言"

常见追问

Q1：Nacos的AP和CP模式如何切换？

A：通过ephemeral参数控制：
- ephemeral=true：临时实例，AP模式（默认）
- ephemeral=false：持久化实例，CP模式

临时实例：客户端心跳，适合微服务（动态扩缩容）
持久化实例：服务端探测，适合固定服务（数据库、中间件）

Q2：为什么Eureka性能不如Nacos？

A：
1. 三级缓存：Eureka有30秒延迟
2. 全量拉取：客户端定期拉取全部服务列表
3. 架构老旧：代码较老，优化不够

Nacos优化：
1. 增量推送：只推送变化的服务
2. 客户端缓存：减少网络调用
3. 异步处理：使用Netty异步框架

---

🎁 总结

一句话记住

• Eureka：老牌稳重，已退休 👴
• Nacos：年轻力壮，全能王 💪
• Consul：严谨可靠，高门槛 🎓

---

祝你面试顺利！💪✨