服务发现

1. 问题本质：为什么需要服务发现

1.1 服务化的根本变化

服务化并不是“把单体拆小”，而是引入了一个根本性变化：

系统拓扑从静态变为动态

因此，服务发现的本质不是“查地址”，而是：

在动态、不可靠的分布式环境中，维持“服务名 → 可用实例集合”的稳定映射

1.2 DNS 的能力边界

DNS 在早期服务发现中可用，是因为当时满足以下隐含前提：

进入微服务时代后，这些前提不再成立：

维度DNS微服务环境
实例变更频率低高
健康状态感知无必须
更新传播延迟高要求低
调用失败代价可接受极高

因此，服务发现成为基础设施级能力，而非命名系统问题。

2. 服务发现的抽象模型（核心升维）

在具体产品之前，先建立一个稳定抽象模型。

2.1 核心角色模型

服务发现系统始终包含三类角色：

角色本质职责
服务提供者主动或被动暴露自身状态
服务发现中心汇聚、判断、传播实例状态
服务消费者基于发现结果进行调用决策

2.2 控制面 / 数据面分离

从系统架构角度，服务发现本质上是一个控制面系统：

服务发现系统的所有设计，都是在“控制面不稳定”前提下，保障数据面可用

这是理解 AP / CP 取舍的关键前提。

2.3 服务发现的核心矛盾

服务发现系统必须在以下目标之间权衡：

不可能三角的本质体现：CAP 在服务发现中的工程化落地

3. 服务发现的两种架构范式

3.1 自理式服务发现（Client-based）

定义：服务消费者直接与服务发现中心交互，并在本地完成实例选择。

架构特征

本质优势

本质代价

Eureka / Spring Cloud 体系属于该范式

3.2 代理式服务发现（Proxy-based）

定义：应用不感知服务发现，实例选择由基础设施代理完成。

架构特征

本质优势

本质代价

Service Mesh 是代理式服务发现的治理终态

4. 服务发现的共性设计能力

无论采用何种实现，服务发现系统都必须具备以下稳定能力：

4.1 实例状态管理

4.2 健康判断机制

4.3 状态传播与同步

5. 一致性策略：AP 与 CP 的工程理性

5.1 Eureka：AP 优先的设计选择

核心判断：

调用到“可能已下线的实例”，好过“因发现系统不可用而无法调用任何实例”

设计结果

自我保护的本质

不是“容错”，而是：

在网络不可靠时，避免控制面错误放大到数据面

5.2 Zookeeper：CP 的天然属性

工程现实

Zookeeper 是优秀的一致性协调系统但并非为高频服务注册而设计

5.3 Nacos：多目标折中方案

本质区别：

Eureka 是“完全对等系统”Nacos 是“中心化控制系统”

6. 服务发现不是终点，而是治理起点

6.1 服务发现 × 服务治理能力树

服务发现├─ 实例管理├─ 健康判断├─ 元数据│  ├─ 权重│  ├─ 标签│  └─ 区域├─ 流量治理│  ├─ 灰度发布│  ├─ 就近路由│  └─ 摘流降级└─ 可观测性   ├─ 健康决策依据   └─ 状态可解释性

没有治理能力的服务发现，只是“动态 DNS”

7. 总结：稳定认知结论

  1. 服务发现的本质是**控制动态系统的不确定性**
  2. AP / CP 是**设计目标选择，而非技术优劣**
  3. 自理式与代理式的区别在于**责任归属**
  4. 服务发现是服务治理体系的**基础设施层**
  5. 所有具体框架都是对上述模型的不同实现取舍

关联内容（自动生成）