Serverless 和传统服务器架构有什么区别？

Serverless 和传统服务器架构是两种截然不同的技术范式，理解它们的差异是后端架构面试中的高频考点。下面从核心原理到实际选型，逐层拆解。

本质区别：谁在管理服务器

传统架构中，开发者需要自行购买或租用服务器（物理机、虚拟机、容器），对操作系统、运行时环境、网络配置等全权负责。Serverless 并不是"没有服务器"，而是将服务器的管理权完全交给云厂商，开发者只需编写业务代码并部署，底层基础设施由平台自动调度。

简单理解：传统架构是你自己买车自己开自己保养，Serverless 是打车——你只管出发和到达，车和司机由平台提供。

从技术实现上看，Serverless 通常由 FaaS（函数即服务）和 BaaS（后端即服务）两部分组成。FaaS 负责运行业务代码，BaaS 提供数据库、存储、消息队列等托管服务，两者配合实现完整的应用架构。

成本模型：固定支出 vs 按量计费

传统架构采用预留资源模式，无论服务是否被访问，服务器租金照付。需要按峰值容量预估采购，低峰期资源闲置浪费。

Serverless 采用按量计费，只为函数实际执行的调用次数和运行时长付费。代码不运行时不产生任何费用，特别适合流量波动大或低频触发的场景。

不过需要注意：如果应用持续高并发运行，Serverless 的累计费用可能超过传统架构的固定成本。成本优势取决于流量模式。一个经验判断——当服务利用率低于 10% 时，Serverless 的成本优势明显；利用率持续超过 70% 时，传统架构通常更经济。

运维与扩展：手动运维 vs 自动伸缩

传统架构需要运维团队处理服务器监控、系统补丁、安全加固、负载均衡配置、容量规划等。水平扩展需要手动增加实例并调整负载均衡策略，扩展速度受限于采购和部署周期。

Serverless 平台自动处理基础设施运维，函数实例根据请求量自动创建和销毁，理论上可无限扩展。开发者无需关心容量规划，平台在毫秒级完成弹性伸缩。

但自动伸缩也有边界：各云厂商对函数的并发执行数、单次执行时长都有上限（如 AWS Lambda 默认单次最长 15 分钟），超长运行任务不适合 Serverless。

状态管理：有状态 vs 无状态

这是一个面试中容易被追问的关键点。传统架构支持本地状态持久化，可以依赖内存中的 Session、本地缓存、文件系统等维持应用状态，也支持会话保持（Sticky Session）。

Serverless 函数是无状态的，每次调用可能运行在不同的计算实例上。上一次调用的内存数据、本地文件在下次调用时不可用。状态必须外部化存储——使用 Redis、数据库、对象存储等。这意味着：

• 不能依赖本地文件系统保存持久数据
• 不能使用进程内缓存作为可靠的状态存储
• 需要通过外部服务实现跨请求的状态共享

冷启动问题

Serverless 函数在长时间未被调用后，计算实例会被回收。下次请求到来时需要重新分配资源并初始化运行环境，这个延迟称为冷启动。

冷启动的影响程度与运行时有关：Python、Node.js 等轻量运行时通常在百毫秒级，Java 等重运行时可能达到数秒。传统架构的服务器常驻运行，不存在冷启动问题。

应对冷启动的常见策略：

• 使用预热机制定时触发函数
• 选择轻量运行时
• 使用预留实例（Provisioned Concurrency）消除冷启动
• 设置函数最小实例数

供应商锁定风险

传统架构的技术栈相对通用，应用可以在不同云平台或自建机房之间迁移。

Serverless 深度依赖云厂商的 FaaS 和 BaaS 服务，不同厂商的函数接口、事件触发机制、服务集成方式差异较大。从 AWS Lambda 迁移到 Azure Functions 或阿里云函数计算，往往需要大幅改造代码。这是架构选型时必须评估的风险。

降低锁定风险的实践：使用 Serverless Framework 等抽象层、将业务逻辑与平台 SDK 解耦、对核心服务保留传统架构方案作为兜底。

开发与部署体验

传统架构需要配置运行环境、管理依赖、编写部署脚本、处理灰度发布。部署流程复杂，迭代周期长。

Serverless 的部署粒度更细，一个函数就是一个部署单元。代码打包上传即可运行，CI/CD 流程更简单。但本地调试和端到端测试的难度更大，因为很多触发器和依赖服务需要在云端才能完整运行。

架构粒度：单体/微服务 vs 函数级

传统架构以应用或微服务为部署单位，一个服务包含多个接口和业务逻辑。

Serverless 将应用拆分为更细粒度的函数，每个函数通常只完成一个动作（处理一个 HTTP 请求、响应一个事件、执行一次数据转换）。这种细粒度带来更好的隔离性和独立扩展能力，但也增加了函数编排和调用的复杂度。

适用场景对比

维度	传统架构	Serverless
流量模式	稳定持续的高并发	突发、间歇性、不可预测
延迟要求	严格低延迟	可容忍冷启动延迟
运行时长	长时间运行的任务	短时计算任务
状态需求	有状态服务	无状态、事件驱动
迁移需求	需要多云/混合部署	接受供应商锁定
团队能力	有专业运维团队	运维资源有限

Serverless 的典型场景：API 网关后端、事件驱动处理、定时任务、数据 ETL 流水线、实时文件处理、IoT 消息处理。

传统架构的典型场景：长时间运行的服务（如 WebSocket 长连接）、对延迟极度敏感的交易系统、需要 GPU 的机器学习训练、有强合规要求需自建机房的业务。

面试回答建议

回答时不要只列差异，要展示选型思维：

1. 先明确两种架构的核心差异——谁管服务器、怎么计费、怎么扩展
2. 再深入技术细节——冷启动、无状态约束、供应商锁定
3. 最后给出选型依据——根据业务流量模式、延迟要求、团队规模、成本预算综合判断

实际项目中，很多团队采用混合架构：核心服务用传统架构保证稳定性和控制力，边缘服务和异步任务用 Serverless 提升开发效率和降低成本。这种折中方案往往是最务实的选择。