微服务 vs Serverless：该选哪种架构？

在设计一款现代应用如何组织和运行时，有两种方式一再出现：microservices，将系统拆分为彼此独立的服务；以及 serverless，无需管理服务器即可运行函数。它们常被混淆或对立起来，但其实回答的是不同的问题：microservices 是组织系统的一种方式，serverless 是运行系统的一种方式。理解这一区别有助于做出更好的架构决策，并避免不必要的复杂度。

本文我们对比 microservices 和 serverless，梳理各自的优劣，并说明何时适合采用哪一种或将二者结合。

什么是微服务

microservices 架构将一款应用拆分为众多小而独立的服务，每个都有自己的职责并可单独部署。它的优势在于独立性和按需扩展：每个团队负责各自的服务，只对需要的部分进行扩展，而某一个服务的故障不会拖垮整个系统。代价是它引入了相当大的复杂度：服务间通信、协调部署以及繁重的运维。它是一种组织系统的方式，与系统在哪里运行无关。

什么是 serverless

serverless 是一种执行模式：你编写函数，由服务商负责配置、扩展和维护基础设施，只按真正的执行向你计费。它的优势在于运维上的简洁以及对可变负载的成本优势：无需管理服务器、自动扩缩容直至归零、按使用付费。代价是控制力较少、对服务商的绑定更深，且在非常持续的负载下可能变贵。它是一种运行代码的方式，而不是组织代码的方式。

组织 vs 执行

避免混淆的关键在于理解它们比较的是不同的东西。microservices 回答的是“我如何拆分我的应用”；serverless 回答的是“我在哪里、以何种方式运行我的代码”。事实上，二者并不互斥：你可以让 microservices 运行在 serverless 上、让 microservices 运行在容器中，或者让一个简单的应用运行在 serverless 上而不使用 microservices。正确的问题不是“二选一”，而是“我的系统需要怎样的结构，以及每个部分适合怎样的执行模式”。

关键差异

概括来说，以下是这两个概念之间差异最明显的几个方面：

• 本质：microservices 负责组织；serverless 负责执行。
• 控制力：microservices 更高（尤其在容器中）。
• 运维：serverless 几乎无需管理基础设施。
• 成本：serverless 在可变负载上占优；持续负载更适合其他模式。
• 复杂度：microservices 很高；serverless 起步时很低。
• 可组合：二者可以毫无障碍地一起使用。

过早复杂化的错误

对这两个概念而言，代价最高的错误就是被其“现代”的名声所吸引、在真正需要之前就采用它们。从第一天起就把一个小应用拆成众多 microservices，会成倍增加复杂度（通信、部署、监控），却得不到那些只有在一定规模下才会显现的好处。同样，把一切都强行塞进 serverless，在重而持续的负载下可能撞上它的局限。业界反复验证的经验很清楚：从简单起步，先度量，等真正的痛点出现时再拆分或更换模式，远比一开始就过度设计划算得多。一个比你预想所需更简单的架构往往是正确的决定，因为当具体问题出现时，你总能再去演进它。

如何选择

对大多数起步阶段的项目，最明智的做法是从简单开始：一个组织良好的应用，往往运行在 serverless 或托管容器上，不要在真正需要之前就贸然采用 microservices。当系统真正壮大时再采用 microservices：众多团队、扩展需求差异极大的部分，或适合单独部署的组件。把 serverless 用于可变或事件驱动的负载，对持续负载则与容器结合使用。要按真实问题来设计，而不是按时髦的标签。

在 AxiomTech，我们会为每种情况设计合适的架构，根据你的真实需求把 microservices、serverless 和容器结合起来，不引入不必要的复杂度。如果你拿不准如何组织和运行你的应用，欢迎与我们聊聊，我们会根据你的负载和团队提供建议。