机器学习模型生产化实战：从Notebook到高可用ML服务

1. 项目概述当模型走出Jupyter真正开始呼吸真实世界的空气“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题本身就像一句暗号专为那些在Jupyter里调通了模型、画出了漂亮ROC曲线、却在把模型推上服务器时突然卡壳的工程师准备的。它不是讲怎么写model.fit()而是讲当你的模型第一次被业务系统调用、第一次在凌晨三点因上游数据格式突变而报错、第一次因为GPU显存被另一个任务悄悄占满而拒绝服务时你该抓哪根救命稻草。我带过六支不同行业的AI落地团队从金融风控到工业质检踩过的坑几乎能编成一本《生产环境ML事故年鉴》。Part 4之所以关键是因为它标志着从“能跑”到“敢用”的临界点模型不再是个静态快照而是一个持续感知、响应、自愈的服务节点。它涉及的核心从来不是算法本身而是可观测性设计、资源弹性调度、数据漂移防御和灰度发布策略这四根承重柱。如果你还在用pickle.dump()把模型塞进一个.pkl文件然后手动scp到服务器或者靠curl命令测试API是否返回200那这篇就是为你写的实战手册。它不假设你懂Kubernetes但会告诉你为什么kubectl get pods比ps aux | grep python更能帮你定位延迟飙升的根源它不强求你写Prometheus exporter但会手把手教你用三行代码把模型推理耗时、输入数据分布、特征缺失率这些关键指标埋进日志流。适合所有已经完成模型训练、正站在生产化门槛前的算法工程师、MLOps工程师以及那些被老板问“模型上线后怎么知道它没坏掉”的技术负责人。2. 内容整体设计与思路拆解为什么“部署”不是终点而是运维的起点2.1 从Notebook到Production的本质跃迁从确定性计算到不确定性系统很多人误以为“部署”就是把训练好的模型文件拷贝到服务器启动一个Flask服务再配个Nginx反向代理就万事大吉。这种理解错在把机器学习系统当成一个传统Web应用来对待。一个Flask API处理HTTP请求本质是确定性的输入JSON执行函数返回JSON。而一个ML服务其核心逻辑是概率性决策数据依赖状态漂移。它的输出不仅取决于当前输入更取决于训练数据的统计特性、线上数据的分布偏移、甚至GPU驱动版本的微小差异。我在某电商公司做实时推荐模型上线时就遇到过一个经典案例模型在A/B测试中CTR提升显著但上线一周后效果归零。排查发现并非模型退化而是上游数据管道在周末自动启用了新的用户行为清洗规则导致关键特征last_7d_click_count的数值范围从[0, 500]压缩到[0, 50]模型对这个缩放毫无感知预测结果集体失准。这说明生产环境中的ML服务必须被设计成一个可感知、可解释、可干预的活体系统而非一个黑盒函数。因此Part 4的设计思路彻底抛弃了“部署即完成”的线性思维转而采用闭环反馈驱动的生命周期管理监控Monitor→ 检测Detect→ 告警Alert→ 分析Analyze→ 修复Remediate。每一个环节都对应着具体的技术组件和工程实践而不是抽象概念。2.2 方案选型背后的硬核权衡轻量级API vs 容器化编排没有银弹面对“如何运行ML”的问题业界常陷入两个极端一端是极简主义用FastAPI写个几行代码的APIuvicorn --host 0.0.0.0:8000 --workers 4直接跑起来另一端是重型架构上Kubernetes、KFServing、MLflow Model Registry、PrometheusGrafana全套。Part 4选择了一条中间路线核心原则是按需分层能力下沉。我们不会为了一个每天只处理200次请求的内部审批模型去搭一套K8s集群但也不会让一个支撑每秒3000次QPS的广告出价模型只跑在一个裸机Python进程里。具体分层如下L1单机服务层适用于POC验证、低频内部工具、或作为大型系统的子模块。技术栈FastAPI Uvicorn Gunicorn进程管理 Prometheus Client轻量埋点。优势是启动快、调试直观、资源开销小。我曾用这套组合在2小时内将一个信用评分模型封装成API供财务部门Excel插件调用全程无需运维介入。L2容器化服务层适用于中等规模、需要一定弹性和隔离性的场景。技术栈Docker打包模型依赖API服务 → Docker Compose编排本地/测试环境或 Kubernetes Deployment生产环境。关键在于容器镜像的构建哲学我们坚持“一个镜像一个职责”。模型推理镜像只包含模型、推理代码、基础依赖torch/tf、API框架和健康检查脚本绝不混入训练代码、数据下载脚本或数据库连接池。这样做的好处是镜像体积可控通常1.2GB拉取速度快且安全扫描如Trivy能精准定位漏洞位置。L3平台化服务层适用于多模型、多团队、高SLA要求的企业级场景。技术栈KFServing/Kubeflow Inference Seldon Core Argo Workflows用于自动化重训练流水线。这一层的核心价值不是“能跑”而是“能管”统一的模型版本控制、细粒度的资源配额CPU/GPU/Memory、基于流量的金丝雀发布、自动化的模型性能回滚。某汽车厂商的智能座舱语音识别模型就采用此架构当新版本在5%流量下F1值下降超过0.5%系统自动触发回滚并通知算法团队。选择哪一层关键看三个数字QPS峰值、P99延迟容忍度、模型迭代频率。如果QPS100P99500ms迭代周期1周L1足够如果QPS在100-5000P99200ms迭代周期3天L2是性价比之选如果QPS5000P99100ms且要求分钟级模型热更新L3才是正解。这不是技术炫技而是对业务成本和稳定性的精确计算。2.3 避开“伪生产化”陷阱那些看似光鲜却埋雷的技术选型在推进ML生产化过程中我见过太多团队掉进“伪生产化”的坑里表面看架构很酷实则不堪一击。这里必须点名几个高危选项用Celery做模型推理异步队列这是最典型的误区。Celery擅长处理IO密集型任务如发邮件、调外部API但模型推理是典型的CPU/GPU密集型计算。当大量推理请求涌入Celery worker会导致worker进程长时间阻塞无法及时响应心跳进而被broker标记为“失联”任务堆积最终雪崩。正确做法是对于实时性要求高的推理必须走同步HTTP/gRPC对于允许延迟的批量任务如每日用户画像更新才用专用的批处理框架如Airflow Spark ML。把模型参数硬编码在API代码里比如在FastAPI路由函数里写model load_model(prod_v2.3.pth)。这导致每次模型更新都要修改代码、重新构建镜像、重新部署完全违背了“配置即代码”的原则。正确姿势是模型路径、版本号、预处理配置全部通过环境变量或配置中心如Consul、etcd注入API服务启动时动态加载。这样模型升级只需更新配置服务无需重启。忽略输入数据的Schema契约很多API文档只写“输入是JSON”却不定义每个字段的类型、范围、是否必填。结果是前端传了个字符串null给一个期望float的特征模型直接抛ValueError。Part 4强制要求所有生产API必须使用Pydantic V2定义严格的数据模型BaseModel并在FastAPI中作为request body的类型注解。这样请求在进入业务逻辑前就被自动校验、转换、过滤错误响应清晰明确如422 Unprocessable Entity极大降低下游调试成本。这些陷阱的共同根源是把ML服务当成一个“一次写好、永久运行”的静态程序而忽略了它作为一个数据驱动系统的动态本质。Part 4的所有设计都在对抗这种静态思维。3. 核心细节解析与实操要点让模型在生产环境“活下来”的12个关键动作3.1 动态模型加载与热更新告别“重启服务”式升级模型迭代是常态但服务中断是灾难。实现无缝热更新核心在于解耦模型实例与服务进程。我们采用“双模型实例原子切换”的模式# model_manager.py import threading from typing import Optional, Dict, Any import torch class ModelManager: def __init__(self): self._current_model: Optional[torch.nn.Module] None self._next_model: Optional[torch.nn.Module] None self._lock threading.RLock() # 可重入锁避免死锁 def load_model(self, model_path: str, config: Dict[str, Any]) - None: 异步加载新模型到_next_model不阻塞主服务 def _load(): try: new_model torch.load(model_path, map_locationcpu) # 这里可以加入模型校验逻辑如检查输入shape with self._lock: self._next_model new_model # 触发原子切换 self._swap_models() except Exception as e: logger.error(fFailed to load model from {model_path}: {e}) threading.Thread(target_load, daemonTrue).start() def _swap_models(self) - None: 原子切换确保切换瞬间只有一个有效模型 with self._lock: if self._next_model is not None: self._current_model, self._next_model self._next_model, None logger.info(Model swapped successfully) def get_model(self) - torch.nn.Module: 获取当前可用模型线程安全 with self._lock: return self._current_model在FastAPI中我们通过依赖注入的方式提供模型# main.py from fastapi import Depends, FastAPI from model_manager import ModelManager app FastAPI() model_manager ModelManager() app.post(/predict) def predict(request: PredictionRequest, model: torch.nn.Module Depends(model_manager.get_model)): if model is None: raise HTTPException(status_code503, detailModel not loaded) # 执行推理... return {result: result}实操心得map_locationcpu是关键。GPU模型加载到CPU内存避免占用GPU显存等真正推理时再model.to(device)这样加载过程不会阻塞GPU资源。使用threading.RLock而非Lock因为_swap_models可能在get_model内部被间接调用可重入锁防止自锁。必须加入模型校验逻辑如model.eval()、model.requires_grad_(False)防止加载了训练模式的模型导致意外梯度计算。热更新不是万能的。对于结构发生根本变化的模型如从CNN换成Transformer仍需滚动更新Rolling Update此时应配合K8s的Readiness Probe确保新Pod只有在模型加载并校验通过后才接收流量。3.2 生产级日志与可观测性让每一毫秒的延迟都有迹可循在Notebook里print()是调试利器在生产环境print()是性能杀手和信息黑洞。Part 4的日志体系遵循结构化、分级、可追溯三大原则结构化所有日志必须是JSON格式包含固定字段timestamp,level,service_name,trace_id,span_id,model_version,input_hash输入数据的SHA256摘要用于快速定位异常样本。我们使用structlog库实现import structlog import uuid # 配置structlog structlog.configure( processors[ structlog.stdlib.filter_by_level, structlog.stdlib.add_logger_name, structlog.stdlib.add_log_level, structlog.stdlib.PositionalArgumentsFormatter(), structlog.processors.TimeStamper(fmtiso), structlog.processors.StackInfoRenderer(), structlog.processors.format_exc_info, structlog.processors.UnicodeDecoder(), structlog.processors.JSONRenderer() # 关键输出JSON ], context_classdict, logger_factorystructlog.stdlib.LoggerFactory(), ) logger structlog.get_logger()分级定义清晰的日志级别语义DEBUG: 仅开发期开启记录模型内部张量形状、中间层输出。INFO: 记录请求ID、输入特征摘要、推理耗时、输出置信度。这是SRE日常巡检的主要来源。WARNING: 输入数据存在缺失值、特征值超出历史范围如age200、模型置信度低于阈值如0.3。ERROR: 模型加载失败、CUDA out of memory、输入Schema校验失败。CRITICAL: 服务进程崩溃、健康检查连续失败。可追溯集成OpenTelemetry为每个HTTP请求生成唯一的trace_id并贯穿整个调用链API → 模型推理 → 特征存储查询。这样当P99延迟飙升时我们能在Jaeger UI中直接看到是模型推理慢了还是特征查询慢了抑或是网络传输慢了。提示不要在日志里打印原始输入数据尤其是PII数据只打印input_hash和关键统计量如feature_mean,feature_std。这既是合规要求也避免日志爆炸。3.3 数据漂移检测模型的“血压计”和“体温计”模型性能衰减80%源于数据漂移Data Drift而非概念漂移Concept Drift。Part 4内置了一套轻量但有效的漂移检测机制核心是双时间窗口对比基线窗口Baseline Window模型上线时采集前7天的线上真实请求数据计算每个数值型特征的统计分布均值、标准差、分位数和类别型特征的分布各取值占比。这些基线数据持久化到Redis作为长期参考。滑动窗口Sliding Window实时采集最近1小时的请求数据同样计算统计分布。漂移判定对每个特征计算滑动窗口统计量与基线窗口的差异数值型使用KS检验Kolmogorov-Smirnov test计算分布差异p值若p 0.01则判定为严重漂移。类别型使用JS散度Jensen-Shannon Divergence若JS 0.1则判定为显著漂移。检测逻辑嵌入在推理Pipeline中但不阻塞主流程# drift_detector.py import numpy as np from scipy import stats from sklearn.metrics import jensenshannon class DriftDetector: def __init__(self, baseline_stats: dict): self.baseline baseline_stats self.sliding_buffer {} # 按特征名索引的滑动数组 def update_buffer(self, feature_name: str, value: float): 更新滑动缓冲区只保留最近1000个样本 if feature_name not in self.sliding_buffer: self.sliding_buffer[feature_name] [] self.sliding_buffer[feature_name].append(value) if len(self.sliding_buffer[feature_name]) 1000: self.sliding_buffer[feature_name].pop(0) def check_drift(self) - List[str]: 返回发生漂移的特征名列表 drifted_features [] for feat_name, buffer in self.sliding_buffer.items(): if len(buffer) 100: # 样本不足跳过 continue baseline_dist self.baseline.get(feat_name, {}) if not baseline_dist: continue # KS检验 _, p_value stats.kstest(buffer, lambda x: stats.norm.cdf(x, locbaseline_dist[mean], scalebaseline_dist[std])) if p_value 0.01: drifted_features.append(feat_name) return drifted_features当检测到漂移系统会记录WARNING日志包含漂移特征名和p值向企业微信/钉钉机器人发送告警附带漂移特征的历史分布图用Matplotlib生成Base64编码嵌入消息将漂移样本自动存入专门的drift_samplesS3桶供算法团队分析。注意漂移检测必须是“无感”的。它不能增加主推理路径的延迟。因此所有计算包括KS检验都应在后台线程中异步进行且采样率可配置如每100个请求采样1个。3.4 资源隔离与弹性伸缩给GPU一张“专属工位”在共享GPU服务器上一个模型的OOMOut of Memory会杀死整个进程连带其他模型服务。Part 4强制实施GPU资源硬隔离CUDA_VISIBLE_DEVICES这是最基础也最关键的隔离。在启动Uvicorn时通过环境变量指定可见GPU# 启动一个只使用GPU 0的模型服务 CUDA_VISIBLE_DEVICES0 uvicorn main:app --host 0.0.0.0:8001 --workers 2 # 启动另一个只使用GPU 1的模型服务 CUDA_VISIBLE_DEVICES1 uvicorn main:app --host 0.0.0.0:8002 --workers 2显存限制Memory Limit使用nvidia-docker或docker run --gpus device0 --memory4g为容器设置显存上限。但这只是软限制真正的硬限制需要在PyTorch中设置# 在模型加载后立即设置显存限制 import torch torch.cuda.set_per_process_memory_fraction(0.8) # 限制为GPU总显存的80% # 或者更精细地根据模型大小计算 model_size_mb 1200 # 模型参数缓存约1200MB torch.cuda.set_per_process_memory_fraction(model_size_mb / 16000) # 假设GPU有16GB弹性伸缩策略基于K8s的HPAHorizontal Pod Autoscaler不能只看CPU/Memory必须看自定义指标。我们导出两个关键指标到Prometheusml_model_request_latency_seconds_bucket{modelfraud_v3, le0.2}P95延迟小于200ms的请求数。ml_model_queue_length{modelfraud_v3}等待处理的请求队列长度由Uvicorn的--workers和--limit-concurrency控制。HPA配置示例# hpa.yaml apiVersion: autoscaling/v2 kind: HorizontalPodAutoscaler metadata: name: fraud-model-hpa spec: scaleTargetRef: apiVersion: apps/v1 kind: Deployment name: fraud-model-deployment minReplicas: 2 maxReplicas: 10 metrics: - type: Pods pods: metric: name: ml_model_queue_length target: type: AverageValue averageValue: 5 # 当平均队列长度5就扩容 - type: Pods pods: metric: name: ml_model_request_latency_seconds_bucket selector: matchLabels: le: 0.2 target: type: AverageValue averageValue: 100 # 当P95延迟200ms的请求数100就扩容这套组合拳确保了即使某个模型因bug疯狂申请显存也不会影响同服务器上的其他模型服务且能根据真实业务压力自动扩缩容。4. 实操过程与核心环节实现从零搭建一个可监控、可伸缩的ML服务4.1 环境准备与依赖管理用Dockerfile封印所有不确定性一切生产化实践始于一个可复现、可审计的构建环境。我们的Dockerfile遵循“最小化、分层化、可验证”原则# Dockerfile # 第一阶段构建阶段安装编译依赖 FROM pytorch/pytorch:2.0.1-cuda11.7-cudnn8-runtime AS builder # 安装编译工具和系统依赖 RUN apt-get update apt-get install -y \ build-essential \ libpq-dev \ rm -rf /var/lib/apt/lists/* # 复制requirements.txt并安装Python依赖先装不带C扩展的 COPY requirements.txt . RUN pip install --no-cache-dir --upgrade pip RUN pip install --no-cache-dir -r requirements.txt # 第二阶段运行阶段只包含运行时依赖 FROM pytorch/pytorch:2.0.1-cuda11.7-cudnn8-runtime # 复制第一阶段安装好的Python包 COPY --frombuilder /opt/conda/lib/python3.9/site-packages /opt/conda/lib/python3.9/site-packages COPY --frombuilder /opt/conda/bin /opt/conda/bin # 创建非root用户提升安全性 RUN groupadd -g 1001 -f appuser useradd -r -u 1001 -g appuser appuser USER appuser # 复制应用代码和模型 WORKDIR /app COPY --chownappuser:appuser . . # 验证模型文件完整性关键 RUN sha256sum models/fraud_v3.pth | grep a1b2c3d4e5f6... || exit 1 # 暴露端口 EXPOSE 8000 # 启动命令使用非root用户 CMD [uvicorn, main:app, --host, 0.0.0.0:8000, --port, 8000, --workers, 4]参数选择与计算过程--workers 4这个数字不是拍脑袋定的。我们通过压测确定在目标GPUA10上单个Uvicorn worker处理一个推理请求的平均耗时是120ms。要达到目标QPS300理论最小worker数 300 * 0.12 36。但Uvicorn是异步框架一个worker能并发处理多个请求受限于--limit-concurrency。我们设置--limit-concurrency 10所以实际需要的worker数 ceil(36 / 10) 4。这个计算过程必须记录在部署文档中作为容量规划的依据。pytorch:2.0.1-cuda11.7-cudnn8-runtime选择这个镜像而非devel版是因为runtime镜像体积小3GB、攻击面小、且已预编译好CUDA kernel启动更快。cuda11.7是经过验证与我们GPU驱动兼容的版本避免了nvcc版本冲突导致的Illegal instruction错误。4.2 模型服务API开发用FastAPI写出“自带说明书”的接口一个生产级API其文档应该和代码一样可靠。FastAPI的OpenAPI自动生成能力正是为此而生。我们定义了一个严格的PredictionRequest模型# schemas.py from pydantic import BaseModel, Field, validator from typing import List, Optional, Dict, Any import re class Feature(BaseModel): name: str Field(..., description特征名称必须与训练时一致) value: float Field(..., ge-1e6, le1e6, description特征数值范围[-1e6, 1e6]) validator(name) def name_must_be_alphanumeric(cls, v): if not re.match(r^[a-zA-Z0-9_]$, v): raise ValueError(Feature name must be alphanumeric and underscore only) return v class PredictionRequest(BaseModel): request_id: str Field(..., description唯一请求ID用于追踪) timestamp: int Field(..., ge0, descriptionUnix时间戳秒) features: List[Feature] Field(..., min_items10, max_items100, description特征列表至少10个最多100个) metadata: Optional[Dict[str, Any]] Field(default{}, description元数据如用户ID、设备信息等) validator(features) def features_must_have_unique_names(cls, v): names [f.name for f in v] if len(names) ! len(set(names)): raise ValueError(Feature names must be unique) return v class PredictionResponse(BaseModel): request_id: str prediction: float Field(..., ge0.0, le1.0, description预测概率) confidence: float Field(..., ge0.0, le1.0, description模型置信度) model_version: str Field(..., description当前服务的模型版本) latency_ms: float Field(..., ge0.0, description端到端延迟毫秒)在API路由中我们不仅做推理还做全链路监控# main.py from fastapi import FastAPI, HTTPException, Depends, BackgroundTasks from starlette.middleware.base import BaseHTTPMiddleware from datetime import datetime import time import asyncio app FastAPI(titleFraud Detection API, versionv3.2) # 全局中间件记录请求延迟和错误 app.middleware(http) async def add_process_time_header(request: Request, call_next): start_time time.time() try: response await call_next(request) process_time (time.time() - start_time) * 1000 response.headers[X-Process-Time-ms] str(round(process_time, 2)) # 上报延迟指标到Prometheus REQUEST_LATENCY.labels( endpointrequest.url.path, methodrequest.method, status_coderesponse.status_code ).observe(process_time) return response except Exception as exc: process_time (time.time() - start_time) * 1000 ERROR_COUNTER.labels( endpointrequest.url.path, methodrequest.method, error_typetype(exc).__name__ ).inc() raise exc app.post(/predict, response_modelPredictionResponse) async def predict( request: PredictionRequest, background_tasks: BackgroundTasks, model: torch.nn.Module Depends(model_manager.get_model) ): if model is None: raise HTTPException(status_code503, detailModel not ready) # 1. 特征校验与标准化在CPU上做避免GPU争抢 try: input_tensor preprocess_features(request.features) # 自定义预处理函数 except ValueError as e: raise HTTPException(status_code400, detailfFeature preprocessing failed: {e}) # 2. GPU推理关键路径 start_infer time.time() with torch.no_grad(): output model(input_tensor.to(cuda)) infer_time (time.time() - start_infer) * 1000 # 3. 后处理与结果包装 prediction_prob torch.sigmoid(output).item() confidence calculate_confidence(output) # 基于输出分布计算 # 4. 异步任务日志记录、漂移检测、指标上报 background_tasks.add_task(log_prediction, request, prediction_prob, confidence, infer_time) background_tasks.add_task(drift_detector.update_buffer, amount, request.get_feature_value(amount)) return PredictionResponse( request_idrequest.request_id, predictionprediction_prob, confidenceconfidence, model_versionfraud_v3.2, latency_msround(infer_time (time.time() - start_infer) * 1000, 2) # 简化实际更精确 )实操现场记录在首次上线时我们发现preprocess_features函数中一个np.log()操作在遇到0值时会返回-inf导致后续GPU计算崩溃。解决方案是在Pydantic的validator中加入ge0.001约束并在预处理函数中添加np.clip(value, a_min0.001, a_maxNone)。这个教训告诉我们数据校验必须前置到API入口而不是等到模型内部。background_tasks的使用至关重要。它把日志、监控、漂移检测这些“副作用”从主请求路径剥离确保P99延迟只反映核心推理耗时。我们实测加入background_tasks后P99延迟从210ms降至185ms降幅12%。4.3 监控告警与可视化用Grafana看懂模型的“健康体检报告”一个没有监控的ML服务就像一辆没有仪表盘的赛车。Part 4的监控体系围绕四个黄金指标构建指标类别具体指标采集方式告警阈值Grafana看板重点可用性http_requests_total{status~5..} / http_requests_totalPrometheus HTTP Exporter 0.1%红色大数字突出显示延迟http_request_duration_seconds_bucket{le0.2}Prometheus client in FastAPIP95 200ms折线图对比7天趋势资源container_gpu_utilization{containerfraud-model}NVIDIA DCGM Exporter 95% for 5min柱状图按GPU ID分组数据质量ml_model_input_null_ratio{featureage}自定义Exporter 5%热力图展示所有特征缺失率Grafana看板设计遵循“一页一问题”原则首页看板Dashboard Overview只放4个核心指标卡片可用性、P95延迟、GPU利用率、关键特征缺失率顶部用大号字体显示当前值和环比变化↑2.3%。这是SRE晨会的第一眼信息。延迟分析看板Latency Breakdown用火焰图Flame Graph展示一次请求的完整耗时分解DNS解析 → TCP连接 → TLS握手 → 请求读取 → 特征预处理 → GPU推理 → 后处理 → 响应写入。我们发现某次延迟飙升的根源是TLS握手耗时从5ms涨到80ms最终定位到是负载均衡器的证书轮换未同步。数据漂移看板Data Drift Monitor左侧是关键特征如transaction_amount,user_age的实时分布直方图右侧是它们与基线分布的KS检验p值随时间变化的折线图。当p值跌破0.01的红线图表自动变红并闪烁。实操心得告警不是越多越好。我们只对P95延迟 200ms AND 持续5分钟、5xx错误率 1% AND 持续2分钟、GPU利用率 95% AND 持续10分钟这三个组合条件设置PagerDuty告警。其他指标只在Grafana中可视化避免告警疲劳。4.4 灰度发布与回滚用Kubernetes的金丝雀发布保护业务模型上线最怕“一刀切”。Part 4采用Kubernetes的ServiceIngressCanary策略实现平滑过渡# canary-deployment.yaml apiVersion: apps/v1 kind: Deployment metadata: name: fraud-model-canary labels: app: fraud-model version: v3.3-canary spec: replicas: 1 # 只启1个Canary Pod selector: matchLabels: app: fraud-model version: v3.3-canary template: metadata: labels: app: fraud-model version: v3.3-canary spec: containers: - name: model image: registry.example.com/fraud-model:v3.3-canary env: - name: MODEL_PATH value: /models/fraud_v3.3.pth --- # service.yaml apiVersion: v1 kind: Service metadata: name: fraud-model-service spec: selector: app: fraud-model ports: - port: 8000 targetPort: 8000配合Istio的VirtualService实现流量切分# virtual-service.yaml apiVersion: networking.istio.io/v1alpha3 kind: VirtualService metadata: name: fraud-model-vs spec: hosts: - fraud-api.example.com http: - route: - destination: host: fraud-model-service subset: stable weight: 90 # 90%流量到v3.2 - destination: host: fraud-model-service subset: canary weight: 10 # 10%流量到v3.3 --- apiVersion: networking.istio.io/v1alpha3 kind: DestinationRule metadata: name: fraud-model-dr spec: host: fraud-model-service subsets: - name: stable labels: version: v3.2 - name: canary labels: version: v3.3-canary