微服务

概述 凌晨三点，手机狂震。打开一看，告警群已经炸了——支付服务 P99 延迟从 50ms 飙到 12 秒，错误率突破 80%。更要命的是，故障像多米诺骨牌一样连锁反应：用户服务超时 → 鉴权失败 → 库存服务重试风暴 → 消息队列阻塞 → 支付回调全部超时。监控大屏上三十秒内全部变红。 这不是某家公司独有的惨案。微服务拆得越细，服务间调用链越长，一个局部故障就越容易演变成全局雪崩。我曾在某新能源物流平台治理 50+ 微服务时，亲历过三次类似事故，最后一次最严重——一个下游搜索服务的数据库连接池打满，导致上游所有依赖搜索结果的服务线程池连锁耗尽，整条交易链路瘫痪 17 分钟。 那次事故后我们花了两周时间重做限流熔断降级体系。最终把 P99 从 200ms 压到 170ms，更重要的是，之后再没出现过级联故障。这篇文章把我踩过的坑、做过的架构选型、以及生产环境真正有效的配置经验一次讲透。 先说清楚三者的关系——很多人混着用，但它们解决的问题不同： 防护手段 解决什么问题 类比 作用位置 限流（Rate Limiting） 流量超过系统承载能力 超市收银台只开 3 个窗口，排满了就不让进了 入口处 熔断（Circuit Breaking） 下游服务故障，防止故障蔓延 保险丝，电流过大自动断电 调用链中间 降级（Degradation） 核心功能不可用时提供替代方案 停电了用应急灯，虽然不亮但能看见 业务逻辑层 三者配合使用：限流挡在前面控制输入，熔断在中间切断故障传播，降级在尾部保证用户体验不至于完全崩溃。 雪崩效应：为什么微服务比单体更容易崩 单体应用里，方法调用是进程内函数调用，微秒级完成。微服务拆开后，每次调用都变成了网络请求——网络可能抖动、DNS 可能解析慢、TCP 三次握手有开销、序列化反序列化要时间。一个用户请求从网关进来，经过 5-7 层服务调用是常态。 故障传播路径 看一个真实的调用链： 用户请求 → API Gateway → 订单服务 → 用户服务（鉴权） → 库存服务（扣减） → 优惠券服务 → 支付服务 → 第三方支付网关 假设第三方支付网关变慢了（比如响应从 100ms 变成 5 秒），会发生什么？...

概述 先回答一个最基本的问题：Service Mesh 是干嘛的？ 一句话：它帮你管微服务之间通信的那些破事。 微服务架构下，服务 A 调服务 B，看似简单的 HTTP 请求，实际上要处理一堆问题：超时了怎么办？重试几次？要不要熔断？流量怎么灰度？证书怎么管？链路怎么追踪？ 传统做法是每个服务自己搞定——Java 用 Spring Cloud，Go 用 go-kit，Python 用一些库。问题是不同语言各搞各的，升级一次 SDK 全部重新编译部署，运维想统一管理根本不可能。 Service Mesh 的思路是把这些通信逻辑从业务代码里剥离出来，放到一个独立的代理层（Sidecar 或节点级代理）。业务代码只管发 HTTP 请求，代理负责重试、熔断、加密、追踪。开发爽了，运维也爽了。 Istio 是 Service Mesh 领域最主流的实现，由 Google、IBM、Lyft 联合开发，2017 年开源，现在是 CNCF 仅次于 Kubernetes 的第二大牌面项目。这篇文章带你从零跑通 Istio，覆盖架构原理、安装部署、流量管理、安全策略和可观测性。 架构全景：控制平面与数据平面 Istio 的架构很清晰，分成两块： 控制平面（Control Plane）：Istiod，负责管理和配置数据平面的代理。你可以理解为"大脑" 数据平面（Data Plane）：一组代理，拦截和处理所有微服务之间的网络通信。你可以理解为"手脚" 数据平面有两种模式，这是 Istio 最核心的设计选择。 Sidecar 模式：经典方案 Sidecar 模式从 Istio 1.0 就有，是最成熟的方案。每个 Pod 旁边塞一个 Envoy 代理容器，所有进出该 Pod 的流量都先经过 Envoy。 ┌─────────────────────────────────┐ │ Pod │ │ ┌───────────┐ ┌─────────────┐ │ │ │ 业务容器 │←→│ Envoy │ │ │ │ (App) │ │ Sidecar │ │ │ └───────────┘ └─────────────┘ │ └─────────────────────────────────┘ ↑ ↓ 入站流量 出站流量 优点：...