2023 年，Amazon Prime Video 公开了一个架构优化案例：他们把一个音视频质量监控 pipeline 从分布式 serverless 组件合并成单进程应用，运营成本降了 90%。很多转述把它概括成「Amazon 放弃微服务」，但这恰恰是最没有价值的读法。

更有价值的问题是：为什么这些大公司在不同阶段做出了完全不同的架构选择？为什么有的继续扩展几千个微服务，有的把某条链路合并回进程内，有的坚持模块化单体，有的把治理重点从服务迁移到 cell、supergraph、data contract？

下面这七个案例不是为了证明「微服务好」或「单体好」。它们更像七个坐标点，帮助我们判断：在什么规模、约束和组织形态下，服务边界的收益还能不能覆盖它带来的成本。

七个案例#

Amazon Prime Video — 把一条高吞吐 pipeline 合并回单进程（2023）#

做了什么： Prime Video 的 Video Quality Analysis 团队原本用 Step Functions、Lambda、S3 等 serverless 组件串起音视频质量检测流程。后来他们把媒体转换、检测器和编排逻辑合并到一个进程内运行，部署在 ECS/EC2 上，减少了中间数据搬运和编排状态跳转。

为什么： 主要瓶颈不是业务计算，而是编排和数据移动成本。每秒视频流会触发多次 Step Functions state transition，容易撞到账户限制；视频帧通过 S3 在组件之间传递，读写量和费用都很高。合并后，帧数据在内存里传递，编排逻辑也从外部状态机变成进程内控制流。

容易被误读的地方： 这不是 Prime Video 放弃微服务，而是一个特定工作负载上的边界重画。这个案例的价值在于提醒我们：当一条链路里的数据移动和编排开销超过业务计算本身时，服务拆分就不再是免费的抽象，而是可以被量化的成本。

Monzo — 接近 3,000 个微服务后的中央治理（2022–2026）#

做了什么： Monzo 长期运行大规模 Go 微服务。2022 年他们公开提到 2,000+ 服务；2024 年迁移文章里数字已经到 2,800+；同年另一篇限流文章把规模描述为接近 3,000 个微服务。

关键在哪： Monzo 的重点不是「服务数量多很厉害」，而是他们选择了高度一致的技术栈、monorepo、统一平台和中央驱动迁移。比如把 tracing 从 OpenTracing/Jaeger SDK 迁到 OpenTelemetry SDK 时，Monzo 不是让每个服务 owner 自己慢慢改，而是由一个团队设计 wrapper、自动化修改 call site、批量部署，再用配置系统灰度打开。

额外背景： 银行业务的监管、安全和可审计要求，让 Monzo 对隔离、权限、变更控制和可观测性的要求高于普通互联网应用。它说明了一件事：几千个微服务不是靠「大家自觉」跑起来的，而是靠平台把一致性做成默认路径，把全局迁移做成可重复能力。

DoorDash — 从微服务迁移到 cell + service mesh（2019–2025）#

做了什么： DoorDash 从 2019 年开始把 Django 单体迁到微服务。公开文章里，他们把这段迁移描述为 2019–2023 年的核心转型；后续又在微服务之上叠加 cell-based architecture 和 Envoy service mesh。到 2025 年，DoorDash 的 service mesh 已经支撑峰值 8,000 万 requests/sec，并迁移了 1,000+ 微服务。

两个独立教训：

  1. 从单体拆到微服务，只是第一层问题。早期痛点包括服务间通信模式不统一、可靠性能力不一致、重试风暴和级联故障。
  2. 微服务边界不等于故障隔离边界。DoorDash 的 cell 架构把服务部署进隔离 cell，cell 间不允许随意通信；service mesh 又提供 zone-aware routing、outlier detection、adaptive concurrency 等流量治理能力。

为什么有代表性： DoorDash 的故事比「从单体到微服务」更完整。它展示了很多公司都会经历的第二阶段：微服务增加了团队自治，但也放大了网络、流量和故障传播问题。后续真正的工作会转向部署拓扑、服务发现、mesh、观测和自动化迁移。

Shopify — 模块化单体不是银弹，但仍是长期选项（2019–2024）#

做了什么： Shopify 没有把核心 Rails 应用默认拆成微服务，而是持续投入模块化单体。早期他们通过 Components 按业务域拆出内部边界，后来开源 Packwerk，用静态分析帮助 Rails 应用约束 package 依赖和隐私边界。

反直觉的地方： Shopify 的选择不是「还没来得及拆」，而是明确反对用网络边界解决代码设计问题。把一个糟糕的内部 API 放到另一个服务里，并不会让它自动变好；它只会额外引入序列化、网络可靠性、部署协调和观测成本。

2024 年的修正： Shopify 后来的 Packwerk retrospective 也很重要。他们承认工具会把人带向一个理想化的依赖图，但真实代码往往按运行路径和业务压力演化，不一定贴合最初设想的领域边界。Packwerk 在 Shopify 已不再像最初那样中心化，但仍在一些基础层依赖治理上有价值。

这个案例的价值： 模块化单体是合法的长期选择，但前提是团队真的愿意维护边界。它不是「单体什么都不管」，而是在同一进程、同一部署单元里，用工具、代码组织和团队纪律换取更低的分布式系统成本。

Uber — DOMA：给 2,200 个微服务加层次（2020）#

做了什么： Uber 在约 2,200 个关键微服务上提出 Domain-Oriented Microservice Architecture（DOMA）。它不是继续鼓励横向拆服务，而是把服务组织成 domain、layer、gateway 和 extension。

核心洞察： 微服务数量过了几百个之后，主要矛盾往往从基础设施转向认知负荷。开发者很难知道该调哪个服务、哪个团队拥有哪个领域、改一个功能会跨多少依赖。DOMA 的答案是：不要只看叶子服务，要把相关服务归入领域，并通过 domain gateway 提供稳定入口。

结果信号： Uber 公开提到，他们把 2,200 个微服务归类到 70 个 domain，平台使用者过去需要调用多个下游服务，现在可以通过一个 domain gateway 接入；某些平台的新人上手（Onboarding）周期降低了 25%–50%。

这个案例的价值： 当服务数量本身开始延长上手周期、增加排查和集成难度，继续拆服务通常不是解法。更有效的是给服务图增加层次，把「一堆点」变成「有边界的领域」。

Netflix — 从 API 聚合单体到 federated supergraph（2019–2024）#

做了什么： Netflix 的 API 层经历了多代演进：早期不同客户端和 API 平台逐渐形成复杂聚合层，后来在 Studio 和 Consumer Edge 场景中采用 GraphQL Federation，把单一 API 聚合团队维护的复杂层，转向多个 domain team 拥有 subgraph、平台团队维护联邦基础设施和治理能力的 supergraph。

关键在哪： Federation 的价值不是「GraphQL 比 REST 高级」，而是把聚合层的所有权重新分配。每个领域团队可以维护自己的 schema 和 resolver，平台团队负责 DGS framework、schema workflow、兼容性治理、观测、安全和联邦网关。

容易写错的地方： 这不是平台团队统一维护所有 API 契约。更准确地说，是平台团队把契约生产和治理流程平台化，让领域团队能拥有自己的图，同时又能组合成一个统一s消费者视图。

这个案例的价值： 当 BFF 和 API gateway 变成另一个 monolith，问题不一定在 gateway 这个模式本身，而在所有权集中。Netflix 的方向是把 API 聚合层也做成分布式所有权，但用平台能力保证它不会重新退化成混乱的服务图。

Grab — 服务拆完之后，数据契约成为新的边界（2025–2026）#

做了什么： Grab 运行 1,000+ 微服务，并在 2025 年公开了从 Consul/Catcher 向 Istio 演进 service mesh 的过程。到 2026 年，Grab 又公开了 Data Mesh / Signals Marketplace 的平台化实践：用 Hubble 做数据发现和治理，用 Genchi 做数据质量观测，用 Data Contract Registry 管理生产者和消费者之间的数据契约。

为什么放在微服务演进里： 微服务强调服务和数据所有权，但当组织继续扩大，问题会从「服务归谁」延伸到「跨域数据能不能被信任」。Grab 的 Data Contract Registry 把数据形状、语义、质量、SLA 和生命周期做成版本化契约；Genchi 持续验证 freshness、volume、schema、业务规则；Hubble 再把所有权、血缘、契约和认证状态暴露给消费者。

2026 年的信号： Grab 说这些平台支撑的是数十万级的数据资产，包括 datasets、streams、attributes 和 metrics。2024 年 Signals Marketplace campaign 之后一年，P80 datasets 数量下降超过 58%，也就是大量查询开始收敛到更少、更可信、更受治理的数据资产上。

这个案例的价值： 这说明微服务演进到后期，边界治理不会停在 RPC 和部署上。数据也需要契约、所有权、观测和自动化变更通知。否则服务边界虽然清楚了，数据消费仍然会退化成部落知识、隐式依赖和突然 break 的下游报表。

跨公司能看到哪些共性信号#

整理完这七个案例，我看到的不是一个单一趋势，而是几个反复出现的判断标准。

1. 服务边界是经济决策，不是意识形态

Prime Video 的合并、Shopify 的模块化单体、DoorDash 的 mesh 投入，本质都在算同一笔账：这个边界带来的独立部署、扩展、隔离和所有权收益，是否大于网络、序列化、观测、治理和认知成本。

边界也不是一次性决定。某个阶段应该拆，另一个阶段可能应该合并；某个业务域适合进程内模块，另一个业务域可能必须成为独立服务。

2. 微服务规模化之后，平台标准化会压倒个人自由

Monzo、DoorDash、Grab 都在说明：服务多了以后，单靠团队自治会失控。真正能跑几千个服务的组织，通常会反过来收紧技术选择、模板、发布、观测、配置和迁移方式。

这不是反自治，而是把重复的工程判断沉到平台里。平台越成熟，业务团队越能专注在业务差异上，而不是每个团队都重新发明 service discovery、限流、tracing、contract testing。

3. 服务数量过大后，分层比继续拆服务更有效

Uber 的 DOMA 和 Netflix 的 supergraph 说的是同一类问题：当系统里到处都是服务和 API，开发者需要的不是更多端点，而是更少、更稳定、更符合领域认知的入口。

domain gateway、subgraph、supergraph、data product，本质都是在服务 and 数据之上再抽一层人能理解的边界。

4. 故障隔离越来越依赖部署拓扑，而不只是代码边界

微服务提供代码和发布边界，但故障传播经常发生在流量、重试、依赖、配置和共享基础设施上。DoorDash 的 cell-based architecture、zone-aware routing、service mesh 说明：真正的 blast radius 控制，往往需要在部署拓扑和流量层做文章。

这也是为什么「我们已经拆成微服务了」不能自动推出「我们已经有故障隔离了」。

5. 数据契约正在变成微服务之后的新治理焦点

早期微服务讨论的是 service contract 和 database ownership。到了 Grab 这种规模，问题会继续推进到 data contract：一张表、一个 Kafka stream、一个 metric 是否有 owner、schema、SLA、质量检查、血缘和变更通知。

如果这些东西没有平台化，微服务只会把单体数据库里的隐式耦合，搬到数据湖、事件流和分析平台里。

6. 模块化单体仍然是高级选项，但它要求纪律

Shopify 的故事最容易被偷懒地理解成「单体也可以」。更准确的说法是：模块化单体可以是长期选项，但它要靠持续的代码组织、静态检查、团队边界和对运行结果的务实反馈来维持。

清晰的进程内边界，通常比糟糕的网络边界更有价值。

读这些案例的正确姿势#

不要因为 Prime Video 合并了一条 pipeline，就得出「微服务已死」。也不要因为 Monzo 接近 3,000 个微服务，就把服务数量当成熟度指标。

这些案例真正有用的地方，是它们给了我们几种可复用的问法：

  • 这个边界解决的是独立部署、独立扩展、故障隔离、组织所有权，还是只是把代码目录换成网络调用？
  • 数据移动、编排、观测和排障成本有没有被算进去？
  • 服务数量增长后，我们有没有对应的平台标准化能力？
  • 故障隔离靠的是服务拆分，还是有明确的 cell、zone、mesh、限流和回滚机制？
  • 服务和数据的契约是显式、版本化、可验证的，还是靠口头约定和部落知识？
  • 如果不拆服务，只做模块化单体，边界是否真的能被工具和团队纪律守住？

架构演进最怕的是拿别人的结果当自己的答案。更好的方式是拿别人的案例当压力测试：在我们当前的规模、团队、监管、成本和可靠性要求下，这笔经济账是否仍然成立？

参考资料#