Istio

2016年，某电商平台在双十一促销中遭遇了诡异的服务调用超时。排查后发现，问题并非来自业务代码，而是服务间的网络通信层——每个微服务实例旁边都跑着一个Envoy代理，它们在处理mTLS加密、流量统计、熔断检测等任务时，竟吃掉了30%的CPU资源。这不是一个孤立的案例，而是一个技术演进过程中必然会暴露的深层矛盾：我们为了解决微服务通信的复杂性，引入了一个新的复杂层。 ...

2017年，Istio 1.0发布。Google、IBM、Lyft三巨头联手打造的服务网格项目，被寄予了重塑微服务通信的厚望。当时的技术媒体甚至用"微服务的最后一公里"来形容它——仿佛只要装上服务网格，所有分布式系统的难题都将迎刃而解。 ...

金丝雀发布的一个常见误解是：只要把流量切到5%的服务器上观察一阵子，就能发现所有问题。但现实远比这复杂。 2020年11月，Cloudflare遭遇了一次长达6小时的大规模故障。根因分析显示，一个正则表达式的性能问题导致CPU飙升。这次故障的关键教训是：问题往往在特定条件下才会暴露——高流量、特定请求模式、缓存未命中。一个配置在低负载测试环境中表现完美，却可能在生产环境的峰值压力下崩溃。 ...

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