微服务

2015年，Netflix的Runtime Platform团队面临一个棘手问题：他们用于服务间通信的自研HTTP/1.1技术栈在规模化场景下开始显现瓶颈。创建一个服务客户端需要2-3周，每个客户端都需要数百行手写的缓存管理代码，而API定义的缺失让服务的发现和理解变得异常困难。 ...

2011年，一位名叫Greg Young的开发者在一次技术会议上提出了一个看似简单的想法：如果我们不再存储对象的当前状态，而是存储导致状态变化的所有事件，会怎样？这个想法后来被称为事件溯源（Event Sourcing）。十五年后的今天，事件驱动架构已经成为微服务系统的核心范式，但它的复杂性也让无数开发者痛不欲生。 ...

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，而是设计者精心埋下的安全机制。这个设计揭示了服务发现系统面临的一个根本性困境：在网络不可靠的世界里，你究竟应该相信什么？ ...

2013年，Netflix的工程团队面临一个棘手的问题：他们的API调用已经增长到每天数十亿次，但传统的负载均衡器无法应对如此复杂的流量治理需求。解决方案是一个名为Zuul的API网关——它不仅能路由请求，还能处理认证、限流、监控等一系列横切关注点。 ...