企业官网建设流程全解析

1. 项目概述：这不是一次“部署上线”，而是一场从实验室到产线的系统性迁移

“From Notebook to Production: Running ML in the Real World (Part 4)”——这个标题里藏着太多被新手忽略的潜台词。它不是教你怎么把model.fit()跑通，也不是演示如何用Flask搭个API接口就喊“上线成功”。它直指一个残酷现实：你在Jupyter里调出98.7%准确率的模型，和它在凌晨三点扛住电商大促流量、持续输出稳定预测、自动熔断异常输入、日志可追溯、版本可回滚、资源不越界、监控有告警——这中间隔着的不是几行代码，而是一整套工程化认知体系。我带过二十多个落地项目，亲眼见过太多团队卡在Part 4：模型在测试环境跑得飞起，一上生产就内存爆满、延迟飙升、特征漂移无声无息、AB测试结果无法归因。Part 4的本质，是把“能跑”变成“敢用”，把“实验产物”变成“业务资产”。它覆盖的不是某个工具链，而是数据流、模型流、服务流、反馈流四条主干道的协同治理。关键词里的ML in the Real World，核心不在“ML”，而在“Real World”——真实世界意味着不确定性、时变性、协作复杂性和成本刚性。你不需要成为Kubernetes专家，但必须清楚模型容器化后CPU限制设为2核还是4核，会直接决定单实例吞吐量是30 QPS还是120 QPS；你不必手写Prometheus exporter，但得明白为什么model_prediction_latency_seconds_bucket这个指标比accuracy更能反映线上健康度。这篇文章面向的是已经能把模型训出来的工程师、数据科学家，以及那些正被“为什么上线后效果掉点”“为什么运维总说我们服务不稳定”“为什么AB测试结论打架”这些问题反复捶打的技术负责人。它不提供银弹，但给你一套可验证、可裁剪、已在金融风控、智能客服、工业质检等场景反复打磨过的落地检查清单。

2. 内容整体设计与思路拆解：为什么Part 4必须聚焦“可观测性+弹性+反馈闭环”三位一体

2.1 拒绝“一次性部署思维”：真实世界的模型是活的，不是标本

很多团队的Part 4实践，本质是把Notebook导出为Python脚本，再用Gunicorn包一层，扔进Docker跑起来。这看似完成了“部署”，实则埋下三颗定时炸弹：第一，状态不可知——你不知道模型当前每秒处理多少请求、平均延迟多少、失败率几何、特征分布是否偏移；第二，弹性不可控——流量高峰时实例自动扩缩容策略缺失，要么资源闲置浪费，要么雪崩式宕机；第三，进化不可持续——线上预测结果没有反哺训练数据，模型像离线孤岛，越用越老。我参与过一个推荐系统迁移，初期采用纯静态部署，结果双十一大促期间，因未配置水平扩缩容（HPA），单实例CPU打满至98%，P99延迟从200ms飙到2.3秒，用户点击率直接跌了17%。复盘发现，问题根源不在模型本身，而在整个服务架构缺乏对“真实流量脉搏”的感知与响应能力。因此，Part 4的设计起点，必须从“让模型跑起来”转向“让模型在变化中稳住并进化”。这决定了我们技术选型的底层逻辑：所有工具链必须服务于三个核心目标——可观测性（Observability）、弹性（Resilience & Scalability）、反馈闭环（Feedback Loop）。它们不是并列选项，而是环环相扣的铁三角：可观测性提供决策依据，弹性保障服务底线，反馈闭环驱动持续优化。放弃其中任一环，Part 4就只是半成品。

2.2 工具链选型逻辑：不追新，只求“够用、可控、可审计”

在Kubeflow、Seldon、KServe、MLflow、BentoML这些名词满天飞的时代，Part 4最危险的陷阱就是陷入“工具军备竞赛”。我见过团队花三个月集成Kubeflow Pipelines，结果连基础的模型版本灰度发布都没跑通，因为其抽象层过于厚重，调试链路长达十几层。真实产线要的是“确定性”而非“先进性”。我们的选型原则非常朴素：

• 可观测性层：放弃自研Metrics Collector，直接采用OpenTelemetry SDK + Prometheus + Grafana黄金组合。理由很实在：OpenTelemetry是CNCF毕业项目，SDK侵入式埋点代码仅需5行，且社区插件覆盖Flask/FastAPI/Triton等所有主流框架；Prometheus的Pull模型天然适配容器化环境，Grafana仪表盘模板社区超2000个，金融客户要求的“预测延迟分位图+特征统计热力图”半小时就能搭出来。
• 弹性服务层：不碰Knative或KEDA这类复杂事件驱动方案，首选Kubernetes原生HPA（Horizontal Pod Autoscaler）+ 自定义指标（如基于http_requests_total或model_inference_duration_seconds_sum）。实测表明，HPA配合Prometheus Adapter，从CPU阈值触发到新Pod Ready，平均耗时47秒，完全满足电商类业务分钟级弹性需求；而Knative的冷启动问题，在实时性要求高的场景（如风控决策）会导致不可接受的首请求延迟。
• 反馈闭环层：拒绝重造数据管道轮子。直接用Apache Kafka作为预测结果与原始特征的统一消息总线，下游接Flink做实时特征计算（如“用户近10分钟点击率”），同时用Debezium捕获业务库变更，通过CDC（Change Data Capture）将用户行为事件（如购买、退款）实时注入训练数据湖。这套组合的优势在于：所有组件均为成熟数据领域基础设施，运维团队已有知识储备，故障排查路径清晰——Kafka lag高？查消费者组；Flink任务背压？看反压指标；Debezium连接中断？看MySQL binlog position。这种“用熟不用生”的策略，让Part 4的落地周期从预估6个月压缩到11周，且上线后首个季度无P1级故障。

2.3 架构演进路径：从“单体服务”到“领域驱动服务化”的必然选择

Part 4的终极形态，绝非一个巨石型ML服务。我们观察到，所有成功跨越Part 4的团队，最终都走向了按业务域拆分的微服务架构。以某保险公司的车险定价模型为例：初期所有逻辑（特征工程、模型推理、规则引擎、报价生成）打包在一个FastAPI服务里。上线后很快暴露问题——精算师要调整折旧率计算规则，需全量回归测试；AI团队升级XGBoost到LightGBM，却因特征预处理代码耦合，导致报价金额偏差超0.5%。后来我们按DDD（领域驱动设计）思想重构：

• 特征服务（Feature Serving）：独立服务，提供/features?entity_id=car_123&as_of=2024-05-20接口，所有模型消费同一份实时特征；
• 模型服务（Model Serving）：仅负责加载模型、执行predict()，输入为标准化特征向量，输出为原始分数；
• 决策服务（Decision Service）：聚合模型分数、业务规则、外部数据（如天气API），生成最终报价与风险等级。
  这种拆分带来质变：特征服务由数据平台团队统一维护，保证全公司特征一致性；模型服务由AI团队独立迭代，A/B测试可精确到单个模型版本；决策服务由业务方掌控，规则变更无需AI团队介入。更重要的是，可观测性指标得以精准归因——当发现报价延迟升高，可快速定位是特征服务DB查询慢（feature_db_query_duration指标飙升），还是模型服务GPU显存不足（gpu_memory_utilization达95%），而非在单体服务里大海捞针。Part 4的深度，就体现在这种对业务复杂性的尊重与解耦能力上。

3. 核心细节解析与实操要点：从代码到产线的12个关键断点检查

3.1 断点1：特征一致性——Notebook与生产环境的“特征鸿沟”如何填平？

这是Part 4里最高频、最隐蔽的坑。你在Notebook里用pandas.read_csv('data.csv')读取数据，sklearn.preprocessing.StandardScaler().fit_transform(X)做标准化，一切完美。但生产环境里，特征工程代码若未封装为可复用函数，或未与训练时使用完全相同的StandardScaler对象（含mean/std参数），就会导致输入特征分布偏移，模型效果断崖下跌。我们强制推行“特征工厂（Feature Factory）”模式：所有特征处理逻辑必须定义在独立Python模块（如features/vehicle_features.py）中，并通过joblib.dump(scaler, 'scaler.joblib')持久化训练时的转换器。生产服务加载模型时，同步加载对应scaler.joblib。更进一步，我们要求每个特征函数必须带version参数，例如：

def calc_vehicle_age(entity_id: str, as_of_date: datetime, version: str = "v1") -> float: if version == "v1": # 原始逻辑：注册日期到as_of_date的年数 return (as_of_date - get_reg_date(entity_id)).days / 365.25 elif version == "v2": # 新逻辑：引入车辆使用强度修正因子 base_age = (as_of_date - get_reg_date(entity_id)).days / 365.25 intensity = get_usage_intensity(entity_id) return base_age * (1 + 0.2 * intensity) # v2新增

这样，当精算师提出新特征逻辑，只需新增version="v2"分支，旧模型继续用v1，新模型指定v2，避免全量切换风险。> 提示：务必在CI/CD流水线中加入“特征一致性校验”步骤——用相同输入数据，对比Notebook导出的特征向量与生产服务返回的特征向量，逐元素比对，差异超过1e-6即阻断发布。

3.2 断点2：模型序列化——Pickle的甜蜜陷阱与安全替代方案

joblib.dump(model, 'model.pkl')是Notebook里的惯用操作，但它在生产环境是颗雷。Pickle协议存在严重安全隐患：反序列化任意二进制数据可执行任意代码；且不同Python版本、不同scikit-learn版本间Pickle文件不兼容，曾导致某客户因服务器升级Python 3.8→3.9，所有模型加载失败，服务瘫痪2小时。我们的硬性规定：禁止在生产环境使用Pickle序列化模型。替代方案分三层：

• 轻量级模型（<10MB）：用ONNX（Open Neural Network Exchange）格式。XGBoost/LightGBM/Scikit-learn均支持model.export_model(format='onnx')，ONNX Runtime推理速度比原生Python快3-5倍，且跨语言、跨平台、无代码执行风险。
• 深度学习模型：TensorFlow SavedModel或PyTorch TorchScript。前者支持TensorFlow Serving，后者经torch.jit.script(model)编译后，可脱离Python解释器运行，内存占用降低40%。
• 超大模型（>1GB）：采用模型分片（Model Sharding）+ 参数服务器（Parameter Server）架构。例如，将BERT-large的1000万参数按层切分，每个gRPC服务实例只加载部分层，通过model_layer_1:50051、model_layer_2:50052等地址协同推理。这虽增加网络开销，但规避了单机内存瓶颈，某NLP项目实测，分片后单节点内存从24GB降至8GB，集群可用性提升至99.99%。

3.3 断点3：服务接口设计——REST vs gRPC：别让通信协议拖垮你的P99延迟

很多团队默认用Flask/FastAPI提供RESTful API，这在低QPS场景没问题，但当QPS超500、模型输入为高维向量（如1024维Embedding）时，JSON序列化/反序列化开销会吃掉30%以上延迟。我们做过对比测试：对同一LightGBM模型（输入128维特征），分别用FastAPI REST和gRPC提供服务：

3.4 断点4：资源隔离——为什么你的模型服务总在OOM Killer下“猝死”？

Kubernetes里不设resources.limits，等于给模型服务发了一张“无限透支信用卡”。某次上线，一个未限制内存的LSTM模型服务，在处理长文本序列时，因PyTorch缓存机制，内存从2GB一路涨到16GB，触发Linux OOM Killer，进程被粗暴杀死，服务雪崩。正确姿势是：为每个容器设置精确的requests和limits。计算方法如下：

1. 内存（Memory）：在测试环境，用psutil.Process().memory_info().rss监控模型加载后、空载时的常驻内存（RSS），再模拟峰值QPS压力，记录最大RSS。取两者较大值，乘以1.3冗余系数。例如，空载RSS=1.2GB，峰值RSS=2.8GB →requests=2.8Gi, limits=3.6Gi。
2. CPU：用time命令测量单次推理耗时，结合目标QPS计算理论CPU需求。例如，单次推理耗时150ms，目标QPS=100 → 每秒需15秒CPU时间 → 理论需15核。但实际需考虑上下文切换、I/O等待，我们按理论值 × 1.5设requests，limits设为requests × 2。故requests=22.5, limits=45（单位mCPU，即22500m）。

实操心得：limits设得太低，容器会被OOM Killer杀；设得太高，K8s调度器无法有效利用节点资源。我们坚持“宁紧勿松”，通过HPA动态扩缩容来应对流量波动，而非靠单实例硬扛。

3.5 断点5：健康探针——Liveness与Readiness探针的生死线

K8s的livenessProbe和readinessProbe是服务稳定的基石，但90%的团队配置错误。常见错误：

• 用/healthz端点做Liveness：该端点只检查进程存活，不验证模型能否真正推理。结果服务进程活着，但模型因GPU显存不足卡死，K8s却认为健康，持续转发流量，导致大量超时。
• Readiness探针超时时间过短：设为timeoutSeconds=1，而模型首次加载需3秒（如BERT加载词表），Pod永远无法进入Ready状态。
  我们的标准配置：

livenessProbe: httpGet: path: /healthz/live port: 8000 initialDelaySeconds: 60 # 给足模型加载时间 periodSeconds: 30 # 每30秒检查一次 timeoutSeconds: 5 # 超时5秒即判为不健康 readinessProbe: httpGet: path: /healthz/ready port: 8000 initialDelaySeconds: 120 # 首次就绪检查延后2分钟 periodSeconds: 10 # 每10秒检查一次 timeoutSeconds: 3 # 就绪检查更严格

关键在/healthz/live和/healthz/ready的实现逻辑：

• live端点：仅检查进程、端口、基础依赖（如Redis连接），不涉及模型；
• ready端点：必须执行一次真实推理（如用预置的test_sample.json调用predict()），并验证返回码、延迟（<500ms）、结果合理性（如分数在[0,1]区间）。只有ready通过，K8s才将Pod加入Service Endpoints，接收真实流量。这确保了“能接流量”即“真能干活”。

3.6 断点6：日志规范——为什么你的日志在故障时“查无可查”？

Notebook里print("Predicting...")的随意日志，在生产环境是灾难。我们强制推行结构化日志（Structured Logging）：所有日志必须是JSON格式，包含固定字段。例如，一次预测请求的日志：

{ "timestamp": "2024-05-20T08:30:45.123Z", "level": "INFO", "service": "model-service", "version": "1.2.4", "request_id": "req_abc123", "model_name": "fraud_xgb_v3", "input_features": {"age": 35, "income": 85000, "trans_count_24h": 12}, "prediction_score": 0.872, "inference_latency_ms": 42.5, "status": "success" }

关键设计：

• request_id贯穿全链路：从API网关生成，经特征服务、模型服务、决策服务，所有日志携带同一ID，故障时可一键串联完整调用链；
• input_features采样记录：非全量记录（防隐私泄露），而是按feature_sampling_rate=0.01随机采样1%请求的特征，用于事后分析特征漂移；
• status字段驱动告警：ELK或Loki中设置告警规则——status: "error"且inference_latency_ms > 1000连续5次，即触发P1告警。

注意：日志级别要克制。DEBUG日志仅在开发环境开启，生产环境默认INFO，ERROR必须包含可操作的根因提示（如"ERROR: Failed to load model from s3://bucket/model.onnx: ConnectionTimeout (15s)"），而非模糊的"Model load failed"。

3.7 断点7：监控指标——别再只盯着Accuracy，P99延迟才是生命线

Accuracy、F1-score是训练阶段的“成绩单”，线上监控必须切换到“服务健康度”视角。我们定义核心SLO（Service Level Objective）指标：

• 可用性（Availability）：1 - (sum(rate(http_request_total{status=~"5.."}[1h])) / sum(rate(http_request_total[1h]))) > 0.9995；
• 延迟（Latency）：histogram_quantile(0.99, rate(model_inference_duration_seconds_bucket[1h])) < 200（P99延迟<200ms）；
• 饱和度（Saturation）：container_memory_usage_bytes{container="model-service"} / container_spec_memory_limit_bytes > 0.85（内存使用率>85%即预警）。
  特别强调model_inference_duration_seconds_bucket——这是模型服务专属指标，必须在代码中手动埋点：

from prometheus_client import Histogram INFERENCE_DURATION = Histogram( 'model_inference_duration_seconds', 'Model inference duration in seconds', buckets=(0.01, 0.025, 0.05, 0.1, 0.2, 0.5, 1.0, 2.0, 5.0) ) # 在predict()函数内 with INFERENCE_DURATION.time(): result = model.predict(input_data)

这样，Grafana就能绘制出延迟分布直方图，一眼看出是“大部分快、个别极慢”（需查异常样本），还是“整体缓慢”（需优化模型或硬件）。> 实操心得：不要迷信单一P99。我们同时监控P50/P90/P99，若P50=50ms、P90=80ms、P99=1500ms，说明存在长尾毛刺，应重点分析那1%的慢请求，而非盲目升级CPU。

3.8 断点8：配置管理——为什么你的“小修改”总引发线上事故？

config.yaml硬编码在代码仓库，每次改阈值都要发版，这是Part 4的大忌。我们采用“配置中心+环境隔离”方案：

• 配置中心：选用Apollo（国内企业主流）或Consul（海外常用），所有配置项（如model_version,feature_timeout_ms,ab_test_ratio）集中管理；
• 环境隔离：dev/staging/prod三套命名空间，prod环境配置变更需双人复核+灰度发布；
• 热更新：服务监听配置变更事件，无需重启即可生效。例如，当ab_test_ratio从0.0（全量旧模型）改为0.1（10%流量切新模型），服务自动加载新分流策略。
  关键实践：所有配置项必须带类型声明与校验。Apollo中定义feature_timeout_ms为Integer类型，范围[100, 5000]，超出即拒绝提交。这避免了"1000"字符串被误解析为1000整数，或50000毫秒（50秒）超时导致级联故障。

3.9 断点9：AB测试——如何科学归因，而非“玄学对比”？

很多团队的AB测试，只是把新旧模型各挂一个Endpoint，用Nginx 50/50分流，然后看“转化率”数字。这忽略了混杂变量：新模型上线时段恰逢周末，旧模型在工作日，结果差异根本无法归因于模型。我们强制要求：

• 流量分桶（Traffic Splitting）：基于user_id哈希，而非简单轮询。hash(user_id) % 100，0-49为A组（旧模型），50-99为B组（新模型）。确保同一用户始终看到同一模型结果，消除用户行为波动干扰；
• 指标对齐（Metric Alignment）：AB测试必须定义核心指标（Primary Metric）与护栏指标（Guardrail Metrics）。例如，推荐系统核心指标是“7日留存率”，护栏指标是“单日PV”“平均停留时长”。若新模型提升留存率但PV下降10%，说明可能过度激进，需叫停；
• 统计显著性（Statistical Significance）：必须达到p-value < 0.05且minimum detectable effect (MDE)在业务可接受范围内（如留存率提升>0.5%）。我们用statsmodels.stats.proportion.proportions_ztest实时计算，Dashboard上红绿灯显示显著性状态。

注意：AB测试周期不能太短。我们要求最小样本量满足n > (Z_{α/2} + Z_β)^2 * p*(1-p) / δ^2，其中p为基线转化率，δ为MDE。某次测试因仅跑48小时，样本不足，得出“新模型差”的错误结论，返工重测耗时两周。

3.10 断点10：模型漂移检测——你的模型正在“悄悄变老”，你却浑然不觉

模型上线后，数据分布随时间推移而变化（Data Drift），是效果衰减的主因。某信贷模型上线3个月后，审批通过率从65%降至52%，起初以为是经济下行，后经漂移检测发现：用户年龄中位数从38岁升至45岁，而模型在45岁以上人群的AUC仅0.61（训练集为0.82）。我们构建三级漂移检测体系：

• 一级（实时）：对每个数值型特征，计算在线滑动窗口（1小时）的均值、标准差，与基线（训练集）对比，偏离超3σ即告警；
• 二级（小时级）：用KS检验（Kolmogorov-Smirnov Test）比较线上特征分布与训练分布，p-value < 0.01即触发；
• 三级（天级）：用PCA降维后，计算线上样本在训练样本主成分空间的投影距离，距离突增表明整体分布偏移。
  所有检测结果写入drift_alerts表，与Grafana联动。当age特征KS检验p-value跌破0.01，仪表盘自动标红，并推送企业微信告警：“用户年龄分布发生显著漂移，请核查数据采集逻辑或启动模型重训”。

3.11 断点11：回滚机制——当新模型翻车，你能在5分钟内回到“昨天”吗？

“回滚”不是一句口号，而是需要提前设计的逃生通道。我们要求：

• 模型版本原子化：每个模型版本（如fraud_xgb_v4）对应独立S3路径、独立Docker镜像Tag、独立K8s Deployment YAML；
• 蓝绿部署（Blue-Green）：新版本部署为greenDeployment，流量先切5%验证，无异常后切100%，旧blueDeployment保留24小时；
• 一键回滚脚本：rollback.sh脚本自动执行：1) 将Service流量切回blue；2) 删除greenDeployment；3) 清理green相关ConfigMap/Secret。实测从发现故障到回滚完成，耗时3分42秒。

关键经验：回滚后必须验证“状态一致性”。例如，风控模型回滚，需确认decision_log表中model_version字段已全部回退，而非仅服务流量切换。我们为此开发了post-rollback-checker，自动比对数据库记录与服务版本。

3.12 断点12：安全合规——GDPR、等保2.0不是纸面功夫

模型服务处理用户数据，安全合规是红线。我们落地三项硬措施：

• 数据脱敏（Data Sanitization）：所有日志、监控、采样数据中的PII（Personally Identifiable Information）字段（如id_card,phone）必须在入口处sha256()哈希，且哈希盐值定期轮换；
• 模型水印（Model Watermarking）：在训练数据中嵌入微小扰动（如对1%样本的某特征加1e-5噪声），使模型输出带有唯一指纹。若发现模型被非法复制，可通过输出反推水印，法律维权有据；
• 等保2.0适配：所有服务容器启用seccomp安全策略，禁用chmod、chown等危险系统调用；网络策略（NetworkPolicy）严格限制Pod间通信，模型服务仅允许来自API网关和特征服务的入站流量。
  某次等保测评，因未启用seccomp，被判定为“高风险项”，整改耗时一周。自此，我们把安全检查纳入CI/CD流水线，docker scan和kube-bench扫描不通过，自动阻断镜像推送。

4. 实操过程与核心环节实现：以电商实时推荐模型上线为例的全流程拆解

4.1 场景设定：从Notebook原型到支撑双11的推荐服务

我们以某电商平台“猜你喜欢”实时推荐模型为案例，完整走一遍Part 4落地。该模型目标：根据用户实时行为（点击、加购、搜索），在500ms内返回个性化商品列表，P99延迟≤300ms，日均调用量2.4亿次。Notebook原型已用LightGBM训练完成，AUC=0.89，特征包括：用户画像（年龄、性别、地域）、近期行为序列（最近10次点击商品ID的Embedding均值）、实时上下文（当前搜索词TF-IDF）。现在，我们要把它变成生产服务。

4.2 步骤1：特征服务化——构建统一、实时、可复用的特征工厂

第一步不是碰模型，而是解耦特征。我们将所有特征计算逻辑抽离，创建feature-service项目：

• 特征注册：在features/catalog.py中定义：

  FEATURES = { "user_age_embedding": { "type": "numerical", "source": "mysql://user_profile", "transform": "lambda x: [x['age']/100, x['gender_int']]", "ttl_seconds": 86400 # 缓存1天 }, "recent_clicks_mean_emb": { "type": "embedding", "source": "kafka://click_stream", "transform": "lambda clicks: np.mean([get_item_emb(c) for c in clicks[-10:]], axis=0)", "ttl_seconds": 300 # 实时特征，缓存5分钟 } }

• 特征API：用FastAPI实现/features端点，输入{"user_id": "u123", "as_of": "2024-05-20T08:00:00Z"}，返回标准化特征向量。关键优化：
  • 对user_age_embedding，用Redis缓存MySQL查询结果，GET user_profile:u123，命中率92%，P99延迟从85ms降至12ms；
  • 对recent_clicks_mean_emb，用Flink实时计算用户点击流，结果存入Redis Hash，HGETALL user_clicks:u123，避免Kafka消费延迟。
• 特征一致性测试：CI流水线中，用pytest跑test_feature_consistency.py，对比Notebook中calc_features(user_id="u123")与feature-service返回结果，误差>1e-5即失败。

4.3 步骤2：模型服务化——ONNX Runtime + gRPC的极致性能

模型服务model-service采用ONNX Runtime加速：

• 模型导出：Notebook中lgb_model.export_model(format='onnx', export_type='dict')，生成recommend.onnx；
• 服务框架：用onnxruntime-server（C++版）而非Python版，内存占用降低60%，P99延迟从210ms降至85ms；
• gRPC接口：定义recommend.proto：

  message PredictRequest { string user_id = 1; repeated float features = 2; // 特征向量 } message PredictResponse { repeated int32 item_ids = 1; // 推荐商品ID列表 repeated float scores = 2; // 对应分数 }

• 资源配置：K8s Deployment中设resources: {requests: {cpu: "2000m", memory: "4Gi"}, limits: {cpu: "4000m", memory: "6Gi"}}，HPA基于grpc_server_handled_total{service="model-service"}指标扩缩容。

4.4 步骤3：决策服务化——整合模型、规则与业务逻辑

decision-service是业务大脑：

• 输入：调用feature-service获取特征，调用model-service获取原始分数；
• 规则引擎：集成Drools，配置业务规则，如“新用户（注册<7天）推荐商品池扩大20%”、“高价值用户（VIP等级≥3）屏蔽低价商品”；
• 重排序（Re-ranking）：对模型输出的Top100商品，用轻量级规则（如库存>0、价格区间匹配）二次过滤，再按score * stock_weight重排；
• AB测试分流：基于user_id哈希，hash(user_id) % 100 < 10走新模型recommend_v2.onnx，其余走v1。

4.5 步骤4：可观测性基建——从“黑盒”到“玻璃盒子”

部署后，立即接入可观测性三件套：

• Metrics：在model-service中埋点model_inference_duration_seconds_bucket，在decision-service中埋点decision_latency_seconds_bucket；
• Tracing：用Jaeger，user_id作为Trace ID，串联API Gateway → decision-service → feature-service → model-service全链路；
• Logging：所有服务输出JSON日志，request_id贯穿全程。
  Grafana Dashboard配置：
• 主面板：P99延迟趋势（model/decision/feature分层）；
• 下钻面板：当model延迟飙升，查看onnx_runtime_execution_time子指标，定位是CPU瓶颈还是GPU显存不足；
• 告警面板：`rate(http_request_total{status=~"5.."}[5m]) >