服务发现与负载均衡

06-工程实践与前沿入门约 15 分钟 #服务发现#负载均衡#健康检查更新 2026-10-02

当前状态：未学

本文基于模型知识整理（生成时未联网核对），关键结论建议对照经典文献复核。

一句话定义

服务发现回答"目标服务现在有哪些活着的实例地址"，负载均衡回答"这次请求发给谁"；二者合起来把动态伸缩的实例集合抽象成一个稳定的虚拟端点。

为什么重要

实例 IP 随扩缩容、发布、故障不断变化，写死地址是分布式时代的第一反模式。发现与均衡的每一层选择（客户端 vs 服务端、注册中心的语义、健康检查的方式）都直接影响故障切换速度与流量倾斜——它们是 kp-030 熔断限流的上游入口。

前置知识

kp-001、kp-007（RPC 调用模型）。

核心概念

注册中心模式：服务启动时注册（自报地址+元数据），消费方订阅变更（watch/推送或轮询）；实例下线靠主动注销或心跳/租约过期（kp-020 的 ephemeral/lease）。
客户端负载均衡：SDK 内嵌均衡逻辑（gRPC 的 addr resolver + LB policy），少一跳、能做每连接精细策略，但多语言实现成本高。
服务端/代理式负载均衡：集中式网关或 sidecar（LVS/Nginx/Envoy/K8s Service+iptables/eBPF），策略集中管理，多语言免费获得，代价是多一跳延迟与代理自身的容量。
健康检查：主动探测（TCP/HTTP 探针）与被动探测（按错误率/延迟剔除）两种信号源；只看端口通是不够的（进程活着但业务假死）。
均衡策略：轮询/加权轮询、最少连接、一致性哈希（会话亲和与缓存命中）、P2C（随机选两个取负载低者——实践上对抗倾斜最有效之一）。

原理与机制

发现的一致性语义陷阱：注册中心是共识系统（ZK/etcd）时强一致但容量有限；是 AP 系统（Eureka、DNS）时可能给消费方过期列表——把请求发给已死实例不可避免，因此重试与快速失败（kp-006/029）是发现机制的必备下游配套，而不是可选项。

健康检查的误判两难：探测间隔短 → 误杀（GC 停顿被判死）；间隔长 → 故障实例持续接流量。工程上组合使用：主动探针（慢频）+ 被动熔断（按实时错误率快速剔除），并把业务就绪（readiness，如依赖的 DB 连接池可用）与存活（liveness，进程还活着）分离——K8s 的这两个探针正是该分离的标准化。

负载不均的真实原因往往不是策略，而是请求成本不均 + 长连接静态映射：长连接建立后请求固定打到同一实例，重启过的实例连接少反而空转；P2C + 定期连接重均衡（或最少连接策略）是对症的解法。

图示

Provider 启动 ──注册(lease)──► Registry(etcd/Nacos)
Consumer ──watch/轮询──► 实例列表 ──P2C 选择──► 实例
实例假死: 被动熔断(错误率↑) 3s 剔除  +  主动探针 30s 兜底

实例或案例

Kubernetes Service：Service VIP + endpoints 控制器按 readiness 摘除实例；kube-proxy/服务网格承接转发。
Nacos/Eureka/Consul：国内微服务常见的注册中心三选，AP/CP 取舍各异（Eureka AP 优先，Nacos 可切换）。
gRPC xDS：控制面（Istio/Envoy）把发现与均衡策略推给客户端，是"客户端 LB 的策略集中化"。

常见误区

误区一："注册中心有健康检查就够了"。检查只能证明"探测那一刻活着"，不证明"接下来能处理请求"；必须与调用方熔断配合。
误区二："轮询就是公平"。请求成本差异大时轮询会周期性打爆慢实例；按在途请求数（最少连接/P2C）或按成本加权更稳。
误区三："服务发现可以不做降级"。注册中心本身故障时，客户端应能用最后一份实例列表（stale cache）继续服务——发现组件不能成为可用性单点。

与其他知识点的关系

kp-010/020：实例列表的分发与租约机制。
kp-030：均衡策略之后的第一道防线是限流熔断。
kp-006/029：对已死实例的调用靠重试与幂等兜底。

自测题

客户端与服务端负载均衡各自的取舍？

答：客户端少一跳、策略灵活但多语言重复实现；服务端集中易管理、语言无关但多一跳且代理需扩容。

为什么 readiness 与 liveness 要分开？

答：未就绪（如依赖不可用）应摘流量但不重启；进程死锁才重启。混用会把临时不可用放大成重启风暴。

长连接场景为什么轮询会失衡？

答：连接与实例静态绑定，请求沿旧连接持续打到少数实例；需要连接级重均衡或按在途请求选择的策略。