1. 课程导入
在金融行业，模型推理服务（Serving）并不是一个“能返回结果就行”的普通在线接口。它直接参与风控决策、反欺诈评分、智能投顾、信贷审批、实时定价等核心业务链路，任何一次超时、抖动或不可用，都可能转化为资金损失、合规风险与客户信任下降。因此，金融Serving的部署目标，从一开始就不是“跑起来”，而是“在压力、故障与变更中持续稳定地跑下去”。本课程围绕这一目标，以Kubernetes为底座，系统讲解高可用部署的架构方法、配置细节与实战排障。
一、金融Serving场景的五个关键特点
理解金融Serving的高可用要求，必须先看清它与互联网通用推理服务的差异。这些差异决定了后续所有架构决策的优先级。
- 强合规与可审计：模型版本、镜像来源、配置变更、访问日志都需要可追溯。部署过程不能依赖手工“登上机器改一改”，而应通过声明式配置与版本化发布完成。
- 低延迟与确定性：风控评分往往要求在几十毫秒内返回，且P99延迟比平均延迟更重要。高可用不仅是“不宕机”，还包括尾延迟稳定。
- 流量潮汐与突发性：交易日开盘、营销活动、批量授信时段的请求量可能数倍于日常，弹性伸缩与容量预留必须同时考虑。
- 多活与容灾要求：单机房、单集群、单节点都不足以承载核心链路，需要跨可用区甚至跨集群的故障隔离与流量切换能力。
- 安全与隔离：模型文件、特征数据、密钥凭证属于敏感资产，需要网络策略、RBAC、Secret管理与镜像签名等机制共同保护。
二、Kubernetes高可用部署目标
Kubernetes提供了副本控制、服务发现、滚动更新、自愈等能力，但这些能力默认并不等于高可用。金融Serving的部署目标需要被明确拆解为可验证的指标与机制。
| 目标维度 | 具体要求 | Kubernetes对应机制 |
|---|---|---|
| 计算高可用 | 多副本分布在不同节点，单节点故障不影响服务 | Deployment副本数、Pod反亲和、拓扑分布约束 |
| 流量高可用 | 请求只转发到健康Pod，故障Pod自动摘除 | Readiness Probe、Service、EndpointSlice |
| 发布高可用 | 版本升级不中断，异常可快速回滚 | 滚动更新策略、maxUnavailable、maxSurge、RevisionHistory |
| 资源高可用 | 关键服务获得稳定CPU/内存，避免被挤占 | Requests/Limits、QoS、ResourceQuota、PriorityClass |
| 容灾高可用 | 集群或可用区故障时可切换 | 多集群、Ingress/Gateway、DNS流量调度 |
| 可观测高可用 | 延迟、错误、饱和度可监控、可告警、可定位 | Metrics、Logs、Traces、Prometheus、Grafana |
这些目标之间并非独立。例如，只配置多副本却不配置就绪探针，流量仍可能打到尚未加载完模型的Pod；只配置资源限制却不设置优先级，节点资源紧张时关键Serving仍可能被驱逐。因此，高可用部署是一项系统性工程。
三、核心原理：从Pod到服务的可用性链路
在Kubernetes中，一个推理请求从进入集群到返回结果，会经过入口、Service、Endpoint、Pod、容器进程等多个环节。高可用设计的关键，是识别这条链路上的单点与薄弱点，并逐层加固。
上图展示了一个典型链路：入口层负责安全与路由，Service与EndpointSlice负责将流量只转发到就绪副本，Pod层通过反亲和与资源约束实现故障隔离，异常Pod被自动摘除。高可用不是某一个组件的能力，而是这条链路上每一层都“不把可用性寄托在下一层”的结果。
四、方法流程：高可用部署的推进顺序
在实际项目中，建议按照“先可用、再可靠、后弹性”的顺序推进，避免一开始就堆砌复杂组件。
- 基线部署：用Deployment部署推理容器，配置Requests/Limits、Readiness/Liveness探针，确保单副本可正常服务。
- 副本与分布：提升副本数，配置Pod反亲和与拓扑分布约束，使副本分散到不同节点与可用区。
- 流量治理：通过Service、Ingress/Gateway暴露服务，配置超时、重试、限流与熔断策略。
- 发布与回滚：设置滚动更新参数，验证maxUnavailable与maxSurge对可用性的影响，准备回滚预案。
- 弹性与容灾：引入HPA、集群自动扩缩容、多集群流量切换与故障演练。
- 可观测与复盘：建立指标、日志、追踪体系，定期进行故障注入与复盘。
# 一个金融Serving Deployment的关键片段示例
apiVersion: apps/v1
kind: Deployment
metadata:
name: risk-serving
spec:
replicas: 4
strategy:
rollingUpdate:
maxUnavailable: 1
maxSurge: 1
template:
spec:
affinity:
podAntiAffinity:
requiredDuringSchedulingIgnoredDuringExecution:
- labelSelector:
matchLabels:
app: risk-serving
topologyKey: kubernetes.io/hostname
containers:
- name: serving
image: registry.example.com/risk-serving:1.8.2
resources:
requests:
cpu: "2"
memory: "4Gi"
limits:
cpu: "4"
memory: "8Gi"
readinessProbe:
httpGet:
path: /health/ready
port: 8080
initialDelaySeconds: 20
periodSeconds: 5
五、案例与场景：一次“副本充足但服务不可用”的复盘
某金融团队在Kubernetes上部署风控Serving，配置了6个副本，节点分布也正常。但在一次模型版本升级后，监控显示Pod全部Running，接口却大量超时。排查发现：新版本模型加载时间从10秒增加到90秒，而Readiness探针的initialDelaySeconds仍为10秒，导致Pod在模型未加载完成时就被标记为Ready并接入流量；同时Liveness探针在加载期间反复失败，触发容器重启，形成“加载—重启—再加载”的循环。
修正方案包括：延长initialDelaySeconds与failureThreshold，增加startupProbe专门处理慢启动，使用PreStop Hook优雅下线，并在发布前用压测验证新版本的冷启动时间。经过调整后，升级期间错误率从8%降至0.1%以下。
六、常见误区与学习建议
- 误区一：只关注Pod副本数。副本多不代表流量能正确分发，Endpoint、探针、会话保持、连接池都可能成为瓶颈。
- 误区二：忽略资源Requests。不设置Requests会导致调度器无法合理分配，节点资源争抢时关键服务被驱逐。
- 误区三：把高可用等同于多集群。单集群内的探针、发布、资源治理没做好，多集群只会把问题复制到更多地方。
- 误区四：没有故障演练。高可用能力必须通过真实故障注入验证，否则只是纸面配置。