分布式系统

一次API请求，平均延迟50毫秒，P99却飙到了800毫秒。排查应用代码、数据库查询、缓存命中，一切正常。最后发现问题出在TCP层——一次重传超时。 ...

一个电商平台在双十一期间需要处理数百万个订单超时取消任务。每个订单创建后30分钟未支付就需要自动取消，释放库存。最直观的实现方式是在数据库中存储订单的创建时间，然后启动一个定时任务每隔几秒扫描一次，找出所有超时的订单。 ...

2015年9月20日，AWS DynamoDB在US-East-1区域经历了超过4小时的服务中断。这次事故的起点极其微不足道：一个瞬时的网络问题导致部分存储服务器无法获取分区分配信息。 ...

2010年10月，位置社交应用Foursquare经历了一场持续17小时的宕机。当时这家创业公司拥有300万用户、2亿次签到、每天新增1.8万用户，业务正处于快速增长期。导致宕机的直接原因并不复杂：分片数据分布不均，一个分片的数据量达到67GB，超过了节点66GB的内存容量，系统开始疯狂地将内存页面换入换出，整个数据库被拖慢到磁盘速度。 ...

2014年，Bitly每月处理60亿次点击和6亿次链接缩短，仅用约30台前端服务器支撑全球流量。这个看似简单的"长变短"功能，却是分布式系统设计的经典考题——它完美浓缩了ID生成、存储选型、缓存策略、高可用设计等核心问题。 ...

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年，Target进军加拿大市场，133家门店同时开业。短短两年后，这家美国零售巨头黯然退出加拿大，累计损失超过21亿美元。根本原因之一是库存数据迁移的灾难性失败——货架上的商品和系统里的记录完全对不上，顾客在结账时发现价格与标签不符，仓库里堆满了系统显示"缺货"的商品。 ...