CAP定理

2012年9月，Netflix开源了一个名为Eureka的项目。这不是一个全新的技术发明，而是一个针对AWS云环境的妥协产物。然而，这个妥协引发了微服务社区长达十年的争论：服务注册中心到底应该优先保证一致性还是可用性？ ...

title: “一个服务地址背后的十五年博弈：从DNS到服务网格的演进之路” date: “2026-03-07T07:33:21+08:00” description: “深入解析微服务架构中服务发现的核心挑战。从DNS的TTL困境到客户端与服务端发现模式的权衡，从Eureka的AP设计哲学到Consul的Raft一致性保证，系统梳理不同服务发现方案的技术本质。分析Netflix、阿里巴巴等企业的实践案例，揭示服务发现在网络分区、脑裂、健康检查等场景下的设计考量，并提供不同场景下的技术选型决策框架。” draft: false categories: [“分布式系统”, “微服务”, “架构设计”] tags: [“服务发现”, “DNS”, “Consul”, “Eureka”, “etcd”, “服务网格”, “Istio”, “Kubernetes”, “CAP定理”, “Raft”, “微服务”, “负载均衡”, “健康检查”] 2015年，Netflix的工程师们设计了一个看似反直觉的机制：当Eureka服务注册中心检测到大量客户端心跳丢失时，它不会驱逐这些"失联"的实例，而是进入"自我保护模式"，保留所有现有记录。这不是bug，而是设计者精心埋下的安全机制。这个设计揭示了服务发现系统面临的一个根本性困境：在网络不可靠的世界里，你究竟应该相信什么？ ...

一个电商平台的订单系统收到两条消息：先是"订单已付款"，紧接着是"订单已发货"。但消费者处理时，先处理了"已发货"，再处理"已付款"。数据库里的订单状态变成了一个诡异的组合——用户明明已经付款，系统却显示发货在付款之前。 ...

2016年2月8日，分布式系统研究员Martin Kleppmann发表了一篇博客文章，标题直截了当：《如何正确实现分布式锁》。文章开篇就对Redis官方文档中的Redlock算法提出了尖锐批评，结论是"这个算法不适合用于正确性依赖于锁的场景"。 ...

1978年，图灵奖得主Jim Gray在《Notes on Data Base Operating Systems》中正式描述了两阶段提交协议（Two-Phase Commit, 2PC）。这个协议的核心目标简单而直接：让分布在不同机器上的多个数据库，能够像操作单一数据库一样实现"全有或全无"的原子性保证。 ...

2000年7月，加州大学伯克利分校的Eric Brewer在ACM Symposium on Principles of Distributed Computing上做了一个主题演讲。他提出了一个看似简单的观点：分布式系统不可能同时提供一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）。 ...

1985年，三位研究者Fischer、Lynch和Paterson发表了一篇论文，证明了一个令人沮丧的结论：在异步分布式系统中，即使只有一个进程可能崩溃，也不存在确定性的共识算法。这个被称为FLP不可能性定理的结果，并没有让分布式系统的发展停滞——相反，它催生了一系列优雅的工程解决方案。 ...