3. API网关与Serverless集成架构
好，咱们直接进入正题。这一章我打算聊聊API网关和Serverless集成时的整体架构长什么样，请求是怎么一路跑过去的，以及——为什么非要把它们俩凑一块儿。
说实话，我最早接触Serverless时，第一反应是：这不就是云函数嘛，直接调不就行了？后来在项目中踩了几个坑才明白，没有API网关在前面挡着，Serverless就像没穿铠甲的士兵，功能有，但扛不住真正的生产流量。
整体架构设计：谁站在哪里？
先画个简单的分层图，你想象一下：
客户端（浏览器/App/小程序）
↓
API网关层（身份认证、限流、路由、协议转换）
↓
Serverless计算层（函数计算、事件驱动）
↓
后端服务层（数据库、缓存、第三方API）这个架构里，API网关是唯一的入口。所有外部请求必须先经过网关，再由网关转发给后端的Serverless函数。为什么这么设计？说白了，就是为了把「通用能力」和「业务逻辑」彻底拆开。
我个人习惯把网关看作「保安队长」，它负责检查每个人的证件（认证）、控制进场人数（限流）、指引你去哪个窗口办事（路由）。而Serverless函数就是窗口里的办事员，只关心你来了、要办什么业务，其他一概不管。
核心原则：网关做「非业务」的事，函数做「纯业务」的事。两者各司其职，互不干扰。
请求流转路径：一个请求的完整旅程
咱们用一个实际场景来走一遍流程。假设用户通过手机App查询订单状态：
- 客户端发起HTTP请求：
GET /api/orders/12345，带上JWT Token。 - API网关接收请求：网关先解析Token，验证用户身份。我在项目中遇到过有人直接把Token放在URL参数里传，网关层直接拦截了——这种低级错误其实挺常见的。
- 网关执行前置策略：检查IP是否在黑名单、每秒请求是否超限、请求体大小是否合规。嗯，这里要注意，限流策略最好在网关层做，别放到函数里，否则流量已经打到函数了，成本可就上去了。
- 路由匹配与转发：网关根据路径
/api/orders/{id}匹配到对应的Serverless函数，把请求转换成函数能识别的格式（比如JSON事件）。 - 函数执行：Serverless运行时拉起一个实例（如果没缓存的话），执行查询数据库的逻辑，返回结果。
- 网关后置处理：函数返回后，网关可能做响应格式统一、添加跨域头、记录访问日志等操作。
- 返回客户端：最终用户看到的是200 OK和订单数据。
你看，整个路径里，函数只做了第5步这一件事。其他所有「杂活」都被网关包揽了。我曾经在一个项目里把认证逻辑写在了函数里，结果每个函数都要重复写一遍JWT校验代码，后来重构时全挪到网关层，代码量直接砍掉40%。
小技巧：如果网关支持自定义插件（比如Kong的插件机制），可以把日志、监控、熔断这些横切关注点做成插件挂载在网关上，函数里一行代码都不用改。
为什么需要集成？三个核心理由
你可能会问：我直接用函数暴露公网地址不行吗？技术上当然可以，但生产环境里你会遇到三个绕不开的问题。
1. 安全与认证的统一
Serverless函数通常有多个版本、多个别名，如果每个函数都自己处理认证，管理起来就是一场噩梦。网关可以集中管理OAuth2、JWT、API Key等多种认证方式。我记得有一次客户要求同时支持微信登录和短信验证码登录，网关层配置了两个认证插件，函数端完全不用改——这种解耦带来的好处，只有经历过的人才知道。
2. 流量治理与成本控制
Serverless是按调用次数和运行时长计费的。如果没有网关限流，一个恶意脚本就能让你的账单瞬间爆炸。网关的限流、降级、熔断机制，说白了就是在帮你「省钱」。我见过一个案例，某公司没配网关限流，结果被爬虫刷了200万次请求，当天函数计算费用直接超了预算的10倍。
| 场景 | 无网关 | 有网关 |
|---|---|---|
| 突发流量 | 函数实例暴增，成本飙升 | 网关限流，平稳处理 |
| 恶意攻击 | 直接打到函数，消耗资源 | 网关层拦截，函数无感 |
| 版本升级 | 需要修改客户端或DNS | 网关路由切换，灰度发布 |
3. 协议转换与异构系统集成
你想想看，Serverless函数通常只接受JSON事件，但客户端可能是WebSocket、gRPC、甚至MQTT协议。网关可以帮你做协议转换。我之前做过一个物联网项目，设备端用MQTT上报数据，网关转成HTTP请求再触发函数，整个过程函数完全不知道底层协议是什么——这就是集成的价值。
避坑指南：我曾经在集成时犯过一个错误——把网关的超时时间设得比函数超时时间还短。结果函数还在跑，网关已经返回504了。记住：网关超时时间一定要大于函数最大执行时间，否则会出现「假失败」。
架构选型建议
最后给点实际建议。市面上主流的API网关（Kong、APISIX、AWS API Gateway、阿里云API网关）都能和Serverless集成。我个人偏好开源方案，因为可定制性强。但如果你用的是云厂商的全家桶，直接用托管网关会更省心——毕竟不用自己运维。
选型时关注三点：
- 冷启动影响：网关会不会增加额外的冷启动延迟？有些网关在转发前会做额外处理，导致函数冷启动雪上加霜。
- 自定义插件能力：能否用Lua、Go或JavaScript写插件？这决定了你能在网关层做多少定制逻辑。
- 与Serverless平台的集成深度：比如是否支持自动生成函数对应的API文档、是否支持直接调试函数。
嗯，这一章的内容差不多就这些。记住一句话：API网关是Serverless架构的「门面」，没有它，你的函数再强大也难以上战场。下一章咱们会深入具体的网关配置，到时候手把手带你搭一套可用的集成环境。