Microservices on 纪伟的个人博客

服务网格：从 sidecar 到 Ambient，那笔"分布式税"怎么省

Tue, 25 Nov 2025 10:00:00 +0800

写在前面

《每个程序员都该知道的延迟数字》里点过一笔账：Service Mesh 代理会增加延迟和资源消耗，但开销不是一个跨环境固定的“每跳毫秒数”。Istio 官方基准显示，它会随协议、连接数、请求率、负载大小、代理线程数和遥测功能明显变化。《后端架构实战（四）：微服务的"分布式税"》讲过这笔税为什么存在。

这篇比较三种数据面路线：sidecar、Istio Ambient，以及以 eBPF 加速网络路径的 Cilium Service Mesh。它们不是严格接替的“三代产品”，而是可以并存的架构选择。

这篇是独立参考稿，不绑某个系列。它和《分布式税》《延迟数字》《Polly》《可观测性》几篇互相印证，串成"微服务通信"的一条线。

一、服务网格到底解决什么

微服务一起来，每一条 service-to-service 链路都背着同一堆非功能性需求：

安全：双向加密 + 身份认证（mTLS）——别让内网裸奔；
弹性：超时、重试、熔断、限流——别让一个慢下游拖垮整条链路；
流量治理：金丝雀发布、按比例分流、按 header 路由、流量镜像；
可观测：服务间拓扑、延迟分布、错误率、访问日志。

每个服务自己用框架（.NET 的 Polly、Java 的 Resilience4j、Go 的中间件……）实现一遍 = 语言不一致、版本不一致、改一条策略要动几十个仓库。

服务网格做的事就一句话：把这一整层从应用代码里抽出来，下沉成独立的基础设施层。应用只管业务逻辑，网格管"服务间通信的所有非功能性需求"。

所以网格不是"替你交分布式税"，而是让交税的方式标准化、集中化——税还在，但不再每个服务各交各的。

二、第一代：Sidecar（Istio + Envoy）

怎么工作

每个 Pod 被 mutating webhook 注入一个 Envoy sidecar，Pod 内所有进出流量被 iptables 规则重定向到本地 Envoy。应用完全无感——它以为自己直连对端，其实流量先被本地 Envoy 拦了一道。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


Pod A Pod B
┌────────────────┐ ┌────────────────┐
│ App │ │ App │
│ │ │ │ ▲ │
│ ▼ │ │ │ │
│ Envoy ───────┼──── mTLS ────→┼── Envoy │ ← 每 Pod 一个 sidecar
└────────────────┘ └────────────────┘

一次调用: app → 本地 Envoy → 网络 → 对端 Envoy → 对端 app
 多了 2 个本地代理跳 + 2 次 mTLS 加解密

能力与代价

能力（这一代把网格能做的几乎全做到了）：mTLS + SPIFFE 身份、VirtualService 的金丝雀/分流/镜像、DestinationRule 的熔断/outlier detection、全量遥测（指标/链路/访问日志自动埋点）。

代价正是延迟篇那笔账：

延迟：请求多经过客户端和服务端代理，过滤器、遥测和排队都会增加平均与尾部延迟；实际值必须按自己的协议、并发和策略压测。
资源：每个工作负载都有代理。Istio 1.24 的官方参考测试中，1 KB 请求、1000 RPS、两个 worker 的单个 sidecar 约占 0.20 vCPU 和 60 MB 内存；这只是特定基准，不是容量规划常数。
启动：Pod 启动变慢且有序问题——应用先于 Envoy 就绪时，出站连接失败；Envoy 先于应用时，入站没人接。

sidecar 模型的问题不在"能力不够"，而在粒度太细：每个 Pod 都扛一个全功能 Envoy，绝大多数流量其实只用到它 mTLS 这一小块。

三、第二代：Ambient（ztunnel + waypoint）

核心思路：L4 和 L7 解耦

Istio Ambient 的洞察是——大多数流量只需要 mTLS（L4），不该每个 Pod 扛一个全功能 Envoy。于是把数据面拆成两层：

ztunnel：每台 node 跑一个（DaemonSet），用 Rust 写的极轻 L4 代理。只管 mTLS 加解密 + L4 授权。node 上所有 Pod 的流量统一由它过，传输用 HBONE（HTTP/2 CONNECT 隧道协议）封装。
waypoint：按需部署（per namespace 或 per service），本质还是 Envoy，但只在需要 L7 策略时才起（流量分割、HTTP 级重试、L7 授权）。不需要 L7 的服务，流量只过 ztunnel，不碰 waypoint。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


Node 1 Node 2
┌─────────────────────┐ ┌─────────────────────┐
│ Pod A Pod B │ │ Pod C Pod D │
│ │ │ │ │ │ │ │
│ ▼ ▼ │ │ ▲ ▲ │
│ └──→ ztunnel ────┼── HBONE ──┼→ ztunnel ←──┘ │ ← 每 node 一个(L4)
│ (L4) │ 隧道 │ (L4) │
│ │ │ │ │ (按需) │
│ ▼ │ │ ▼ │
│ waypoint │ │ waypoint │ ← 需要 L7 才起
└─────────────────────┘ └─────────────────────┘

L4 流量只过 ztunnel（轻）；要 L7 治理才加 waypoint 那一跳

收益与代价

收益：

减少重复资源：从“每工作负载一个 Envoy”变成“每节点一个轻量 ztunnel + 按需 waypoint”；能省多少取决于 Pod、节点、waypoint 副本数和策略规模。
避免 per-Pod 代理：流量仍会经过源、目的节点上的 ztunnel，HBONE 也仍有代理、加密与排队成本；收益来自更轻的共享 L4 数据面，而不是“近乎零额外跳”。
零侵入：业务 Pod 不再被注入 sidecar，迁移成本和故障面都小。
可并存：Ambient 能和 sidecar 模式混跑，逐服务渐进迁移。

代价：

心智更绕：ztunnel + waypoint + HBONE 三件事，比"一个 sidecar"复杂。
L7 那一跳省不掉：要流量分割/重试，waypoint 本质还是个 Envoy——只是换了部署位置。
能力仍在演进：Ambient 于 2024 年 5 月随 Istio 1.22 进入 Beta，并于 2024 年 11 月随 1.24 达到 GA；核心 ztunnel、waypoint 和 API 已标记 Stable，但与 sidecar 的功能对齐仍是后续路线图的一部分。

四、另一条路线：eBPF（Cilium Service Mesh）

核心思路：既然要离开应用进程，干脆离开用户态

Cilium 使用 eBPF 在内核数据路径中完成服务负载均衡、网络策略和可观测等 L3/L4 工作；需要解析 HTTP、gRPC、Kafka 或 DNS 等应用层协议时，流量仍要重定向到用户态 Envoy。

L3/L4：eBPF 负责转发、负载均衡、策略执行和观测；可选的 WireGuard/IPsec 提供透明加密，但这不等同于成熟的工作负载级 mTLS 身份认证。
身份认证：Cilium 的 SPIFFE/SPIRE mutual authentication 在当前文档中仍为 Beta，若要同时获得加密，还需启用 WireGuard 或 IPsec。
L7：eBPF 将需要应用层处理的流量透明重定向到 Envoy；具体部署形态取决于安装配置。

一个必须说清的诚实点

Cilium 经常被宣传成"无 sidecar、eBPF 搞定一切"，但它的 L7 仍然要靠 Envoy，只不过从"每 Pod 一个"换成了"每 node 一个共享实例"。所以：

Cilium 和 Ambient 都不是“消灭所有代理”。Ambient 用节点级 ztunnel 承担安全 L4 overlay，并按需加入 waypoint；Cilium 用 eBPF 承担大量 L3/L4 工作，但 L7 仍依赖 Envoy。二者的身份模型和策略 API 也不同。

收益与代价

收益：L3/L4 极致性能（内核原生）、无 per-pod 开销、内核级可观测（网络指标天然丰富）。

代价：

L7 多租户隔离是社区讨论点——共享 node Envoy 处理多服务流量，隔离不如 per-pod sidecar 干净。
依赖满足 Cilium 支持矩阵的 Linux 内核与功能配置；不要用一个笼统的 5.10+ 代替安装前的系统要求检查。
控制面是 Cilium 自家体系（CiliumNetworkPolicy 等 CRD），和 Istio 的 VirtualService/DestinationRule 不通用，迁移有成本。

五、三条路线横评

维度	Sidecar（Istio 经典）	Ambient（Istio）	eBPF（Cilium）
数据面位置	每 Pod 一个 Envoy	每 node 一个 ztunnel + 按需 waypoint	内核 eBPF（L3/L4）+ 每 node Envoy（L7）
L7 能力	全（Envoy 原生）	全（waypoint = Envoy）	有，但弱于 Istio 的体系
每 Pod 开销	大（几十~百 MB）	几乎为零（无 sidecar）	几乎为零（无 sidecar）
延迟开销	多两个代理数据路径，需实测	L4 路径更轻；L7 增加 waypoint	L3/L4 主要在 eBPF 路径；L7 增加 Envoy
心智复杂度	中（最成熟、资料最多）	中高（ztunnel + waypoint + HBONE）	中（eBPF + 内核依赖）
成熟度	最成熟	Istio 1.24 起 GA；功能仍持续对齐	Cilium 网络数据面成熟；mutual authentication 仍为 Beta
适用	已有 Istio、重度 L7 治理	新部署、求轻量、要 mTLS+可观测	新内核、追性能、L7 需求不重

六、那笔税到底省了多少

回到延迟问题，更稳妥的比较方式是看数据路径，而不是套一个固定的“每 hop”数字：

1
2
3


sidecar（每工作负载 Envoy）：请求经过两端 Envoy，功能完整、资源隔离清晰
Ambient L4（ztunnel + HBONE）：请求经过两端节点 ztunnel，共享轻量 L4 数据面
Cilium L3/L4（eBPF）：转发与策略主要在内核路径；需要 L7 时再进入 Envoy

（Ambient/Cilium 的精确延迟要看各自的官方基准，随负载和场景漂移；这里给的是相对量级。）

最该记住的洞察：这些路线不是把分布式通信变成零成本，而是在代理隔离、共享资源和内核加速之间取舍。只要需要基于 HTTP 等应用层语义做治理，就需要 L7 解析；在本文讨论的实现里，这仍由 Envoy 承担。

所以省下的是基础 mTLS 这一层的重复税，不是"L7 治理本身的税"。L4 需求为主、L7 需求少的服务，是 Ambient/Cilium 最大的受益者。

七、怎么选（决策清单）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


□ 已有 Istio + 重度 L7 治理（金丝雀/重试都写在 VirtualService 里）
 → 留 sidecar；想降开销就逐服务迁 Ambient（能并存，渐进）

□ 新部署、主要要 mTLS + 基础可观测、资源敏感
 → Ambient

□ Linux 内核满足目标 Cilium 版本的系统要求、重视网络数据面效率、团队熟悉 eBPF
 → Cilium

□ 规模没到（几十个服务以下）
 → 可能根本不需要网格

最后一条最容易踩坑。网格自身的运维复杂度（控制面、版本升级、故障排查、CRD 体系）不低。规模没到时，可以按需求组合网络策略、平台提供的工作负载身份或 mTLS 能力、应用侧 Polly 与 OpenTelemetry；其中 Kubernetes NetworkPolicy 只做网络访问控制，本身不提供 mTLS。网格是规模问题的解药，不是小集群的补品。

八、和 .NET / ASP.NET Core 的分工

网格下沉之后，应用层还做什么？关键原则是别重叠——两边都做同一件事，不仅浪费，还会出事：

mTLS：若网格已覆盖这条链路，应用通常不必再重复建立一层同目的的传输加密；但端到端合规边界、网格外流量和应用层加密需求仍需单独评估。
重试 / 超时 / 熔断：二选一。要么网格（Istio 的 DestinationRule / Ambient waypoint），要么应用（Polly）。两边都开 = 双重重试，一个失败触发两层的重试风暴，放大流量、恶化雪崩——这是最常见的坑。一般原则：跨服务边界的通用策略 → 网格；和业务逻辑绑定的（“这个 API 失败重试 3 次且只对特定错误”)→ 应用层 Polly。详见《Polly 的前世今生》《分布式税》。
可观测：互补，不是替代。网格给"服务间拓扑 + 调用延迟 + 错误率"（数据面自动埋点，零侵入）；OpenTelemetry 给"业务全链路 + 应用内 span"。两者通过 trace context 串联，画面才完整。详见《后端架构实战（七）：可观测性》。
流量治理（金丝雀、AB、按 header 分流）：网格擅长，别在应用里自己造路由层。

小结

服务网格 = 把服务间通信的非功能性需求（mTLS / 弹性 / 治理 / 可观测）从应用下沉成独立基础设施层。
三条路线：sidecar（每工作负载 Envoy）、Ambient（节点级 ztunnel + 按需 waypoint）、Cilium（eBPF L3/L4 + 按需 Envoy L7）；它们并非严格代际替换。
税省了什么：Ambient 和 Cilium 都避免 per-Pod sidecar，但数据路径、身份认证与 L7 处理仍有成本；必须以目标环境的 p50/p99、吞吐和资源占用实测选型。
选型：看 L7 需求 / 规模 / 内核版本 / 团队能力；规模没到别硬上，Polly + OTel 可能更划算。
和应用层的边界：mTLS 交网格、重试别两边都开（双重重试是最常见的坑）、可观测互补。

一句话：服务网格这十年的故事，就是把"分布式税"从每个应用进程里，一寸一寸挪到 node 和内核——挪得越远，应用越轻，但那笔 L7 的核心税，到现在谁也没真消掉。

参考资料

Polly 的前世今生：从 Policy 到 ResiliencePipeline 的韧性范式重构

Sat, 15 Nov 2025 10:00:00 +0800

写在前面

在分布式系统里，“调用失败”不是异常，而是常态。网络会抖、依赖会慢、对端会短暂挂掉。如果你的代码只会 try/catch 然后把异常往上抛，那一次偶发的 503 就会变成一次真实的业务损失——订单失败、请求超时、用户体验坍塌。

Polly 就是 .NET 生态用来回答这个问题的答案。它是事实标准的韧性（resilience）框架，把“重试、熔断、超时、降级、限流”这些原本散落各处的容错逻辑，抽象成可组合、可配置、可观测的策略积木。

但 Polly 在 v8 做了一次近乎重写的范式升级：从“以 Policy 为中心”迁到“以 ResiliencePipeline 为中心”。这次重构不是换一套 API 那么简单，而是重新定义了“.NET 应用该如何做韧性工程”。这篇文章我们就把 Polly 的前世今生、七大策略、管线组合、可观测性，以及它背后的设计思想一次讲透。

顺带：这篇和《HttpClient 的前世今生》是姊妹篇——HttpClient 负责“怎么把请求发出去”，Polly 负责“请求失败了怎么办”，两者在 .NET 8 通过 Microsoft.Extensions.Http.Resilience 最终合流。

一、为什么需要韧性：故障是分布式系统的常态

进入具体策略之前，先建立心智模型。分布式系统的故障大致分三类，每一类需要完全不同的对策：

故障类型	典型场景	正确对策
瞬时故障 (transient)	网络抖动、短暂 5xx、限流 429	重试——大概率自愈
持续故障 (sustained)	依赖真的挂了、磁盘满了	熔断——停止徒劳重试，保护下游
自身过载 (overload)	自己被打爆、连接池耗尽	限流 / 舱壁——主动收缩，保住容量

如果你对这三类故障用同一招（比如“一律重试三次”），就会在最坏情况下火上浇油：对端已经挂了你还猛重试，把下游彻底压垮，同时耗光自己的线程和连接。

Polly 的价值正在于此：它把不同故障对应的策略做成可组合的积木，让你按需拼装。理解了这一点，下面的 API 都是好理解的“积木说明书”。

边界提示：本文讨论的所有策略都挂在调用方一侧——HttpClient 对自己的出站调用做保护，下游服务器并不知情。所以这是“我调别人时给自己加韧性”，与服务端的入站限流 / 降级是两套东西。

二、前世今生：v7 到 v8 的范式重构

这是理解现代 Polly 最关键的一节。我们对比两段代码。

v6/v7：以 Policy 为中心。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


// v7：每个策略是一个 Policy 对象，手动 wrap 组合
var retry = Policy
 .Handle<HttpRequestException>()
 .OrResult<HttpResponseMessage>(r => !r.IsSuccessStatusCode)
 .WaitAndRetryAsync(3, attempt => TimeSpan.FromSeconds(Math.Pow(2, attempt)));

var breaker = Policy
 .Handle<HttpRequestException>()
 .CircuitBreakerAsync(5, TimeSpan.FromSeconds(30));

var wrapped = Policy.WrapAsync(retry, breaker); // 手动组合
var resp = await wrapped.ExecuteAsync(ct => client.GetAsync(url, ct), ct);

它的特征与局限：

API 维度较多：同步/异步、无结果/有结果分别使用不同接口和构造方式，组合时需要区分。
结果与异常用不同 API：.Handle<>() 管异常，.OrResult(...) 管返回值，谓词表达割裂。
手动 PolicyWrap 组合：顺序靠参数位置，缺乏统一的管线抽象。
观测依赖手工回调：v7 可以在重试、熔断等回调里记录日志，但缺少 v8 统一的 telemetry 管线。
配置与代码耦合：阈值写死在代码里，改配置要重新发布。

v8：以 ResiliencePipeline 为中心。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


// v8：管线 + 策略 + 配置对象，结果与异常用统一谓词
var pipeline = new ResiliencePipelineBuilder<HttpResponseMessage>()
 .AddRetry(new RetryStrategyOptions<HttpResponseMessage>
 {
 MaxRetryAttempts = 3,
 Delay = TimeSpan.FromSeconds(1),
 BackoffType = DelayBackoffType.Exponential,
 UseJitter = true,
 ShouldHandle = new PredicateBuilder<HttpResponseMessage>()
 .Handle<HttpRequestException>()
 .HandleResult(r => !r.IsSuccessStatusCode)
 })
 .AddCircuitBreaker(new CircuitBreakerStrategyOptions<HttpResponseMessage>
 {
 FailureRatio = 0.5,
 MinimumThroughput = 10,
 SamplingDuration = TimeSpan.FromSeconds(30),
 BreakDuration = TimeSpan.FromSeconds(30)
 })
 .AddTimeout(TimeSpan.FromSeconds(10))
 .Build();

var resp = await pipeline.ExecuteAsync(ct => client.GetAsync(url, ct), cancellationToken);

驱动这次重构的有四股力量：

统一：一个 ResiliencePipeline 同时支持同步/异步、泛型化，策略即插即用。
可观测：内建 metrics（Polly meter）与 telemetry，韧性第一次“看得见”。
集中配置：options 对象 + 注册表让策略构造与业务调用解耦；校验和动态重载需要相应的 .NET options 集成。
性能：管线编译一次反复复用，大幅减少每次执行的分配。

所以 v8 不是“换个写法”，而是把韧性从“手写策略”提升为“可运维的工程基础设施”。

三、核心心智：Strategy 与 Pipeline

整个 v8 只有两个核心概念：

Strategy（策略）：单一韧性能力（重试、熔断、超时……），是管线的积木。
Pipeline（管线）：有序组合的策略链，外层策略包裹内层策略。

执行模型是经典的“洋葱”，但比一句话更能帮助理解的是它的代码形态。每个策略本质是这样一个函数（伪代码）：

1
2
3
4
5
6
7
8
9


async Task<Outcome<T>> ExecuteAsync(ResilienceContext ctx, Func<Outcome<T>> next)
{
 // ── 下行：调用内层前的准备 / 门禁（启动计时、看熔断状态）──
 ...
 var outcome = await next(); // 把控制权交给内层
 // ── 上行：拿到结果后的决策（重试？记失败？抛超时？）──
 ...
 return outcome;
}

next() 就是“内层那一段”：调用 next = 控制权往内走，next 返回 = 控制权往回走。整条管线是一摞这样的函数嵌套——下行做门禁、上行做决策，真正的判断几乎都在拿到结果之后。

顺手认出这个模式：它就是责任链（Chain of Responsibility）——和《设计模式实战（六）》里讲过的 ASP.NET Core 中间件同源。严格说，Polly 是责任链的“装饰器链”变体：经典 GoF 责任链是“某个 handler 处理掉就结束”的单向链；这里是双向洋葱，每个节点都参与（既预处理又后处理），请求一路下到真正的调用、结果再原路返回穿过所有节点。入站中间件、出站 DelegatingHandler、Polly 管线——同一个模式的三次复用。

以标准顺序 TotalTimeout( Retry( CircuitBreaker( AttemptTimeout( Exec ) ) ) )（顺序的讲究见第五节）为例，看一次完整生命周期：

1
2
3
4
5
6
7


下行（请求往里走） 上行（结果往外走）
══════════════════ ══════════════════
① 总计时启动 ─┐ ┌─ 总计时释放
② 重试 第1次 ─┤ ├─ 重试：要不要再来一次？
③ 熔断 看状态(闭?) ─┤ ├─ 熔断：记一笔，要不要开路？
④ 单次计时启动 ─┤ ├─ 单次计时释放
 └→ Exec：真正发 HTTP ──────────────→ 结果原路返回 ─┘

两个最能帮你“看透”的认知：

重试不是“从管顶重来”，而是 Retry 策略在上行阶段重新调用它的内层 next。所以总计时器跨所有重试持续在跑（它在 Retry 外面，只启动一次），而单次计时器每次重试都重新建（它在 Retry 里面）——这正是“总超时在外、单次超时在内”的运行时含义。
熔断开路时，它在下行就短路：状态为开时，熔断策略根本不调 next，直接返回失败——下游一个请求都收不到。这就是“保护下游”的运行时含义。

v8 还在底层引入了一个关键抽象：Outcome<T>——用“结果对象”统一表达“成功值 / 异常”。过去异常控制流和返回值检查是两条路，现在统一成一条：策略拿到的是 Outcome<T>，用同一套 ShouldHandle 谓词决定它算不算“需要处理的故障”。这是 v8 一切简洁性的根基。

四、七大韧性策略

这是 Polly 的核心武器库。其中重试、熔断、超时是“三大件”，必须吃透；其余四个按场景补充。

4.1 重试（Retry）——对抗瞬时故障

最常用，也最容易被滥用。

退避（backoff）：Constant / Linear / Exponential 三种。绝对不要“立即重试”，否则瞬时故障下会形成同步重试风暴。
必须加抖动（Jitter）：UseJitter = true。给每次退避叠加一个随机量，避免大量客户端在同一时刻集体重试（“惊群效应”）。
精确的谓词：ShouldHandle 决定“什么算可重试”。不是所有异常都该重试——4xx 业务错误重试一百次结果也一样，只会浪费配额。
必须有上限：MaxRetryAttempts 必须封顶，否则一次失败被放大成 N 倍流量。
幂等性：重试 GET 很安全；重试 POST 必须带幂等键（Idempotency-Key），否则可能产生重复下单。

4.2 熔断（Circuit Breaker）——在持续故障下保护下游

当依赖真的挂了，重试只会火上浇油。熔断器的职责是主动停止调用，给下游喘息。

三态循环：Closed（正常）→ Open（熔断，请求直接快速失败，不真正调用）→ Half-Open（试探性放行少量请求）→ 判定恢复则 Closed、否则重新 Open。

v8 的熔断是高级实现：它基于“采样窗口内的失败率”（FailureRatio + MinimumThroughput + SamplingDuration），而不是简单的“连续失败 N 次”。这更贴近真实流量——偶尔一两次抖动不会误开熔断，但持续的失败率上升会被及时捕捉。

作用域：熔断是“按下游聚合”的，不是单请求、也不是全 App 一个。 这是最容易误解的地方：

熔断器是有状态机，状态挂在一条 ResiliencePipeline 实例上，被“经过它的所有调用”共享。失败率是跨请求聚合统计的，不是每个请求自己单独算。
但粒度是按下游 / 按 pipeline 隔离：你给 OrderApi 和 InventoryApi 各配一套，各有各的熔断器，一个挂了不会误伤另一个。绝不该让全 App 共用一个 client/pipeline。
单个请求的重试触发不了熔断：虽然标准顺序下每次重试尝试都会被熔断器记一个采样，但开路有吞吐量门槛（MinimumThroughput，标准默认要求窗口内至少约 100 次吞吐）+ 失败率门槛（约 10%）。一个请求的几次重试远凑不齐——要开路，得跨请求集体证明“这个下游不行了”。

和重试对照着看，本质就清晰了：

	重试（Retry）	熔断（Circuit Breaker）
状态	无状态，每次调用自己循环	有状态，跨请求共享
作用域	单次调用内部	整条 pipeline（按下游）
判断依据	“这一次”失败 → 再来	“一段时间内多次调用”的失败率

重试是“单兵作战”，熔断是“全队观察”。

哲学点：熔断不只是“保护下游不被打爆”，更是“给上游一个快速失败（fail-fast）”——与其让请求挂 30 秒超时，不如毫秒级返回失败，把容量留给其他能成功的请求。

4.3 超时（Timeout）——给每次调用一个上限

Polly v8 的 timeout strategy 通过取消令牌通知回调停止，并在超时时抛出 TimeoutRejectedException。回调必须使用 Polly 传入的令牌并支持协作式取消；如果委托忽略令牌，底层工作可能在调用方收到超时后仍继续运行。旧版 Polly 的 optimistic/pessimistic 模式不应套到 v8 API 上。

通常配两层：总超时（包住整个重试过程）+ 每次尝试超时（包住单次调用）。两层都不可少。

4.4 对冲（Hedging）——对抗尾延迟

针对 p99 抖动：发出第一个请求，若在 Delay 内没返回，就并行再发一个，谁先回用谁。在 p99 严重的系统里（想想 Jeff Dean 那张“延迟尾部放大”图），对冲能把慢请求的尾部显著拉平。代价是多打流量，只适合幂等或廉价的调用。它对应 HttpClient 侧的 AddStandardHedgingHandler。

4.5 限流（Rate Limiter）——控制自身或下游速率

基于 System.Threading.RateLimiting 的 limiter。客户端侧限流既可保护下游，也可避免自己过快消耗配额；具体是速率还是并发约束取决于所配置的 RateLimiter。

4.6 并发限制（Concurrency Limiter，舱壁思路）——故障隔离与容量保护

限制并发执行数，超出时快速拒绝而非排队堆积。它的核心价值是隔离：把不同依赖放进不同“舱室”，一个慢依赖拖不垮整艘船——避免一个慢下游占满线程池/连接池，导致整个进程假死。

4.7 降级（Fallback）——优雅失败

所有策略都兜不住时，返回一个默认值、缓存或兜底逻辑，让用户看到“降级但可用”的结果，而不是刺眼的 500。这是用户体验的最后一道防线。

五、组合：管线顺序就是语义

策略本身只是积木，怎么排列它们决定了语义。这是 Polly 最容易被用错的地方。.NET 8 标准韧性管线给出的“出厂正确顺序”（由外到内）是：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


Rate / Concurrency Limiter ← 入口：先控制进入管线的并发
 ↓
Total Timeout ← 总超时：包住整个重试过程
 ↓
Retry ← 重试：处理瞬时故障
 ↓
Circuit Breaker ← 熔断：持续故障时让重试快速失败
 ↓
Attempt Timeout ← 内层：单次尝试的时限
 ↓
你的业务调用

每一层的位置都有理由：

限流/舱壁在最外：在进入任何重试逻辑前先控制并发与速率，防止“重试放大流量”冲垮自己。
总超时包住重试：否则 3 次重试 × 每次挂 30 秒，一个请求能拖 90 秒。
重试在熔断之外：每次重试尝试都会经过熔断器；一旦熔断打开，重试会立刻拿到 fast-fail，不真正调用下游，而重试自身的失败计数仍能正常累计。
每次尝试超时在最内：它只约束单次调用，不约束整个重试链。

对冲变体（AddStandardHedgingHandler）则把“重试 + 熔断 + 单次超时”整体塞进对冲策略的内部，外面包一层总超时。

这个“顺序敏感的洋葱模型”，和 DelegatingHandler、ASP.NET Core 中间件完全同构。理解了管线的语义，就理解了 .NET 一大类框架的设计语言。

六、配置驱动：Options 与 Registry

v8 支持通过 DI 集中注册命名管线。下面是集中配置示例；若要从配置文件绑定或动态重载，需要额外使用 options/配置集成，不能仅凭这段代码自动获得热更新：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20


// 在 DI 中集中注册一条命名管线
builder.Services.AddResiliencePipeline("order-api", pipeline =>
 pipeline.AddRetry(new RetryStrategyOptions
 {
 MaxRetryAttempts = 3,
 BackoffType = DelayBackoffType.Exponential,
 UseJitter = true
 })
 .AddCircuitBreaker(new CircuitBreakerStrategyOptions { FailureRatio = 0.5 })
 .AddTimeout(TimeSpan.FromSeconds(10)));

// 取用
public class OrderClient(ResiliencePipelineProvider<string> provider)
{
 public async Task DoAsync()
 {
 await provider.GetPipeline("order-api")
 .ExecuteAsync(static async ct => await Task.Delay(100, ct));
 }
}

好处是阈值和管线构造集中管理、业务代码只按 key 取用。是否启动时校验、是否支持动态重载，取决于采用的 options 注册与 reload 机制。

七、可观测性：v8 最大的飞跃

Polly v8 会为管线与策略生成遥测事件；使用 Microsoft.Extensions.Resilience 集成时，可通过日志和 System.Diagnostics.Metrics 接入观测系统，并用 telemetry options 配置严重级别、监听器与标签。不存在一个适用于本文所有构建方式的通用 .EnableTelemetry() 开关。

重试了几次、每次因为什么失败；
熔断器的状态切换（Closed → Open → Half-Open）；
超时、限流、舱壁拒绝的计数。

这些指标可以直接进 OpenTelemetry / Prometheus / Grafana 仪表盘。

为什么这很重要？看不见的韧性是危险的。 一个配错的熔断器可能静默地把一半流量快速失败，而你在告警里只看到“错误率升高”却无从定位。v8 把可观测性作为一等公民，让韧性可监控、可调优、可归因——这是它从“库”升级为“基础设施”的标志。

八、与 HttpClient 合流：Microsoft.Extensions.Http.Resilience

回到姊妹篇。.NET 8 的 Microsoft.Extensions.Http.Resilience 是 Polly v8 与 IHttpClientFactory 的官方桥梁：

1
2


builder.Services.AddHttpClient<OrderApi>(...)
 .AddStandardResilienceHandler(); // 限并发 + 总超时 + 重试 + 熔断 + 单次超时

AddStandardResilienceHandler / AddStandardHedgingHandler 把预配置的 v8 管线接进 HttpClient 出站管线，但并不等于启用 Polly 的“全部策略”；fallback 等需求仍需自定义。官方还建议一个 client 只配置一个 resilience handler，避免无意叠加。

九、设计思想：Polly 教会了我们什么

回头看，Polly 的演进浓缩了几个值得带走的思想：

“故障是常态，韧性是工程义务”。 在分布式系统里，容错不是可选优化，而是基本功。把重试/熔断当业务逻辑的一部分来设计，而不是事后补丁。
“策略即管线，组合优于硬编码”。 和 HttpClient、ASP.NET Core 一脉相承——把横向关注点拆成可插拔的策略，按顺序组合，而不是在每个调用点重复 try/catch。
“Outcomes over exceptions”。 v8 用 Outcome<T> 统一表达成败，摆脱“用异常做控制流”的旧范式。这是更健康、更易组合的失败模型。
“可观测的韧性”。 看不见就调不了。把可观测性内置进框架，让韧性从黑盒变成仪表盘上的一等指标。
“对下游负责”。 熔断、限流、舱壁，本质都是“自我约束以保护整个系统”。一个有责任感的客户端，应当主动限制自己，而不是无限重试把下游压垮。

十、决策与避坑清单

按故障选策略：

你遇到的问题	用
偶发网络抖动 / 短暂 5xx	Retry + Jitter
依赖持续故障	Circuit Breaker
请求偶发慢 / p99 高	Hedging
自己被打爆 / 保护下游配额	Rate Limiter
一个慢依赖拖垮全盘	Bulkhead
想给用户兜底体验	Fallback
任何调用都必须有	Timeout

常见坑：

重试风暴：无 jitter + 无退避，瞬时故障下集体同步重试。
重试不可幂等的 POST 不带幂等键 → 重复下单。
有重试、有单次超时，却忘了总超时 → 单请求拖到天荒地老。
熔断阈值设太敏感（正常抖动就开）或太迟钝（形同虚设）。
把 4xx 业务错误当成“可重试故障”。
韧性策略没开 telemetry，上线即黑盒，出事无从定位。

结语

Polly 从一个“重试库”长成了“.NET 韧性工程的基础设施”。v8 的 ResiliencePipeline 范式重构，让韧性统一、可配置、可观测——这三点，恰恰是生产级分布式系统最需要的。

当你下一次写出 AddStandardResilienceHandler() 时，背后是一套经过千锤百炼的韧性工程语言：重试带抖动、熔断保护下游、超时封顶延迟、一切皆可观测。理解了这套语言，你写出的就不再是“能跑的代码”，而是“对下游负责、对自己克制、对故障坦然”的分布式客户端。

参考资料

后端架构实战（八）：落地——用 ASP.NET Core 搭一个微服务骨架

Tue, 08 Apr 2025 10:00:00 +0800

写在前面

前七篇全是道理：权衡、单体、拆分、分布式税、一致性、通信、可观测性。这一篇把理论落成代码——用 ASP.NET Core 搭一个最小可用的微服务骨架。

它不会是一个完整生产系统，但会覆盖微服务的"承重墙"：项目结构、依赖注入、API 网关、健康检查、弹性（Polly）、可观测性（OpenTelemetry）。每一处都对应前面某一篇讲过的道理。

前置：本篇假设你读过我的《ASP.NET Core 学习笔记》系列（中间件管道、DI、认证授权）。基于 .NET 8 LTS。

一、整体结构

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


一个最小微服务系统（4 个工程）：

 Gateway/ API 网关（YARP，统一入口、路由、鉴权）
 OrderService/ 订单服务（业务 A）
 InventoryService/ 库存服务（业务 A 的依赖）
 Shared/ 少量稳定的传输契约（需独立版本化，避免共享领域模型）

 对应前文：
 拆分（第三篇）→ 按领域切 Order / Inventory
 通信（第六篇）→ 网关 + 服务间 HTTP
 分布式税（第四篇）→ 健康检查、Polly 弹性
 可观测性（第七篇）→ OpenTelemetry 串联

1
2
3
4
5
6
7
8


工程依赖方向（单向，严禁循环）：
 Gateway ──→ Shared
 OrderService ──→ Shared
 InventoryService ──→ Shared
 OrderService ──调用──→ InventoryService（运行时 HTTP，非编译依赖）

 关键：服务间运行时依赖走网络，编译期互不引用
 → 这样才能独立编译、独立部署。

二、每个服务的内部分层

单个服务内部，按职责分层（不是按"被拆成服务"的技术层——区别于第三篇的反模式）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


OrderService/
├── OrderService.Api/ 表现层（Controller / 最小 API）
│ └── 引用 Application、Domain
├── OrderService.Application/ 应用层（用例、编排、接口定义）
│ └── 引用 Domain
├── OrderService.Domain/ 领域层（实体、领域服务、规则）
│ └── 不依赖任何人（依赖倒置的核心）
└── OrderService.Infrastructure/ 基础设施（DB、外部调用、实现）
 └── 引用 Application（实现接口）

 依赖方向永远向内，Domain 在最中心、不依赖任何层。
 这是"整洁架构/洋葱架构"的思路，保证领域逻辑纯净。

三、依赖注入：组装一切

ASP.NET Core 的 DI 是一等公民（见我的 ASP.NET Core 笔记一）。微服务里，所有跨层依赖都通过 DI 注入，这样才好测试、好替换。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


// OrderService.Application/Dependencies.cs
public static class Dependencies
{
 public static IServiceCollection AddOrderServices(this IServiceCollection services)
 {
 // 应用层服务
 services.AddScoped<IOrderService, OrderService>();
 // 端口适配器：接口在 Application，实现在 Infrastructure
 services.AddScoped<IInventoryClient, InventoryClient>();
 services.AddScoped<IOrderRepository, OrderRepository>();
 return services;
 }
}

// OrderService.Api/Program.cs
var builder = WebApplication.CreateBuilder(args);
builder.Services.AddOrderServices(); // 业务服务
builder.Services.AddControllers();
builder.Services.AddHealthChecks(); // 健康检查（第五节）
builder.Services.AddHttpClientPolicies(); // Polly 弹性（第六节）

var app = builder.Build();
app.MapControllers();
app.MapHealthChecks("/health"); // 暴露健康检查端点
app.Run();

单元测试里可以替换 IInventoryClient 为 mock，这就是第四篇《.NET 单元测试：依赖注入与可测试性》的价值。

四、API 网关：YARP 统一入口

对外不直连各服务，用网关收口（第六篇）。.NET 生态用 YARP（Yet Another Reverse Proxy，微软出品，比 Ocelot 更现代）。

1
2
3
4
5
6
7
8


// Gateway/Program.cs
var builder = WebApplication.CreateBuilder();
builder.Services.AddReverseProxy()
 .LoadFromConfig(builder.Configuration.GetSection("ReverseProxy")); // 路由放配置

var app = builder.Build();
app.MapReverseProxy(); // 网关入口
app.Run();

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


// Gateway/appsettings.json —— 路由配置
{
 "ReverseProxy": {
 "Routes": {
 "order-route": {
 "ClusterId": "order-cluster",
 "Match": { "Path": "/api/orders/{**catch-all}" }
 },
 "inventory-route": {
 "ClusterId": "inventory-cluster",
 "Match": { "Path": "/api/inventory/{**catch-all}" }
 }
 },
 "Clusters": {
 "order-cluster": {
 "Destinations": {
 "d1": { "Address": "http://order-service:8080/" }
 }
 },
 "inventory-cluster": {
 "Destinations": {
 "d1": { "Address": "http://inventory-service:8080/" }
 }
 }
 }
 }
}

1
2
3
4
5
6


网关集中处理（不在每个服务里重复）：
 - 路由（/api/orders → 订单服务）
 - 鉴权（统一验 token）
 - 限流、熔断
 - 协议转换
 生产环境再配多实例 + 负载均衡，保证网关本身高可用。

五、健康检查：编排的基础

K8s 和负载均衡器靠健康检查决定"流量往哪打"（第四篇分布式税）。ASP.NET Core 内置 HealthCheck。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32


// 自定义健康检查：探测下游依赖
public class InventoryHealthCheck : IHealthCheck
{
 private readonly IInventoryClient _client;
 public InventoryHealthCheck(IInventoryClient client) => _client = client;

 public async Task<HealthCheckResult> CheckHealthAsync(
 HealthCheckContext context, CancellationToken ct = default)
 {
 try
 {
 var ok = await _client.PingAsync(ct);
 return ok ? HealthCheckResult.Healthy("inventory reachable")
 : HealthCheckResult.Degraded("inventory slow");
 }
 catch
 {
 return HealthCheckResult.Unhealthy("inventory down");
 }
 }
}

// 注册
builder.Services.AddHealthChecks()
 .AddCheck<InventoryHealthCheck>(
 "inventory",
 failureStatus: HealthStatus.Unhealthy,
 tags: ["ready"]);

// 分别暴露存活探针 / 就绪探针（K8s 标准用法）
app.MapHealthChecks("/health/live", new() { Predicate = _ => false }); // 进程活着
app.MapHealthChecks("/health/ready", new() { Predicate = r => r.Tags.Contains("ready") });

1
2
3
4
5


K8s 里：
 livenessProbe → /health/live （进程活着吗）
 readinessProbe → /health/ready （依赖就绪、能接流量吗）
 就绪探针失败 → K8s 把该实例摘出流量，但不重启；
 存活探针失败 → K8s 重启容器。

六、弹性：Polly 应对分布式税

跨网络调用要定义截止时间、并发和失败策略；重试与熔断并非越多越好。.NET 8 可用 Microsoft.Extensions.Http.Resilience（基于 Polly v8）配合 HttpClientFactory。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


// 需安装 Microsoft.Extensions.Http.Resilience
builder.Services.AddHttpClient<IInventoryClient, InventoryClient>(client =>
{
 client.BaseAddress = new("http://inventory-service:8080/");
})
.AddStandardResilienceHandler(options =>
{
 options.TotalRequestTimeout.Timeout = TimeSpan.FromSeconds(5);
 options.AttemptTimeout.Timeout = TimeSpan.FromSeconds(2);
 options.Retry.MaxRetryAttempts = 2;
 options.Retry.DisableForUnsafeHttpMethods(); // 写请求默认不自动重试
});

1
2
3
4
5


这几行代码对应第四篇的整笔账：
 超时 → 别傻等慢服务
 重试 → 只处理适合重试的瞬时故障；写请求需先具备幂等键或去重语义
 熔断 → 库存服务挂了，订单服务直接快速失败，不耗尽自己的线程池
 → 切断雪崩的放大效应

七、可观测性：OpenTelemetry 串联

第七篇的链路追踪，几行代码接入。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


// 各服务统一接入 OpenTelemetry
builder.Services.AddOpenTelemetry()
 .WithTracing(tp => tp
 .AddAspNetCoreInstrumentation() // 自动追踪 HTTP 入站
 .AddHttpClientInstrumentation() // 自动追踪 HttpClient 出站
 .AddSqlClientInstrumentation() // 自动追踪 DB 调用
 .AddOtlpExporter()); // 导出到 OTel Collector

builder.Logging.AddOpenTelemetry(o =>
 o.AddOtlpExporter()); // 活动上下文中的日志可关联 TraceId/SpanId

1
2
3
4
5


效果：一次"下单"请求
 网关(span) → 订单服务(span) → 库存服务(span) → DB(span)
 在采样、传播和各段 Instrumentation 正确配置时可连成一条 trace；异步消息还需显式传播上下文。
 Jaeger 里一眼看到哪一段慢。
 → 这就是第七篇说的"微服务神经系统"，接入成本极低。

八、配置与外部化

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


每个服务的配置分环境（开发/测试/生产）外置：
 appsettings.json —— 默认值
 appsettings.Production.json —— 生产覆盖
 环境变量 / K8s ConfigMap / Secret —— 敏感和环境相关

 builder.Configuration
 .AddJsonFile("appsettings.json")
 .AddJsonFile($"appsettings.{env}.json", optional: true)
 .AddEnvironmentVariables(); // 环境变量优先级最高，适合容器

 分布式税里的"配置中心"（Nacos/Apollo）在规模上来后再引入，
 小系统先用环境变量 + ConfigMap 足够。

九、把前七篇串起来

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


这个骨架里，每一处都对应前面某一篇：

 工程结构、依赖方向 ← 第三篇：按领域切，单向依赖
 DI 注入一切 ← 可测试性（ASP.NET Core 笔记四）
 YARP 网关 ← 第六篇：统一入口、路由、鉴权
 健康检查 ← 第四篇：编排基础（K8s 探针）
 Polly 超时/重试/熔断 ← 第四篇：弹性，防雪崩
 OpenTelemetry ← 第七篇：可观测性神经系统
 服务间 HTTP + 幂等 ← 第五、六篇：一致性 + 通信
 配置外置 ← 第四篇：分布式税中的配置

 这就是一个"承重墙齐全"的微服务起点。
 业务往上长，基础设施已就位。

十、回到第一篇：要不要这么做

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14


最后，回到系列第一篇的"权衡"：

 这个骨架是"当你要做微服务时"的标准起手式。
 但你要不要做微服务，回到那几个问题：

 - 团队是不是大到需要拆分协作？
 - 是不是有独立扩容 / 独立发布 / 故障隔离的真实需求？
 - 有没有 K8s + CI/CD + 可观测性的运维能力？

 如果没有 → 第二篇的"模块化单体"才是你的答案。
 把这套骨架的"DI + 分层 + 健康检查 + 可观测性"
 用在单体内部，一样成立，还省了网络和分布式税。

 记住：技术选型服务于问题和约束，不是反过来。

十一、系列小结

八篇下来，一条主线：

（一）架构是权衡：没有银弹，一切看约束
（二）单体被低估：模块化单体是大多数团队的起点
（三）拆分看领域：按业务切，不按技术层切
（四）分布式要收税：网络、一致性、可观测、运维，样样要自建
（五）一致性靠模式：核心收敛强一致，周边用最终一致 + Saga + Outbox
（六）通信看同步异步：REST/gRPC 与消息队列各擅其场
（七）可观测性是神经：日志 + 指标 + 链路，traceId 串联
（八）落地 ASP.NET Core：把理论变成可跑的代码

架构没有终点。系统会演进，约束会变化，今天的最优解是明天的技术债。保持权衡的思维、演进的视角、记录决策的习惯——这才是这套系列想留给你的，比任何具体技术都重要的东西。

后端架构实战（四）：微服务的“分布式税”——你准备好买单了吗

Mon, 31 Mar 2025 10:00:00 +0800

写在前面

前三篇我一直在"劝退"过早微服务化，不是反对微服务，是想让你想清楚再拆。这一篇就把账算明白：拆成微服务之后，你到底要为哪些隐性成本买单。

我把这些成本叫做“分布式税”——单体里免费的东西，到了分布式环境，每一项都要你自己花人、花钱、花时间重新建起来。

一、什么叫"分布式税"

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


单体里（进程内）免费的能力：

 - 函数调用 = 直接 new、直接调，纳秒级
 - 强一致性 = 一个数据库事务搞定
 - 配置 = 读本地配置文件
 - 日志 = 写同一个文件
 - 鉴权 = 一个进程内的中间件
 - 故障传播 = 进程挂了，全挂（简单粗暴）

微服务里（跨网络）每一项都要重新建：

 - 函数调用 → 网络调用（毫秒级、会超时、会丢包）
- 同库事务 → 跨服务一致性设计（可能采用 Saga、TCC、Outbox、对账或分布式事务）
 - 配置 → 配置中心（集中下发、动态刷新）
 - 日志 → 日志聚合（收集到统一存储）
 - 鉴权 → 每个服务都要验 token
 - 故障 → 一个挂了，可能雪崩倒一片

 这些"重建"，就是分布式税。

二、第一笔税：网络根本不可靠

这是分布式系统一切痛苦的根源。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


进程内调用 vs 网络调用：

 进程内调用：
 ✓ 几乎不会失败（除非进程崩）
 ✓ 纳秒~微秒级
 ✓ 没有序列化开销

 网络调用：
 ✗ 会超时（对方慢、网络抖动）
 ✗ 会丢包、会重试、会乱序
 ✗ 毫秒级起步，还要序列化
 ✗ "超时"最可怕——不知道对方到底执行了没有

 八大谬误（Peter Deutsch）：
 1. 网络是可靠的 ❌
 2. 延迟为零 ❌
 3. 带宽是无限的 ❌
 4. 网络是安全的 ❌
 5. 拓扑不会变化 ❌
 6. 只有一个管理员 ❌
 7. 传输成本为零 ❌
 8. 网络是同构的 ❌

代价：每一次跨服务调用都要定义超时与失败语义；是否重试、要求何种幂等、能否降级，要按操作和业务风险决定。try-catch 本身在单体中也不能解决事务与恢复问题。

网络为什么不可靠、CAP 为什么成立——我在《分布式系统学习笔记（一）：CAP 与一致性》里讲过底子。这里只说工程后果。

三、第二笔税：服务发现与配置

单体里，所有代码在一个进程，互相调函数即可。微服务里，“找谁"和"用什么配置"成了问题。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


单体：函数地址 = 编译期固定
微服务：服务实例的 IP/端口是动态的（容器漂移、弹性扩缩）

必须明确由平台、云服务或团队承担的能力：
 - 服务注册与发现（谁在线、在哪）
 常见：Consul / Nacos / etcd / K8s Service / Eureka
 - 配置中心（配置不再散落各服务）
 常见：Nacos / Apollo / Consul KV / K8s ConfigMap
 - 动态刷新（改配置不重启）

 这些都是单体里"不存在"的基础设施。

四、第三笔税：数据一致性

这是最重的一笔税，下一篇会专门展开，这里先列账：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


单体：一个事务保证 ACID
微服务：每个服务一个库，跨库没有 ACID

你必须明确选择或建设：
 - 分布式事务方案（Saga、TCC、Outbox 模式）
 - 最终一致性补偿机制
 - 幂等性保证（重试导致的重复执行）
 - 对账机制（数据不一致时的人工/自动核对）

 详见我写的《分布式系统学习笔记（四）：分布式事务》。
 本系列第五篇会讲它怎么在数据架构上落地。

五、第四笔税：可观测性

单体里，一个请求的处理在一个进程内，看一个日志文件就懂了。微服务里，一个请求要经过 5 个服务，出问题你怎么定位？

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


必须具备可观测性“神经系统”，可自建也可使用托管服务：

 - 链路追踪（Trace）
 给每个请求一个 traceId，跨服务透传
 常见：OpenTelemetry / Jaeger / Zipkin / SkyWalking

 - 指标监控（Metrics）
 每个服务的 QPS、延迟、错误率
 常见：Prometheus + Grafana

 - 日志聚合（Logs）
 所有服务的日志收到一处，按 traceId 串联
 常见：ELK / Loki

 没有这三件套，微服务一旦出问题 = 黑盒，只能玄学排查。
 第七篇会专门讲可观测性。

六、第五笔税：可靠性与弹性

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


单体里：一个函数失败 → 抛异常，调用方决定怎么办
微服务里：一个服务失败 → 故障会沿调用链放大，可能雪崩

必须按调用风险配置：
 - 超时（Timeout）—— 别傻等
 - 重试（Retry）—— 配合幂等
 - 熔断（Circuit Breaker）—— 别打已经挂的服务
 - 限流（Rate Limit）—— 别被流量压垮
 - 降级（Fallback）—— 给个兜底响应
 - 舱壁隔离（Bulkhead）—— 别让一个慢调用拖垮线程池

 .NET 生态：Polly（这套东西几乎成了标配）
 本系列第八篇落地时会用上。

1
2
3
4
5


雪崩示意：
 服务 A 依赖 B，B 依赖 C
 C 慢了 → B 的线程被占满 → B 也慢 → A 的线程被占满 → A 也挂
 一个底层小故障，逐层放大，拖垮整条链路。
 熔断 + 舱壁就是用来切断这种放大效应的。

七、第六笔税：运维与部署

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


单体运维：1 个应用 × N 台机器
微服务运维：M 个服务 × N 个实例 × 动态变化

 - 需要容器化（Docker）+ 编排（K8s）
 见我写的 Docker / K8s 系列
 - 需要 CI/CD（每个服务独立构建、独立发布）
 - 需要版本兼容（新老接口并存期）
 - 需要 API 网关（统一入口、鉴权、限流）
 - 需要 DevOps 能力（SRE 文化）

 团队没有这些能力，上微服务 = 上灾难。

八、账单汇总：值得吗

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


拆成微服务，你要新增的基础设施清单：

 □ 服务注册发现 □ 配置中心
 □ API 网关 □ 分布式事务/一致性
 □ 链路追踪 □ 指标监控
 □ 日志聚合 □ 熔断/限流/重试（Polly）
 □ 容器编排（K8s） □ CI/CD 流水线
 □ 幂等 + 对账 □ 版本兼容策略

 收益（只有规模到了才兑现）：
 ✓ 独立部署、独立扩容、技术栈解耦、故障隔离、团队解耦

 判断标准：
 规模/团队/解耦需求 带来的收益 > 上面这份税单 → 拆
 否则 → 老老实实模块化单体

 这就是第一篇说的"权衡"。

九、小结

分布式税：单体里免费的能力，微服务里每一项都要自建
网络不可靠是根源：每次跨服务调用都要处理超时/重试/幂等/降级
服务发现 + 配置中心：解决"找谁"和"用什么配置”
数据一致性是最重的税：Saga/最终一致/幂等/对账（下一篇详谈）
可观测性：链路追踪 + 指标 + 日志，否则微服务是黑盒
弹性：超时/重试/熔断/限流/降级/舱壁，防止雪崩
运维：K8s + CI/CD + 网关 + 版本兼容
决策：只有当解耦收益 > 这份税单，才值得拆

下一篇，把最重的一笔税——分布式数据一致性——彻底讲透。