背景与问题

在单体应用时代，服务地址通常写在配置文件里，改一次重启一次，虽然笨，但问题边界清晰。进入集群架构后，事情就完全不一样了：实例会扩缩容、容器 IP 会漂移、节点会临时故障、机房链路会抖动。“服务在哪” 和 “流量该怎么走”，从配置问题变成了系统设计问题。

很多线上故障，表面看是“调用超时”或者“偶发 502”，本质上却是下面这些典型问题之一：

• 注册中心里残留了失效实例，客户端还在继续打流量
• 服务发现有延迟，扩容成功了但流量迟迟打不过去
• 流量治理策略过于激进，触发了错误的熔断或限流
• 某个热点实例被打满，其他实例却很空闲
• 下游故障没有被隔离，导致线程池、连接池被拖死，形成级联雪崩

我自己做排障时，最常见的误判是：大家都先盯着业务代码看，结果最后发现是注册数据不一致或者客户端本地缓存过期。所以这篇文章不打算只讲概念，而是从 troubleshooting 的角度，把“注册中心 → 服务发现 → 负载均衡 → 故障隔离”这条链路串起来。

背景与问题：故障链路长什么样

先看一个典型调用链：

flowchart LR
    A[客户端请求] --> B[API服务]
    B --> C[服务发现]
    C --> D[实例列表]
    D --> E[负载均衡]
    E --> F[下游实例1]
    E --> G[下游实例2]
    E --> H[下游实例3]
    F --> I[返回结果]
    G --> I
    H --> I

问题在于，任何一个环节失真，都会把上层拖下水：

• 注册中心错：实例状态不准，发现结果就错
• 客户端缓存错：注册中心已经恢复，但客户端还在用旧列表
• 负载均衡错：把请求持续打到慢实例上
• 隔离策略缺失：少数异常请求拖垮整个进程

这类故障有一个非常“迷惑”的特征：
日志里看起来每一层都“偶尔成功”，但整体 SLA 明显下降。

核心原理

这一部分我们不追求大而全，只抓住排障最需要的几件事。

1. 服务发现的两种基本模型

客户端发现

客户端先从注册中心拉取实例列表，再在本地做负载均衡。

优点：

• 调用路径短
• 客户端可自定义负载均衡、重试、熔断策略

缺点：

• 每个客户端都要维护发现逻辑
• 实例变更传播依赖客户端缓存刷新机制

服务端发现

客户端请求一个代理层，由代理统一做服务发现和转发。

优点：

• 流量治理能力集中
• 策略统一，便于运维

缺点：

• 多一跳
• 代理本身也会成为关键基础设施

flowchart TD
    subgraph ClientDiscovery[客户端发现]
      A1[调用方] --> B1[注册中心]
      A1 --> C1[目标服务实例]
      B1 --> A1
    end

    subgraph ServerDiscovery[服务端发现]
      A2[调用方] --> B2[网关/代理]
      B2 --> C2[注册中心]
      B2 --> D2[目标服务实例]
    end

实战里很少绝对二选一。常见形态是：

• 内部 RPC 用客户端发现
• 对外入口流量走网关或服务网格
• 限流、熔断、灰度策略在代理层和客户端两边都做一层

2. 注册中心到底解决了什么

注册中心最核心的职责，不是“存地址”，而是维护一个近实时可用实例集合。

它通常至少要处理：

• 实例注册
• 健康检查或心跳续约
• 实例摘除
• 元数据管理，如版本、机房、权重、协议
• 变更通知或订阅

一个容易被忽略的点是：
注册中心保证的是“最终一致的实例视图”，不是“绝对实时且绝对正确”。

因此，客户端必须接受以下现实：

• 拉到的列表可能短时间过期
• 某个实例可能刚好处于“将死未死”的边缘状态
• 瞬时网络抖动会让健康状态误判

所以服务发现不是“拿到列表就万事大吉”，而是必须结合超时、重试、熔断、隔离一起设计。

3. 流量治理的几个关键动作

负载均衡

常见策略：

• 轮询
• 随机
• 加权随机
• 最少连接
• 一致性哈希

如果下游实例性能差异大，纯轮询往往是坑。我比较建议至少引入：

• 权重
• 慢实例惩罚
• 短期失败避让

限流

目的是保护系统，不是“让更多请求失败”。
典型用法：

• 入口 QPS 限制
• 按租户/用户限流
• 下游依赖的并发数限制

熔断

当下游失败率或超时率持续升高时，快速失败，避免资源被耗尽。

隔离

这是很多系统最容易缺的一环。隔离可以发生在：

• 线程池隔离
• 连接池隔离
• 队列隔离
• 机房隔离
• 租户隔离

没有隔离时，一个慢依赖就能拖死整个应用。

4. 故障隔离的本质

故障隔离不是“把错误挡住”，而是控制影响半径。
比如一个服务同时依赖支付、库存、推荐三个下游：

• 推荐挂了，不该拖垮支付链路
• 一个大客户流量暴涨，不该影响其他租户
• 某个机房有问题，不该把全局请求都打过去

sequenceDiagram
    participant U as 用户请求
    participant A as 业务服务
    participant D as 服务发现
    participant B as 下游服务
    participant C as 熔断/隔离器

    U->>A: 发起请求
    A->>D: 获取可用实例
    D-->>A: 返回实例列表
    A->>C: 申请并发槽位
    alt 槽位足够
        C-->>A: 放行
        A->>B: 调用下游
        alt 调用成功
            B-->>A: 返回结果
            A-->>U: 成功响应
        else 超时/失败
            B-->>A: 错误/超时
            A->>C: 记录失败
            A-->>U: 降级结果
        end
    else 槽位不足
        C-->>A: 拒绝
        A-->>U: 快速失败/降级
    end

现象复现

下面我们用一个可运行的 Python 小例子，模拟一个最小版的：

• 注册中心
• 两个服务实例
• 一个客户端发现逻辑
• 基于失败摘除和简单限流的流量治理

这个例子不追求生产可用，而是方便你在本地直观看到问题。

目录说明

我们会启动三个 HTTP 服务：

• registry.py：注册中心
• service_instance.py：服务实例
• client.py：调用方，带发现与流量治理

实战代码（可运行）

1）注册中心：维护实例列表

# registry.py
from flask import Flask, request, jsonify
import time
import threading

app = Flask(__name__)

services = {}
TTL = 10  # 10秒没有续约就视为失效


@app.route("/register", methods=["POST"])
def register():
    data = request.json
    service_name = data["service_name"]
    instance_id = data["instance_id"]
    host = data["host"]
    port = data["port"]
    weight = data.get("weight", 1)

    services.setdefault(service_name, {})
    services[service_name][instance_id] = {
        "host": host,
        "port": port,
        "weight": weight,
        "last_heartbeat": time.time(),
        "status": "UP",
    }
    return jsonify({"ok": True})


@app.route("/heartbeat", methods=["POST"])
def heartbeat():
    data = request.json
    service_name = data["service_name"]
    instance_id = data["instance_id"]

    if service_name in services and instance_id in services[service_name]:
        services[service_name][instance_id]["last_heartbeat"] = time.time()
        services[service_name][instance_id]["status"] = "UP"
        return jsonify({"ok": True})
    return jsonify({"ok": False, "error": "instance not found"}), 404


@app.route("/discover/<service_name>", methods=["GET"])
def discover(service_name):
    result = []
    now = time.time()
    for instance_id, meta in services.get(service_name, {}).items():
        if now - meta["last_heartbeat"] <= TTL and meta["status"] == "UP":
            result.append({
                "instance_id": instance_id,
                "host": meta["host"],
                "port": meta["port"],
                "weight": meta["weight"],
            })
    return jsonify(result)


def cleanup():
    while True:
        now = time.time()
        for service_name in list(services.keys()):
            for instance_id in list(services[service_name].keys()):
                meta = services[service_name][instance_id]
                if now - meta["last_heartbeat"] > TTL:
                    meta["status"] = "DOWN"
        time.sleep(2)


if __name__ == "__main__":
    t = threading.Thread(target=cleanup, daemon=True)
    t.start()
    app.run(port=5000)

2）服务实例：启动后注册并定时心跳

# service_instance.py
from flask import Flask, jsonify
import requests
import threading
import time
import random
import sys

app = Flask(__name__)

REGISTRY = "http://127.0.0.1:5000"
SERVICE_NAME = "order-service"
PORT = int(sys.argv[1])
INSTANCE_ID = f"order-{PORT}"


@app.route("/health", methods=["GET"])
def health():
    return jsonify({"status": "UP", "instance_id": INSTANCE_ID})


@app.route("/process", methods=["GET"])
def process():
    # 模拟一个不稳定实例：5002 端口偶发慢响应
    if PORT == 5002 and random.random() < 0.4:
        time.sleep(3)
    return jsonify({
        "ok": True,
        "instance_id": INSTANCE_ID,
        "port": PORT
    })


def register():
    requests.post(f"{REGISTRY}/register", json={
        "service_name": SERVICE_NAME,
        "instance_id": INSTANCE_ID,
        "host": "127.0.0.1",
        "port": PORT,
        "weight": 1
    }, timeout=2)


def heartbeat_loop():
    while True:
        try:
            requests.post(f"{REGISTRY}/heartbeat", json={
                "service_name": SERVICE_NAME,
                "instance_id": INSTANCE_ID
            }, timeout=2)
        except Exception:
            pass
        time.sleep(3)


if __name__ == "__main__":
    register()
    threading.Thread(target=heartbeat_loop, daemon=True).start()
    app.run(port=PORT)

3）客户端：本地缓存发现结果 + 简单故障隔离

# client.py
import requests
import time
import random
import threading

REGISTRY = "http://127.0.0.1:5000"
SERVICE_NAME = "order-service"

discovery_cache = []
cache_expire_at = 0

failure_count = {}
eject_until = {}

MAX_CONCURRENT = 5
current_concurrent = 0
lock = threading.Lock()


def discover():
    global discovery_cache, cache_expire_at
    now = time.time()
    if now < cache_expire_at and discovery_cache:
        return discovery_cache

    resp = requests.get(f"{REGISTRY}/discover/{SERVICE_NAME}", timeout=2)
    resp.raise_for_status()
    discovery_cache = resp.json()
    cache_expire_at = now + 5
    return discovery_cache


def choose_instance(instances):
    candidates = []
    now = time.time()
    for ins in instances:
        instance_id = ins["instance_id"]
        if eject_until.get(instance_id, 0) > now:
            continue
        candidates.append(ins)

    if not candidates:
        return None
    return random.choice(candidates)


def before_call():
    global current_concurrent
    with lock:
        if current_concurrent >= MAX_CONCURRENT:
            return False
        current_concurrent += 1
        return True


def after_call():
    global current_concurrent
    with lock:
        current_concurrent -= 1


def mark_failure(instance_id):
    failure_count[instance_id] = failure_count.get(instance_id, 0) + 1
    if failure_count[instance_id] >= 3:
        eject_until[instance_id] = time.time() + 15
        failure_count[instance_id] = 0


def mark_success(instance_id):
    failure_count[instance_id] = 0


def call_service():
    if not before_call():
        return {"ok": False, "error": "rate limited by concurrency guard"}

    try:
        instances = discover()
        instance = choose_instance(instances)
        if not instance:
            return {"ok": False, "error": "no available instance"}

        url = f"http://{instance['host']}:{instance['port']}/process"
        try:
            resp = requests.get(url, timeout=1)
            resp.raise_for_status()
            mark_success(instance["instance_id"])
            return resp.json()
        except Exception as e:
            mark_failure(instance["instance_id"])
            return {
                "ok": False,
                "error": str(e),
                "instance_id": instance["instance_id"]
            }
    finally:
        after_call()


if __name__ == "__main__":
    for i in range(20):
        print(call_service())
        time.sleep(0.5)

4）运行方式

先安装依赖：

pip install flask requests

分别启动：

python registry.py

python service_instance.py 5001

python service_instance.py 5002

python client.py

你会看到什么

• 5002 因为偶发慢响应，逐渐出现超时
• 客户端对 5002 连续失败 3 次后，临时摘除 15 秒
• 并发上限超过时，直接被本地限流挡住，避免堆死线程

这个例子对应了线上常见的几个动作：

• 注册中心提供实例列表
• 客户端做本地缓存，减少注册中心压力
• 调用超时后对异常实例做短期摘除
• 用并发隔离而不是无限堆积请求

定位路径

真实排障时，我建议按这条顺序查，不容易漏。

第一步：先判断是“找不到服务”还是“找到了但不可用”

看现象：

• no available instance：优先查注册中心、心跳、缓存
• timeout 或 connection refused：优先查实例健康、网络、负载均衡
• rate limited：优先查限流/并发保护是否误伤

第二步：对比三个视角的数据

必须同时看：

1. 注册中心视角

   • 当前有哪些实例
   • 实例状态 UP/DOWN 是否正确
   • 实例元数据是否异常

2. 客户端视角

   • 本地缓存里的实例列表是什么
   • 缓存刷新频率
   • 是否存在摘除中的实例

3. 服务端视角

   • 实例自身健康状态
   • 响应时间分布
   • 线程池/连接池是否耗尽

很多故障就是这三个视角不一致。

第三步：看关键时间点

排障不要只看“现在”，一定要看时间轴：

• 故障开始时有没有扩容、发布、摘流量
• 注册中心节点是否发生 leader 切换
• 是否出现网络抖动、DNS 变更、机房切流

如果时间点能对上，定位速度会快很多。

常见坑与排查

1. 心跳还在，但实例已经不可服务

这是很常见的“假活着”。

现象：

• 注册中心显示实例 UP
• 调用方持续超时
• 登录机器发现 CPU 100% 或线程池满

原因：

• 心跳线程和业务线程分离，业务挂了但心跳还活着
• 健康检查只检查进程存活，不检查关键依赖

建议：

• 健康检查至少覆盖关键资源：线程池、连接池、磁盘、下游依赖
• 避免只用“进程活着”作为健康标准

2. 注册中心已经摘除，客户端还在打旧实例

现象：

• 注册中心里查不到该实例
• 客户端日志还在访问旧 IP

原因：

• 客户端发现结果本地缓存过长
• 订阅通知丢失，未主动拉取补偿
• 长连接或连接池未及时清理

建议：

• 缓存设置上限，订阅失败时要有主动全量拉取
• 连接池对失效地址做短期禁用
• 实例下线前先摘流量再停服务

3. 重试把故障放大了

这个坑我真见过很多次：超时一来，大家本能地把重试次数从 1 改成 3，结果下游直接雪崩。

问题在于：

• 原始请求已经慢了
• 重试会带来额外流量
• 如果多个调用层都重试，流量会指数放大

建议：

• 只对幂等请求重试
• 重试次数小，且必须带退避
• 优先做实例切换重试，而不是对同一实例死磕

4. 熔断阈值设置不合理

现象：

• 明明只是短暂抖动，却触发大面积熔断
• 或者明明下游已经崩了，熔断迟迟不生效

建议：

• 区分超时、连接失败、业务失败三类错误
• 使用滑动窗口，不要只看单点失败
• 熔断后要有半开探测机制

5. 限流只在入口做，内部链路还是被打爆

入口限流只能保护第一层。
如果内部某个服务被多个上游共同调用，它仍然可能被压垮。

建议：

• 入口限流 + 服务级并发保护 + 下游依赖隔离，三层配合
• 对热点接口、热点租户单独限流

止血方案

如果线上已经在抖，不要上来就改一堆配置。优先做止血。

场景 1：下游少数实例异常

动作顺序：

1. 手工摘除异常实例
2. 清理客户端缓存或触发服务发现刷新
3. 确认连接池不再复用旧连接

场景 2：下游整体变慢

动作顺序：

1. 缩短调用超时，避免大量请求堆积
2. 降低重试次数
3. 打开熔断/并发隔离
4. 开启降级返回兜底数据

场景 3：注册中心不稳定

动作顺序：

1. 客户端切换到本地缓存兜底
2. 暂停非必要扩缩容和发布
3. 降低注册中心读写压力
4. 优先恢复注册数据一致性

这里有个边界条件要强调：
本地缓存兜底只能用于短期止血，不能长期依赖。
因为实例拓扑一旦变化，缓存只会越来越脏。

安全/性能最佳实践

安全方面

1. 注册与发现接口要鉴权

不要让任何实例都能随便注册。否则轻则脏数据，重则流量被恶意劫持。

建议：

• 注册接口使用 token、双向 TLS 或节点身份认证
• 注册元数据要做合法性校验
• 审计实例注册、摘除、权重变更操作

2. 防止元数据被滥用

如果元数据里允许任意写标签、权重、版本，治理策略很容易被误导。

建议：

• 限制可写字段
• 对权重和路由标签设置白名单
• 发布系统统一写入元数据，减少人工操作

性能方面

1. 发现结果要缓存，但不能缓存过久

经验上要在“注册中心压力”和“实例变更实时性”之间平衡。

建议：

• 本地缓存 3~10 秒起步，根据业务调整
• 同时支持推送更新和定时全量拉取补偿
• 发现失败时优先使用最近一次成功缓存

2. 超时要分层设置

不要所有超时都配成一样。

例如：

• 连接超时：较短
• 读取超时：依据接口耗时分布
• 总超时：小于上游 SLA 预算

3. 隔离资源池

不同下游不要共用一套线程池或连接池。

• 支付、库存、推荐分别隔离
• 核心链路和非核心链路隔离
• 大客户租户和普通租户隔离

4. 可观测性必须带实例维度

只看服务平均值会掩盖问题。
必须能看到：

• 每个实例的 QPS、RT、错误率
• 被摘除次数
• 本地缓存命中率
• 熔断打开次数
• 限流拒绝数

stateDiagram-v2
    [*] --> Healthy
    Healthy --> Suspect: 连续失败/超时升高
    Suspect --> Ejected: 达到摘除阈值
    Ejected --> HalfOpen: 摘除时间到
    HalfOpen --> Healthy: 探测成功
    HalfOpen --> Ejected: 探测失败

常用排查清单

下面这份清单我自己排障时经常用，比较实用。

服务发现排查清单

• 注册中心里实例数量是否正确
• 实例心跳是否连续
• 最近是否发生实例重启或扩缩容
• 客户端缓存是否刷新
• 客户端是否存在旧实例连接复用

流量治理排查清单

• 负载是否明显倾斜到少数实例
• 超时阈值是否过大导致请求堆积
• 重试是否把流量放大
• 熔断阈值是否过敏或过钝
• 并发隔离是否触发过多误拒绝

故障隔离排查清单

• 是否存在共享线程池/连接池
• 是否有慢下游拖垮整个应用
• 是否对热点租户做了单独保护
• 是否能按机房/可用区快速摘流量

总结

服务发现和流量治理，表面上是两个话题，实战里其实是一条链路：

• 注册中心决定你“看见谁”
• 服务发现决定你“选谁”
• 流量治理决定你“怎么打”
• 故障隔离决定出事时“影响多大”

如果你想把系统做得更稳，我建议优先落地这几件事：

1. 服务发现结果必须可观测

   • 能看到注册中心视角和客户端视角是否一致

2. 调用必须设置超时、重试边界和实例摘除

   • 不要让失败无限堆积

3. 核心依赖必须做并发隔离

   • 防止一个下游拖死整个服务

4. 实例下线流程要标准化

   • 先摘流量，再停服务，最后清缓存

5. 排障时按链路查，不要只盯业务代码

   • 先确认发现是否正确，再确认治理策略是否误伤

最后给一个很实用的判断标准：
如果你的系统在“一个实例变慢、一个节点失联、一个注册中心短时抖动”这三种场景下，仍然能稳定降级而不是全面雪崩，那这套设计基本就走在正确方向上了。