微服务 vs. 无服务器：选择正确架构的实用指南

核心要点

• 并非竞争对手： 微服务和无服务器并非互斥。微服务是一种围绕业务能力构建应用程序的架构模式。无服务器是一种无需管理服务器即可执行代码的云运营模型。
• 两者关系： 你可以构建一个微服务，并使用无服务器模型（例如，作为 AWS Lambda 函数）部署它。另一种选择是将其部署在更传统的“常驻”环境中，例如 Kubernetes 上的容器。
• 关键权衡： 选择归结为控制力与便利性之间的权衡。容器上的微服务提供高控制力，但具有显著的操作开销。无服务器提供低开销和自动扩展，但存在执行时间限制和潜在供应商锁定等约束。
• 使用合适的工具： 对于事件驱动、突发性或间歇性工作负载，使用无服务器。对于长时间运行的进程、有状态应用程序或高且持续的流量，使用容器化微服务。
• 混合方法： 最高效的现代架构通常是混合的。它们使用灵活的 API 网关将流量路由到每个任务的最佳后端——无论是无服务器函数还是容器化微服务。

引言：伟大的架构之争

在构建可扩展、弹性系统并摆脱单体架构陷阱的不懈追求中，两种强大的范式已成为主导力量：微服务和无服务器。两者都承诺敏捷性、独立部署和专注的开发。然而，它们经常在架构辩论中被对立起来，造成一种可能导致困惑和分析瘫痪的错误二分法。无服务器是“新的微服务”吗？ 你必须二选一吗？

简短的回答是否定的。这场辩论建立在一个根本性的误解之上。

本文将阐明微服务和无服务器并非竞争对手。微服务是指导你如何构建应用程序逻辑的架构蓝图。无服务器是决定该逻辑如何执行和管理的云运营模型。最关键的见解是，它们可以并且经常应该协同工作。

我们将通过定义每种范式、在关键因素上进行比较，并探讨 API 网关在管理两者中不可或缺的作用，来分解这个复杂的话题。到最后，你将不再问“哪个更好？”，而是问“哪个更适合这个特定工作？”

架构蓝图 vs. 云运营模型

在我们进行比较之前，必须理解它们的不同性质。两者之间的选择不仅仅是关于功能；它关乎控制力、成本和复杂性之间的根本权衡。

微服务：你的应用程序蓝图

微服务架构将应用程序构建为一组围绕业务能力构建的小型、自治服务。想象一下诸如“用户认证”、“产品目录”或“支付处理”之类的服务。每个服务都是：

• 可独立部署： 你可以更新支付服务而无需触及用户服务。
• 松耦合： 服务通过明确定义的 API 进行通信。
• 拥有其数据： 每个服务通常管理自己的数据库，以确保强边界。

这些服务通常部署为“常驻”进程，通常打包为容器（例如 Docker），并由像 Kubernetes 这样的编排器管理。团队负责整个生命周期：配置基础设施、配置网络和管理运行时。

1graph TD
2    subgraph Client Tier
3        WebApp[Web Application]
4    end
5
6    subgraph "API Gateway Layer"
7        APIGateway[API Gateway]
8    end
9
10    subgraph "Microservices on Kubernetes"
11        UserService["User Service <br/> (Container)"]
12        ProductService["Product Service <br/> (Container)"]
13        OrderService["Order Service <br/> (Container)"]
14    end
15
16    WebApp --> APIGateway
17    APIGateway -- routes /users --> UserService
18    APIGateway -- routes /products --> ProductService
19    APIGateway -- routes /orders --> OrderService

无服务器：你的代码执行模型

无服务器计算是一种云执行模型，其中提供商为你动态管理服务器。最流行的形式是函数即服务（FaaS），由 AWS Lambda、Google Cloud Functions 和 Azure Functions 等提供商提供。

使用无服务器，你只需将代码编写并上传为一个函数。云提供商处理其他所有事情：

• 无需服务器管理： 你永远不需要配置、修补或管理任何虚拟机或容器。
• 事件驱动执行： 函数由事件触发——HTTP API 调用、S3 存储桶中的新文件、队列中的消息等。
• 按执行付费： 你只需为函数消耗的计算时间付费，精确到毫秒。空闲时间无需付费。

这种模型从根本上将责任从开发人员转移到了云提供商，使团队能够几乎完全专注于应用程序逻辑。

逐项功能对比

理解选择一种部署模型而非另一种背后的“原因”的最佳方式是直接比较。

通过 API 网关统一架构

无论你选择容器化微服务、无服务器函数，还是（理想情况下）两者混合，都需要一种稳健的方式来管理、保护它们并将其暴露给外部世界。这就是现代 API 网关不可或缺的作用。

网关作为微服务的前门

在微服务架构中，API 网关不是可选的；它是必需的。没有它，客户端将必须知道每个服务的网络位置，从而造成紧耦合的混乱。网关充当单一、统一的入口点，并执行关键的横切任务：

• 路由： 它检查传入请求并将其路由到适当的后端服务（例如，/api/users 到用户服务）。
• 安全： 它通过在边缘处理 JWT 验证、API 密钥认证和 OAuth 2.0 流程等任务，将安全顾虑从单个服务中卸载。
• 速率限制与缓存： 它通过强制执行使用策略和缓存常见响应，保护后端服务免受过载，并提高性能。

网关作为无服务器函数的触发器

对于无服务器函数，API 网关通常扮演更基本的角色：它充当主要的调用触发器。函数只是休眠的代码，直到事件调用它。网关提供稳定、公共的 HTTP 端点，将 Web 请求转换为函数触发器。

1graph TD
2    subgraph Event Sources
3        APIGateway["API Gateway (HTTP Trigger)"]
4        S3["S3 Bucket (File Upload Trigger)"]
5        SQS["SQS Queue (Message Trigger)"]
6    end
7
8    subgraph "Serverless Functions (AWS Lambda)"
9        Func_A[Function A]
10        Func_B[Function B]
11        Func_C[Function C]
12    end
13
14    APIGateway --> Func_A
15    S3 --> Func_B
16    SQS --> Func_C

网关可以将传入的 HTTP 请求负载转换为函数预期的事件格式，处理身份验证，并为原本只是一段孤立代码的内容提供安全、可管理的 RESTful 接口。

两全其美：混合架构

最成熟和务实的方法是认识到你不必为整个系统选择一种模型。最精明的架构师会混合搭配，为每项工作使用最佳工具。一个高级的 API 网关是轻松管理这种复杂性的关键。

示例场景：电子商务应用程序

考虑电子商务平台所需的不同任务：

1. 图片调整大小： 用户上传产品图片。这是无服务器的完美用例。来自存储桶（例如 Amazon S3）的事件触发一个短暂、无状态的函数，将图片调整为各种缩略图并保存回去。它是事件驱动、计算简单，并且只需按需运行。
2. 订单处理： 用户点击“完成购买”。这会启动一个复杂、有状态且长时间运行的工作流。它需要检查库存、处理支付、与运输提供商协调、更新客户的订单历史记录并发送通知。这是容器化微服务的完美选择，可以管理复杂状态并根据需要运行任意长时间。

像 Apache APISIX 这样的 API 网关可以从单一控制平面管理这种混合环境。客户端应用程序与一个统一的 API 交互，无需了解多样化的后端架构。

1graph TD
2    Client[Web/Mobile Client] --> APIGateway["API Gateway (Apache APISIX)"]
3
4    subgraph "Backend Execution Models"
5        subgraph "Serverless (AWS Lambda)"
6            ImageResizeFunc[Image Resize Function]
7        end
8        subgraph "Microservices (Kubernetes)"
9            OrderService[Order Processing Service]
10            UserService[User Management Service]
11        end
12    end
13
14    APIGateway -- routes POST /api/v1/orders --> OrderService
15    APIGateway -- routes GET /api/v1/users/me --> UserService
16    APIGateway -- routes POST /api/v1/images --> ImageResizeFunc

网关智能地将请求路由到适当的后端，为整个基础设施的安全、可观测性和流量控制提供统一层。

做出选择：实用的决策框架

为了从理论走向实践，这里有一个指南，帮助你决定对给定服务或组件使用哪种模型。

何时倾向于微服务（容器/Kubernetes）

• 你需要长时间运行的进程： 对于超过 15 分钟 FaaS 限制的任务，例如复杂的数据处理、实时 析管道或管理持久的 WebSocket 连接。
• 你的流量可预测且持续高流量： 如果服务始终繁忙，容器的预配置成本可能比支付数百万次单独的无服务器调用更经济。
• 你需要对环境进行精细控制： 当你的应用程序需要特定的操作系统版本、自定义编译的二进制文件、访问 GPU 或微调的网络控制时。
• 你正在构建有状态服务： 对于严重依赖内存状态或需要直接、低延迟访问服务拥有和管理的专用数据库的应用程序。
• 你的组织拥有成熟的 DevOps 和 Kubernetes 专业知识。

何时倾向于无服务器（FaaS）

• 你的工作负载是事件驱动或具有突发性、不可预测的流量： 适用于长时间不活动但突然出现请求激增的服务（例如，处理月度报告的函数）。
• 上市速度是你的最高优先级： 无服务器极大地降低了操作复杂性，允许小团队极其快速地推出功能和 MVP。
• 你希望最小化低流量服务的成本： 适用于内部工具、聊天机器人、计划任务（cron 作业）和简单的 API 后端，为常驻服务器付费是浪费的。
• 你的应用程序逻辑是无状态的，并且可以分解为小的、单一用途的函数。
• 你的团队规模小或缺乏深厚的 DevOps 专业知识。

结论：超越“对决”走向“融合”

“微服务 vs. 无服务器”的辩论分散了构建更好应用程序这一真正目标的注意力。对话已经超越了这种错误的二分法。微服务为设计解耦、面向领域的系统提供了宝贵的蓝图。无服务器提供了一种革命性的运营模型，抽象了基础设施，实现了无与伦比的敏捷性和成本效益。

如今最高效的架构师不是纯粹主义者；他们是务实者。他们构建弹性的混合系统，将有状态、长时间运行的服务部署为容器，同时利用事件驱动的无服务器函数处理短暂任务。使这个混合世界易于管理的关键是一个强大而灵活的 API 网关。它充当智能控制平面，为外部世界提供单一、安全且连贯的 API，无论幕后的复杂性如何。这种战略组合——为工作使用正确的工具，并通过网关统一——是现代软件架构的标志。