📚 课程目录第4章部署架构设计

4. 部署架构设计：单体架构 vs 微服务架构 vs Serverless 架构对比

在评分通道模型的生产部署中，架构选型直接决定了系统的吞吐上限、运维复杂度和资源成本。本章从高并发评分场景出发，对三种主流部署架构进行系统性对比，帮助你在不同业务阶段做出合理选择。

维度	单体架构 (Monolithic)	微服务架构 (Microservices)	Serverless 架构
部署单元	单个进程 / 单个容器	多个独立服务进程	函数粒度 (FaaS)
扩展粒度	整体水平扩展	按服务独立扩展	按请求自动弹性
启动时间	秒级 ~ 分钟级	秒级	毫秒级 (冷启动 100ms+)
状态管理	本地内存 / 共享 DB	分布式缓存 + 数据库	外部存储 (Redis / DB)
运维复杂度	低	高 (服务发现、链路追踪)	极低 (托管平台)
适用 QPS 范围	0 ~ 5,000	1,000 ~ 100,000+	0 ~ 10,000 (突发型)

选型提示： 评分通道模型通常包含特征提取、模型推理、后处理三个子阶段。单体架构适合原型验证和低并发场景；微服务架构适合多模型混合编排；Serverless 适合流量波动剧烈的在线评分服务。

下图展示了三种架构下，一次评分请求从网关到模型推理的完整路径差异。

单体架构： 只能整体扩缩容，资源利用率低。当模型推理成为瓶颈时，特征提取和后处理也必须一同扩容，造成浪费。
微服务架构： 可针对推理服务单独设置 HPA（Horizontal Pod Autoscaler），特征服务和后处理服务保持较小副本数，资源利用率提升 30%~50%。
Serverless 架构： 每个函数独立弹性，冷启动时延约 100~500ms。对于突发流量（如秒杀评分），能快速拉起数千并发实例，但需注意冷启动对延迟敏感型业务的影响。

成本项	单体架构	微服务架构	Serverless 架构
基础设施	固定服务器 / 容器	K8s 集群 + 服务网格	无服务器 (按调用计费)
运维人力	1 人维护	2~3 人维护	0.5 人维护
空闲成本	高 (始终运行)	中 (可缩容至 0)	低 (无调用不计费)
模型 GPU 利用率	30%~50%	50%~70%	70%~90% (共享 GPU)

根据评分通道模型的实际业务需求，可参考以下决策路径进行架构选择：

某金融风控评分平台在一年内经历了三次架构迭代，其演进路径可作为典型参考：

阶段一（单体架构）： 日评分量 10 万笔，单台 8 核 32G 服务器部署 Flask + ONNX Runtime，QPS 峰值 800，响应时间 P99 200ms。开发周期 2 周，运维成本极低。
阶段二（微服务架构）： 日评分量增长至 500 万笔，拆分为特征服务、推理服务、后处理服务三个独立微服务，部署在 5 节点 K8s 集群。推理服务单独配置 2 张 T4 GPU，QPS 峰值 12,000，P99 降至 80ms。
阶段三（混合架构）： 引入 Serverless 处理突发流量，日常流量走微服务，秒杀活动期间自动触发函数计算扩容，峰值 QPS 达到 50,000，闲置时函数缩容至零，GPU 成本降低 40%。

避坑提醒： 不要一开始就追求微服务或 Serverless。评分通道模型的核心瓶颈通常是模型推理延迟而非架构弹性。建议先以单体架构跑通全链路，通过性能压测找到真实瓶颈后，再按需拆分。过早拆分会增加 2~3 倍的开发和运维成本。

迁移方向	代码改动量	基础设施投入	团队技能要求	建议周期
单体 → 微服务	30%~50% 重构	K8s 集群 + 服务网格	容器化、分布式调试	4~8 周
单体 → Serverless	20%~40% 适配	云函数平台 + API 网关	无状态函数设计	2~4 周
微服务 → 混合架构	10%~20% 改造	增加 Serverless 触发器	流量调度策略	2~3 周

  核心结论： 对于高并发评分通道模型，推荐采用微服务 + Serverless 混合架构。核心推理链路使用微服务保证低延迟和稳定性；突发流量和异步评分任务使用 Serverless 函数弹性处理，实现成本与性能的最佳平衡。