2026年初，在优化立达标讯招标数据查询API时，团队内部展开了一场关于“部署架构”的讨论。
一方认为：“必须用Serverless！弹性伸缩！免运维！按需付费！云原生趋势！”
另一方提出：“我们的部分API是高频调用、对冷启动极度敏感的场景，是否可以考虑传统服务器部署？”
这不是一场“谁替代谁”的争论，而是一次关于场景适配的技术探讨。最终，我们在部分核心API中采用了传统服务器部署的方案。半年后，回顾这个决定，我们对其适用边界有了更清晰的认识。
两种方案的场景分析
Serverless的典型适用场景
-
低频调用、突发流量场景（如定时任务、Webhook）。
-
希望免运维，聚焦业务逻辑。
-
成本敏感，按需付费。
传统服务器的典型适用场景
-
高频调用，对冷启动延迟极度敏感。
-
需要长期稳定运行，对性能可预测性有要求。
-
需要精细控制运行时环境（如特定内核参数、GPU资源）。
我们的判断：这不是“二选一”的问题，而是“如何组合”的问题。
我们的实践：混合部署架构
场景一：核心查询API → 传统服务器
我们的核心查询API是高频调用（每秒数千次），对冷启动延迟极度敏感。在Serverless方案下，由于函数冷启动，P99延迟波动极大（从50ms到2s不等）。迁回传统服务器后，我们获得了稳定的运行时环境，P99延迟稳定在50ms以内。
| P99延迟 | 50ms-2s（冷启动波动） | <50ms | 稳定性显著提升 |
| 月度成本 | 波动大（按调用次数） | 可预测 | 成本可控 |
| 运维复杂度 | 低（免运维） | 中 | 可接受 |
场景二：定时任务与Webhook → Serverless
对于定时任务和Webhook这类低频调用场景，我们继续使用Serverless。这类场景的特点是：
-
调用频率低。
-
对冷启动不敏感。
-
希望免运维。
场景三：混合部署 → 传统服务器 + Serverless
对于部分复杂链路，我们采用了混合部署架构：
-
核心高频API使用传统服务器，保证性能和稳定性。
-
定时任务和Webhook使用Serverless，保证弹性和免运维。
-
通过统一的API网关，实现两边服务的统一接入。
效果量化：混合部署的收益
| 核心API P99延迟 | 50ms-2s | <50ms | 稳定性显著提升 |
| 月度成本 | 波动大 | 可预测 | 成本可控 |
| 运维复杂度 | 低 | 中（需管理两类环境） | 可接受 |
关键启示：技术选型的本质是场景适配
这次实践让我们深刻认识到：没有“最好”的技术，只有“最合适”的场景适配。
-
Serverless在低频调用、突发流量、免运维场景下具有不可替代的优势。
-
传统服务器在高频调用、冷启动敏感、性能可预测场景下具有显著优势。
-
混合架构可以兼顾两者优势，但需要处理好统一接入和监控。
这和我们在立达标讯上处理招标信息的逻辑是一致的：面对每天20万+条的招标信息平台数据，我们不会盲目追求单一技术方案，而是根据数据特征（结构化程度、更新频率、查询模式）选择最合适的处理方式。
在API部署选型中，你更看重？
A. 弹性伸缩与免运维（如Serverless），选择“确定性”。
B. 性能可控与成本可预测（如传统服务器），拥抱“专精”。
C. 混合架构，根据场景适配。
欢迎在评论区留下你的选择（A、B或C）和理由。我将根据大家的反馈，在后续文章中分享我们处理混合部署监控和统一接入的具体实践。
