微服务比单体架构慢多少？实测数字让工程师大吃一惊

Wotech

Wotech Electronics 博客作者

微服务（Microservices）被誉为"现代"架构，但你可曾想过：为了换取这种灵活性，系统要在性能上付出多大代价？一项刚刚完成的实验给出了具体数字——而且远超许多人的想象。

单体架构（Monolith）与微服务（Microservices）之争在技术圈从未停歇。理论大家都懂：转向微服务，意味着用一部分性能换取团队规模化时的灵活性。但"一部分"究竟是多少？5%？10%？实际上，很少有测试能精确测出这个数字。本文整理了由工程师 Arjay McCandless（前 Amazon 微服务与 Serverless 架构工程师）进行的一项细致而客观的实验，并由吕明光（Lữ Minh Khương）在 VGU Tech Alumni 社群中分享和解析。

一段话看完令人震惊的结果

把一个运行在 8 vCPU（16GB 内存）服务器上的单体应用，拆分成运行在 4 台 2 vCPU（每台 4GB 内存）服务器上的 4 个微服务——硬件总预算同样为每月 112 美元——系统的最大承载能力：

• 使用 HTTP/JSON 时，从 60,000 用户（约 15,400 请求/秒）降至 18,000 用户

• 使用 gRPC 时，达到 19,000 用户

• 即便做了资源分配优化（重新平衡副本，rebalancing replicas）并使用 gRPC，最优的微服务配置也只能达到 30,000 用户——比单台大型服务器上的单体架构性能下降 50%，比横向复制到 4 台小服务器上的单体架构（50,000 用户）低 40%

核心原因在于：数据封装/解码（encoding/decoding）的 CPU 开销、网络连接管理，以及必须用服务之间来回的 API 调用链取代原本直接的 SQL JOIN 语句。

测试方法：公平到每一个细节

为了让实验公平，作者选用了 Conduit——一个类似 Medium 的博客平台，属于 RealWorld 标准 benchmark。用户可以发布文章、互相关注、加载信息流、收藏文章、评论以及管理个人资料。

两个版本都用 Go 语言和标准 HTTP 库编写：

• 单体架构：整个应用运行在一个进程中。

• 微服务：拆分为 4 个独立服务——Users、Profiles、Articles、Comments。

在数据库层面，每个服务拥有各自的数据表：Users 管理用户信息，Profiles 管理关注关系，Articles 管理文章/标签/收藏，Comments 管理评论。4 个服务共用一个 16 vCPU 的 PostgreSQL 集群，但每个服务通过独立的数据库角色（database role）连接，且只能访问自己的表——完全符合微服务的数据所有权（data ownership）原则。

这正是彻底改变数据检索方式的地方：在单体架构中，获取文章并附带作者姓名只需一条 SQL JOIN 语句。而在微服务中，Articles 服务无法直接 JOIN Users 或 Profiles 的表——必须调用相应服务的 API。

测量之前先做彻底优化

为了避免有人归咎于"天真幼稚的设计"，微服务版本做了精心优化：

• 内部 API 支持按 ID 列表批量聚合（batching）——避免经典的 N+1 调用问题

• 请求之间复用连接（connection pooling）

• 令牌验证在本地处理，不产生调用 Auth 服务的额外请求

• 各服务通过同一数据中心（纽约）的内网通信，消除跨区域延迟

• 不使用 API 代理或服务网格（Service Mesh）——不引入任何额外的中间层开销

• 所有配置必须先通过 197 项兼容性测试（conformance checks）才能开始测量

硬件配置与评分标准

应用服务器层（Application Server）的预算固定为 112 美元/月（DigitalOcean；整个集群加上负载生成机器的实际总开销超过 1,500 美元/月）。在这个预算下，有两个等效选择：

前端是一台独立的 8 vCPU 机器运行 Nginx；负载由 3 台独立的负载发生器（load generator）打过来。每 1,000 个虚拟用户大约产生 250–270 请求/秒的混合任务负载：浏览文章、打开个人资料、查看评论，偶尔发布内容。

每种配置的得分 = 系统在 5 分钟内持续承受、且仍满足 SLA 的最大用户数：

• 95% 的请求（p95）响应低于 500ms

• 99% 的请求（p99）响应低于 1 秒

• 错误率低于 1%

分阶段的实验结果

阶段 1：用单体架构建立基准线

在 8 vCPU/16GB 的大型服务器上运行单体架构：系统承载 60,000 用户（约 15,400 req/s）。

接下来，作者对单体架构做横向扩展（horizontally scaled monolith）：在 4 台 2 vCPU 机器上运行 4 个完全相同的副本，由 Nginx 做负载均衡。结果：50,000 用户——比单台大机器下降约 17%，原因是每台机器各自承担操作系统开销、网络开销，以及虚拟化硬件的不一致性。

单体架构的基准线由此确立：60,000 用户（1 台大机器）和 50,000 用户（4 台小机器）。

阶段 2：拆成 4 个服务，但仍在同一台 8 vCPU 机器上运行

为了隔离硬件变量、只测量软件架构本身的纯开销，4 个服务作为 4 个独立进程运行在同一台 8 vCPU 机器上。

• HTTP/JSON：承载能力从 60,000 骤降至 25,000 用户

• gRPC（Protocol Buffers）：达到 29,000 用户

最值得关注的是 CPU 数据：每个公开请求，单体架构只消耗 0.47ms CPU，而微服务 HTTP 版本消耗高达 1.2ms CPU——CPU 工作量增加超过 2.5 倍，即便一切都位于同一台机器上，没有经过任何物理网线。

原因在于：原本在内存中的函数调用（in-process function calls）变成了经由内网的进程间调用。为了返回一篇文章，Articles 服务要调用 Profiles 服务，Profiles 又要调用 Users 服务——每一步都消耗客户端代码、服务端代码、连接管理、JSON 编码/解码以及操作系统的调度。

阶段 3：将 4 个服务部署到 4 台独立服务器上

这是最贴近实际部署形态的模型——每个服务一台 2 vCPU 机器。

• HTTP/JSON：只能承受 18,000 用户

• gRPC：能承受 19,000 用户

与单体架构在完全相同的这 4 台机器上横向复制得到的 50,000 用户相比，下降幅度极其可观。

在检查 CPU 利用率以寻找瓶颈时，作者发现了严重的负载不均：运行 Articles 的机器 CPU 被推到 95%，而 Comments 机器只用到 52%。"每个服务一台机器"的平均分配方式，错误地假设所有服务需要的资源都一样——而现实中浏览文章的流量远高于评论。Comments 机器上富余的 CPU 无法"转移"去支援 Articles。

阶段 4：优化资源分配（Rebalancing）

利用微服务可独立扩展的优势且不增加预算（仍是 4 台 2 vCPU 机器），作者把 Articles 服务的第二个副本部署到正在运行 Comments 的机器上，并重新调整流量分配比例：

• HTTP/JSON：从 18,000 小幅提升至 20,000 用户（每请求 1.27ms CPU）

• gRPC：从 19,000 跃升至 30,000 用户（每请求 0.91ms CPU——比均衡前改善约 58%，CPU 开销比 HTTP 低 28%）

在 4 台小机器上达到 30,000 用户，已逼近微服务在 1 台大机器上的结果（29,000），但仍比 4 台小机器上的单体架构（50,000）低 40%，比 1 台大机器上的单体架构（60,000）低 50%。

结果汇总表

Serverless 和自动扩容能救场吗？

很多人会想到 Serverless（AWS API Gateway + Lambda + DynamoDB）或自动扩缩容的容器方案，用它们来自动补足缺失的算力。但实验数据表明：自动分配资源并不能让额外的处理开销消失。要支撑 15,000 公开请求/秒（单体架构能扛住的负载水平）：

换言之：无论有没有 Serverless 或自动扩容，为处理同样的流量，你都必须支付 2 到近 3 倍的算力费用。

那么，Amazon、Netflix、Facebook 为什么仍然选择微服务？

答案不在服务器性能，而在人和组织的规模（organizational scaling）。

当数百名工程师被分成负责搜索（Search）、计费（Billing）、推荐（Recommendation）等方向的团队时，清晰的服务边界能让每个团队独立地构建、测试、部署、回滚——不必等待统一的发布周期。每个团队还可以为自身问题选择最合适的语言/框架。对于大型组织而言，功能开发速度和团队自主权完全值回新增的基础设施成本。

许多项目踩过的两个坑

• 虚假的独立性（分布式单体，Distributed Monolith）：很多系统拆成了微服务，但每次发布新功能仍需要 4 个团队同时修改 API、按严格顺序部署、管理复杂的版本。结果：丢掉了单体架构的性能，也没得到微服务的独立性——两个世界的好处都没捞着。

• 故障隔离的幻觉（爆炸半径隔离，Blast radius isolation）：理论上，一个服务出故障不会拖垮整个系统。但如果缺乏容错设计（fault tolerance、优雅降级 graceful degradation），一个像 Users 这样的核心服务出现事故，依然会让所有依赖它的服务功能全面瘫痪。

给越南企业的启示

对越南大多数中小企业——技术团队几十人、基础设施预算有限——教训相当清晰：

• 不要为了"赶时髦"而拆微服务。如果你的系统还没触及一台强力服务器（或负载均衡后面的几个单体副本）扛不住的门槛，单体架构几乎总是在成本上更划算的选择。

• 如果已经拆了：注意按实际流量平衡资源（不要平均地给每个服务分一台机器），内部通信优先使用 gRPC，合理使用批处理（batching）与缓存（caching）。

• 模块化单体（Modular Monolith）——在一个应用内部划分清晰的模块与代码边界——很可能重新成为大多数新项目的默认选择，尤其当 AI 工具让小团队也能完成大团队的工作量时，既能保持运维简单，又能避免一切不必要的内部通信开销。

任何架构都有它的代价。关键在于清楚自己到底在为什么买单——而上面的实验表明，这份代价可以精确量化到每一个毫秒的 CPU。

结语

微服务并不"差"——它解决的是组织问题，而不是性能问题。如果你的目标是为特定流量优化基础设施成本，单体架构（单机或横向复制）碾压式胜出：同样是每月 112 美元，你能获得两倍的承载能力。如果目标是让数百名工程师规模的多个团队并行、独立开发——微服务的每一分额外开销都物有所值。

你的系统目前采用哪种架构？在拆分微服务之后，是否也曾"咬牙"优化过延迟和基础设施成本？欢迎在评论区分享你的经验。

参考资料

• 原始实验：Arjay McCandless — "How much slower are Microservices? (I tested)"

• 越南语解析：Lữ Minh Khương — VGU Tech Alumni 社群

• 应用基准测试标准：RealWorld (Conduit)