一、CAP理论在服务注册与发现中的落地实践
1.1 CAP三要素的技术权衡
| 要素 | AP模型实现 | CP模型实现 |
|---|---|---|
| 一致性 | 最终一致性（Eureka通过异步复制实现） | 强一致性（ZooKeeper通过ZAB协议保证） |
| 可用性 | 服务节点可独立响应（支持分区存活） | 分区期间无法保证写操作（需多数节点可用） |
| 分区容错性 | 必须支持（分布式系统基本要求） | 必须支持（通过复制协议实现） |
典型场景对比：
- 电商秒杀（AP）：允许部分用户看到旧服务列表，但保证页面可访问。
- 银行转账（CP）：必须等待服务状态全局一致，避免资金不一致风险。
二、AP模型深度解析：高可用优先的设计哲学
2.1 核心场景与技术实现
2.1.1 适用场景特征
- 动态伸缩性要求高：
容器化环境中服务实例每分钟上下线超100次（如Kubernetes集群），AP模型的无主节点架构（如Eureka集群）可避免主节点成为瓶颈。 - 读多写少操作：
服务发现请求中查询占比＞90%，写入（注册/注销）频率低，允许缓存数据短暂不一致。
2.1.2 关键技术方案
Eureka架构解析：
- 心跳机制：服务实例每30秒发送心跳，超时90秒标记为失效。
- 缓存策略：客户端缓存服务列表，默认30秒更新一次，注册中心宕机时仍可调用。
- 自我保护模式：当心跳失败比例＞85%，停止剔除服务实例，避免网络分区误判。
Consul AP模式配置：
# consul配置文件
datacenter = "dc1"
server = true
bootstrap_expect = 3
# 开启AP模式（牺牲强一致性换取可用性）
disable_leader = true
disable_gossip = true
三、CP模型深度解析：强一致性优先的设计哲学
3.1 核心场景与技术实现
3.1.1 适用场景特征
- 分布式协调需求：
如Kubernetes的节点注册（需保证Pod列表实时一致）、分布式锁（如Redlock）。 - 配置中心场景：
服务配置变更（如限流规则）需秒级同步到所有节点，避免部分节点使用旧配置导致故障。
3.1.2 关键技术方案
ZooKeeper一致性实现：
