/tags/data-mesh/ Recent content in data-mesh on Hugo -- gohugo.io en Mon, 04 May 2026 10:00:00 +0800 /posts/microservices-boundary-governance-2019-2026/ Mon, 04 May 2026 10:00:00 +0800 /posts/microservices-boundary-governance-2019-2026/ 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、批量部署，再用配置系统灰度打开。