---
tags: [arch/microservice, service-discovery, eureka, nacos, consul, cap-theory, health-check]
create time: 2026-08-08 18:00
update time: 2026-08-08 18:00
---

# 服务注册与发现

## 概述

服务注册与发现是微服务架构的基石。当服务实例动态扩缩容时，调用方需要知道"当前谁在提供服务"以及"它们在哪"。本文对比 Eureka、Nacos、Consul 三大主流方案的核心设计差异，分析 CAP 理论在服务注册中心中的取舍，以及健康检查的各种实现方式。

## 核心原理

### 服务注册/注销/续约流程

```mermaid
sequenceDiagram
    participant Client as 客户端
    participant Server as 服务提供者
    participant Registry as 注册中心
    participant Discover as 消费方
    Client->>Server: 启动服务
    Server->>Registry: 1. 注册服务 (POST /register)
    Registry-->>Server: 注册成功
    Server->>Registry: 2. 心跳续约 (POST /heartbeat)
    Registry->>Registry: 更新 lastDirtyTimestamp
    loop 每 N 秒
        Server->>Registry: 心跳续约
        Registry-->>Server: ACK
    end
    Discover->>Registry: 3. 查询服务列表 (GET /instances)
    Registry-->>Discover: 返回健康实例列表
    Discover->>Server: 发起 RPC 调用
    Note over Server: 服务关闭
    Server->>Registry: 4. 主动注销 (DELETE /deregister)
    Registry-->>Server: 注销成功
    Registry->>Registry: 从服务列表中移除
```

**三步走**：注册 → 续约（或心跳）→ 注销。绝大多数故障场景下，调用方感知到服务宕机会延迟一个续约超时周期（通常 30~90 秒）。

### Eureka — AP 取向的自我修复

Eureka 是 Netflix 开源的方案，设计上严格遵循 **AP（可用性 + 分区容错性）**：

- **双副本架构**：Peer Replication 机制将数据异步同步给所有节点，不同步视为正常而非故障。
- **自我保护机制**：当 15 分钟内超过 85% 实例未发送心跳，Eureka 锁定保护窗口，不再剔除任何实例。这意味着被误判为宕机的实例仍会出现在服务列表中——宁可多调几次再失败，也不主动剔除。
- **客户端缓存**：消费者缓存服务列表（默认每 30 秒刷新），即使注册中心完全不可用，消费方依然能根据本地缓存继续通信。

```java
// Eureka 自我保护机制触发条件
public boolean shouldEnableRenewments() {
    double threshold = registry.getRenewalThreshold(); // 85%
    if (serverConfig.isSelfPreservationEnabled()
            && registry.getCachedInstanceStatus().equals(HEAVY_OVERLOAD)) {
        return true; // 进入自我保护，允许续约
    }
    return super.shouldEnableRenewments();
}
```

> [!WARNING]
> 自我保护机制在生产环境是个双刃剑：它保证了高可用，但可能导致流量打向已宕机的实例。建议监控 `eureka.server.selfPreservationThreshold` 指标。

### Nacos — CP/AP 可切换的统一平台

Nacos 解决了 Eureka 和 ZooKeeper 只能二选一的问题：

| 模式 | 适用场景 | 一致性协议 | 典型部署形态 |
|------|---------|-----------|------------|
| AP 模式 | 服务注册发现 | Distro 协议（自研，类似 Eureka 的双写） | 集群部署 |
| CP 模式 | 配置管理 | Raft 协议 | 奇数节点集群 |

**统一命名空间管理**：Nacos 通过 `namespace` 实现环境隔离（dev/test/prod），每个命名空间有独立的服务和配置视图。底层基于 PostgreSQL 存储元数据，天然支持持久化。

```go
// Nacos Go SDK 服务订阅示例
client, _ := nacos.NewClient(nacos.Config{
    ServerAddr: "127.0.0.1:8848",
    NamespaceId: "prod-ns",
})

info, _ := client.Subscribe(&nacos.Subscriber{
    ServiceName: "user-service",
    Cluster:     "DEFAULT",
    OnEvent: func(event *nacos.Event) {
        for _, inst := range event.Hosts {
            fmt.Println(inst.InstanceIp, inst.InstancePort)
        }
    },
})
```

> [!TIP]
> 面试常考点：为什么 Nacos 能在同一套代码中既做 AP 又做 CP？答：两种模式使用不同的数据存储路径和服务类型——`nacos.v1.auth.user`（CP，Raft）与 `nacos.v1.instance`（AP，Distro）。

### Consul — Serf Gossip + 丰富健康检查

HashiCorp 出品的 Consul 有三个独特优势：

1. **Serf  gossip 协议**：基于 WAN Gossip 的成员管理，相比 TCP 直连更容错。节点通过 pull-based push-based 混合机制传播成员变更。
2. **丰富的健康检查**：支持 TCP、HTTP、HTTP Body、docker、脚本五种检查方式。还支持 TTL（手动报告状态）模式。
3. **KV 存储能力**：内嵌 Raft 一致性 KV 存储，可用于配置管理、分布式锁等辅助场景。

```go
// Consul HTTP 健康检查配置
func registerCheck() *api.AgentServiceCheck {
    return &api.AgentServiceCheck{
        HTTP:                          "http://localhost:8080/health",
        Timeout:                       "5s",
        Interval:                      "10s",
        DeregisterCriticalServiceAfter: "90s",
    }
}
```

### CAP 理论在服务注册中心的体现

| 注册中心 | CAP 选择 | 网络分区时的行为 | 数据一致性保证 |
|---------|---------|-----------------|--------------|
| Eureka | AP | 各节点独立响应，可能返回过期数据 | 最终一致 |
| Nacos (AP) | AP | Distro 协议异步复制，容忍短暂不一致 | 最终一致 |
| Nacos (CP) | CP | 选出 Leader 后响应，部分节点不可用时降级 | 强一致 |
| Consul | CP（TCP）/ AP（DNS） | Raft Leader 不可达时无法写入 | 读可能 stale |

> [!NOTE]
> PACELC 补充：CAP 只讨论网络分区场景。PACELC 指出：无分区时，延迟（Latency）与一致性（Consistency）仍需权衡。Nacos AP 模式、Eureka 都是选择了低延迟而非强一致。

### 健康检查方式对比

| 方式 | 原理 | 优点 | 缺点 |
|------|-----|------|------|
| TCP | 尝试建立 TCP 连接 | 轻量、通用 | 无法感知应用层故障 |
| HTTP/HTTPS | 请求指定 endpoint 检查状态码 | 灵活，可携带业务逻辑 | 增加服务器负载 |
| gRPC | gRPC Health Checking Protocol | 适合 gRPC 服务 | 需额外 proto 定义 |
| Script | 执行自定义脚本 | 最灵活，可做深度检查 | 维护成本高 |
| Edge探测 | 模拟真实用户请求 | 最贴近用户体验 | 复杂度高，一般用于 SLA 监控 |

## 代码示例

以下是一个简化版的 Go 服务注册中心心跳续约逻辑：

```go
type Heartbeat struct {
    ServiceID   string
    InstanceID  string
    LastPingAt  time.Time
}

type Registry struct {
    instances map[string]*Instance // serviceID -> Instance
    mu        sync.RWMutex
}

// Register 注册一个新实例
func (r *Registry) Register(svc, instanceID, addr string) error {
    r.mu.Lock()
    defer r.mu.Unlock()
    if _, ok := r.instances[svc]; !ok {
        r.instances[svc] = &Instance{Addr: addr}
    }
    return nil
}

// Renew 续约：更新最后心跳时间
func (r *Registry) Renew(svc, instanceID string) bool {
    r.mu.Lock()
    defer r.mu.Unlock()
    inst, ok := r.instances[svc]
    if !ok {
        return false
    }
    inst.LastHeartbeat = time.Now()
    return true
}
```

## 实践场景

**秋招高频问题：**

- "Eureka 的自我保护机制什么时候该关？" — 答案：金融类对一致性要求高的场景可以考虑关闭，普通互联网业务不建议关。关了之后可能出现"雪崩式下线"——一批实例同时被认为是故障而全部剔除。
- "Nacos 和 Eureka 有什么本质区别？" — Eureka 只管服务发现，Nacos 是一体化平台（服务发现 + 配置中心）。Nacos 还能按 namespace/group/key 精确分组配置。
- "Consul 的 DNS 接口为什么是 AP 模式？" — DNS 本身是无状态的，Consul 的 DNS API 直接指向随机节点读取本地内存缓存，不经过 Raft 日志，因此速度极快但可能读到旧数据。

**实战建议：** 小团队用一个 Nacos 集群就够用；大规模多机房场景考虑 Consul 的多数据中心能力。

## 关联笔记

- [[负载均衡算法]]
- [[限流熔断降级]]
- [[配置中心设计]]