专篇 · Java×Python 混合部署生产实践

考察你是否意识到：Java 业务服务 + Python Agent/推理服务共存时，容量不是两者基线的简单相加。峰值时段的资源争抢（CPU、内存带宽、GC 停顿、GPU 显存）会让整体吞吐远低于各自单测之和。

混部容量规划演进：① 单栈容量（求拐点）——各栈独立压测找吞吐/延迟拐点；② 叠加估算（相加）——早期直接把两栈基线相加，严重高估；③ 叠加压测实测——两栈同时加压，测出互扰后的真实总容量；④ 互扰系数建模——把 GC 抢核、NUMA 跨节点、总线争抢量化成系数；⑤ 动态配额 + 容量档案数字化——按业务时段调配额，互扰系数沉淀为可复用档案。主线是从「各求拐点」到「求互扰」。

分别画像：Java 侧关注线程池饱和、堆外内存、GC 停顿（STW 会阻塞同节点所有线程）；Python 侧关注 GIL 对 CPU 密集的瓶颈、asyncio 事件循环吞吐、GPU 显存与算力占用。

叠加模型：总容量 ≈ 业务基线 + Agent 推理峰值 − 互扰损耗。互扰损耗来自同节点 CPU 争抢（GC 与推理抢核）、NUMA 跨节点内存访问延迟、共享总线带宽竞争。叠加系数须通过「叠加压测」实测，不能拍脑袋。

1. 先分别压测 Java 与 Python 栈，记录各自拐点（吞吐/延迟/P99）。
2. 再做「叠加压测」：两栈同时加压，测出互扰后的真实总容量。
3. 建立容量档案：基线、峰值倍数、互扰系数、预留缓冲（建议 20%~30%）。
4. 按业务时段动态调整配额，大促前做专项混部压测。

陷阱：各测各的然后相加，上线后真实混部下 GC 停顿拖慢推理线程、GPU 推理抢占 CPU 调度，整体容量腰斩。

单栈容量规划是「求拐点」，混部容量规划是「求互扰」。前者有成熟模型，后者必须靠实测——因为互扰路径（GC 与推理抢核、显存与堆外抢带宽）无法纯理论推导。容量档案的核心价值就是记录这套互扰系数。

1. 各测各的然后相加：上线后 GC 停顿拖慢推理线程、GPU 抢占 CPU 调度，整体容量腰斩。
2. 忽略 GC 停顿对邻居的传导：Java STW 会阻塞同节点所有线程，包括推理 worker。
3. 不预留缓冲（20%~30%）：峰值叠加 + 互扰余量被吃掉，常态接近满负荷。
4. 只按 CPU 算忽略内存带宽/NUMA：跨节点访问延迟与带宽竞争才是隐性瓶颈。
5. 大促前不专项混部压测：平时低负载掩盖互扰，大促一加压就崩。

考察成本黑盒的认知：一台混部机、一张 GPU 卡同时跑 Java 业务与 Python 推理，成本怎么分摊？不清的归属会让「降本」退化成团队间的甩锅游戏。

混部成本治理演进：① 不分摊（黑盒）——一台机成本归谁都说不清；② 按资源配额申请——简单但「申请 ≠ 使用」，易浪费；③ 按实际使用计量——CPU/内存/GPU 时长打标计量，公平但要计量基建；④ 按业务线归因——最终归因到 unit economics；⑤ FinOps 单位经济——把 GPU 利用率作为一级健康度，闲置回收、低峰降配。主线是「从甩锅式黑盒到可优化自身用量的归因体系」。

成本归属三法：① 按资源配额（申请的而非用的，简单但易浪费）；② 按实际使用（计量 CPU·内存·GPU 时长，公平但需计量基建）；③ 按业务线（最终归因到产出，最贴近 unit economics）。

FinOps 视角：核心指标是「单位推理成本」「单位请求成本」「GPU 利用率」。GPU 是混部里最贵的资源，利用率每提升 10%，整体成本显著下降。

1. 资源打标：namespace/team/cost-center 标签，按标签计量。
2. 建立单位经济指标看板，把 GPU 利用率作为一级健康度。
3. 闲置 GPU 回收（缩容/调度给其他负载），低峰时段降配。
4. 事前定义分摊规则并写入成本治理规范，避免事后扯皮。

判据：成本归属的有效性 = 团队能否据此优化自身用量。若归属后无人改行为，说明计量粒度或规则有问题。

混部降本的真正杠杆是「 GPU 利用率」而非「少买机器」。很多团队把 Java 与 Python 混部是为了提高单机利用率，但若缺乏计量，反而因为互扰导致两者都降效，成本不降反升。计量先行，优化才有靶心。

1. 成本黑盒导致甩锅：无 namespace/team/cost-center 标签，降本退化成团队扯皮。
2. 只按申请不按使用：资源申请大、实际用得少，整体利用率低。
3. GPU 利用率低不优化：GPU 是混部最贵资源，利用率每升 10% 成本显著降。
4. 归属后无人改行为：说明计量粒度或分摊规则有问题，应回炉。
5. 缺计量基建强行分摊：没有计量就拍比例，结果不公平反而激化矛盾。

考察故障传导意识：一个 Python 推理进程 OOM 把同节点 Java 业务拖垮，就是故障域没隔离。混部的容灾难点是「爆炸半径更难预测」。

混部容灾演进：① 单栈各自高可用——以为两栈都 HA 就稳；② 识别共享故障域——节点/可用区/资源池都是边界，共享即必然传导；③ 物理/逻辑故障域隔离——AI 推理独占 GPU 节点池；④ cgroup 限额——防 CPU/内存饿死邻居；⑤ GPU 独占/MIG + 跨可用区部署——把爆炸半径压到单栈内。主线是「从自身不挂到邻居挂了我不死」。

故障域：节点、可用区、资源池都是故障域边界。混部下，两个栈共享故障域意味着一栈故障必然波及另一栈。

隔离手段：独立节点池（AI 推理独占 GPU 节点）、cgroup 限额（防 CPU/内存饿死邻居）、GPU 独占或 MIG 切分、跨可用区部署关键链路。

1. 关键业务 Java 与 AI 推理做物理/逻辑故障域隔离（不同节点池）。
2. 栈间设置熔断降级：一栈超时要能保护另一栈不被拖垮。
3. 定期做跨栈故障演练，验证故障传导边界与隔离有效性。
4. 单栈故障的爆炸半径预先评估并写入容灾预案。

陷阱：默认「各栈自己高可用就够了」，忽略同节点资源争抢——GC 风暴或推理 OOM 会瞬间击穿邻居。

单栈容灾追求「自身不挂」，混部容灾追求「邻居挂了我不死」。后者才是混部的核心能力。设计默认应是「邻居一定会挂」，据此做故障域隔离，而不是依赖两栈各自的高可用叠加。

1. 默认各栈自己 HA 就够了：忽略同节点资源争抢，GC 风暴/OOM 瞬间击穿邻居。
2. 不隔离故障域：一栈 OOM 把同节点 Java 业务拖垮，爆炸半径不可控。
3. 栈间无熔断降级：一栈超时不保护另一栈，连锁雪崩。
4. 不做跨栈故障演练：隔离有效性靠嘴说，真出事才发现边界破了。
5. 不评估爆炸半径写预案：单栈故障影响范围未知，预案形同虚设。

考察端到端视角：用户一次请求跨 Java 与 Python 两栈，端到端 SLO 如何定义？一栈达标、一栈超时，整体算达标吗？各栈自嗨的 SLO 对用户毫无意义。

混部 SLO 演进：① 各栈自嗨 SLO——单栈达标但用户仍慢；② 端到端 SLO——由关键路径（最慢栈）决定，取两栈最严格的用户感知指标；③ error budget 切分——端到端预算分摊给各栈；④ 跨栈 SLI——链路级指标且能归因到单栈预算；⑤ 端到端告警 + 单栈下钻。主线是「从内部契约到用户契约，且二者可互相追溯」。

端到端 SLO：由关键路径（通常是最慢栈）决定，取两栈中最严格的用户感知指标。各栈内部 SLO 须从端到端预算中切分 error budget。

跨栈 SLI：链路级指标（总耗时、端到端错误率、跨栈饱和度），且每个跨栈 SLI 必须能归因到单栈预算，否则无法定位劣化来源。

1. 先定义端到端 SLO（如「95% 请求端到端 P99 < 800ms」）。
2. 按关键路径把 budget 分摊给 Java 栈与 Python 栈。
3. SLI 打通：统一 traceId，端到端指标可下钻到单栈。
4. 告警按端到端触发，但定位时直接关联单栈 budget 消耗。

判据：SLO 的无效信号 = 各栈都「达标」但用户仍抱怨慢。根因是 SLO 没站在端到端视角定义。

SLO 的本质是「对用户承诺的可量化体验」。混部下，单栈 SLO 只是内部契约，端到端 SLO 才是用户契约。两者必须可互相追溯——端到端劣化能定位到是哪个栈吃了 budget，才算健康的跨栈 SLO 体系。

1. 各栈达标但用户仍慢：SLO 没站在端到端视角定义，是最无效信号。
2. 一栈达标一栈超时算整体达标：端到端体验由关键路径决定，不能取平均。
3. SLI 不能归因单栈：端到端劣化无法定位是哪个栈吃了 budget。
4. 告警按单栈不按端到端：用户已感知慢，各栈还显示绿。
5. budget 不切分给单栈：只有用户契约没有内部契约，无法驱动各栈优化。

考察变更管控的精细度：升级 Python 推理栈时，如何只灰度 AI 部分而不影响 Java 业务？反之亦然。整机灰度在混部下等于「拿另一个栈陪葬」。

混部灰度演进：① 整机灰度——升级一栈连邻居一起动，陪葬式发布；② 流量染色——header/标签把请求路由到指定版本，按服务粒度而非整机；③ 独立灰度批次——Java 与 Python 各有 Go/No-Go 判定；④ 跨栈端到端判定——灰度好坏看新旧版本端到端指标对比；⑤ 固定一栈灰度降维——把二维版本矩阵降为一维，每次只动一个变量。主线是「从整机陪葬到外科手术式染色」。

流量染色：通过 header/标签把请求路由到指定版本（网关或服务网格按染色标签转发），实现按服务粒度而非整机灰度。

独立灰度批次：Java 与 Python 各自有灰度批次与判定窗口，互不影响。灰度判定基于跨栈端到端指标对比（新旧版本），而非单栈内部指标。

1. 网关/网格按染色标签路由：新版本流量走新栈，其余走稳定栈。
2. Java 与 Python 独立灰度批次，各自有 Go/No-Go 判定。
3. 灰度期间重点监控跨栈端到端指标（而非只看本栈）。
4. 控制灰度维度，避免「Java v2 × Python v1/v2」组合爆炸。

陷阱：两栈一起灰度，任一栈出问题都无法判断元凶，回滚时只能全量退，代价巨大。

混部灰度的核心矛盾是「版本矩阵爆炸」：Java 与 Python 各有新旧版本，组合达 4 种。正确做法是固定一栈、灰度另一栈，把二维问题降为一维，每次只动一个变量。

1. 两栈一起灰度：组合爆炸，任一栈出问题都无法判断元凶，只能全量退。
2. 整机灰度陪葬健康栈：升级 Python 把 Java 也拖进变更窗口。
3. 只看本栈指标不看过端到端：本栈绿灯但端到端劣化，漏判。
4. 维度失控（v2×v1/v2 爆）：应固定一栈，灰度另一栈。
5. 无染色标签路由：只能整机切，无法做服务级灰度。

考察回滚的精准度：灰度中端到端指标劣化，该回滚哪个栈？全量回滚代价大且误伤健康栈，部分回滚才是混部的正确姿势。

混部回滚演进：① 全量回滚——退整个版本，误伤健康栈；② 单栈回滚——支持一键退单栈；③ 状态补偿——Agent 会话/中间状态外置或幂等重放，回滚不丢数据；④ 部分回滚——只回退劣化栈，保留健康栈；⑤ 根因闭环——回滚后做根因定位 + 改进项，而非退版本了事。主线是「从全身麻醉到外科手术」。

回滚触发线：端到端 SLO 突破 error budget（如 P99 连续 5 分钟超阈值、错误率越线）即触发。判定线须预设且透明。

部分回滚：只回退劣化栈，保留健康栈。前提是两个栈可独立回退且状态可补偿（幂等/会话重放/状态外置）。

1. 预设回滚判定线（P99/错误率/饱和度阈值）并写入发布预案。
2. 支持一键回退单栈，回退后验证跨栈链路恢复。
3. 状态补偿：Agent 会话/中间状态外置或幂等重放，避免回滚丢数据。
4. 回滚后做「根因定位 + 改进项」闭环，而非简单退版本了事。

判据：回滚的有效性 = 恢复服务的速度与精准度。能只回退元凶栈，才算混部回滚成熟。

回滚不是「退版本」而是「恢复服务」。单栈下这二者重合；混部下，退版本可能误伤健康栈。真正的成熟度是「精准定位元凶栈 + 局部回退 + 状态补偿」，让回滚成为外科手术而非全身麻醉。

1. 全量退回误伤健康栈：退版本可能把没问题的栈一并打挂。
2. 回滚线不预设：临时拍板，犹豫期故障窗口拉长。
3. 状态不补偿：回滚丢会话/中间数据，用户侧出现不一致。
4. 退版本了事不定位根因：同类问题下次再爆。
5. 不支持一键单栈回退：只能全量，代价巨大。

考察可观测的跨栈完整性：Java 用一套 trace、Python 用另一套，跨栈调用断链，根因定位只能靠猜。这是混部规模化的头号前提缺口。

混部可观测演进：① 各栈独立 trace——Java 一套、Python 一套，跨栈断链；② W3C tracecontext 统一——Python 入口注入/透传 traceId；③ 统一指标 backend（OTel）——命名/单位对齐接入同后端；④ 跨栈拓扑视图——一眼看全调用链；⑤ 异常聚合 + 统一日志关联键——同 traceId 异常自动聚合。主线是「让一次跨栈请求可被完整复盘」。

统一 traceId：跨栈传播用 W3C tracecontext 标准，Python 推理入口注入/透传 traceId，使一次用户请求在 Java 与 Python 间无缝串联。

统一指标与日志：指标命名/单位一致、接入同一 backend（Prometheus/OTel）；日志结构化且带关联键；跨栈拓扑图可一眼看全调用链。

1. 在 Python 推理/gRPC 入口注入并透传 traceId（OTel SDK）。
2. Java 与 Python 指标接入统一采集后端，命名规范对齐。
3. 跨栈告警关联：同一 traceId 的异常自动聚合成一条事件。
4. 建跨栈拓扑视图，定位「慢在哪一栈、卡在哪一跳」。

陷阱：两栈各自可观测但互不相通，故障时只能在两个系统间来回切换比对，MTTR 大幅拉长。

可观测打通不是「多接几个 dashboard」，是「让一次跨栈请求可被完整复盘」。没有它，H01.03 的容灾、H01.05 的灰度、H01.06 的回滚都是盲操作——你不知道该隔离谁、该灰度谁、该回滚谁。它是所有其他能力的地基。

1. 两栈各自可观测不互通：故障在两个系统间来回切比对，MTTR 大幅拉长。
2. 不传 traceId：跨栈调用断链，根因定位只能靠猜。
3. 指标命名/单位不一致：跨栈聚合与下钻失败。
4. 跨栈告警不聚合：同一 traceId 的异常散成多条事件。
5. 以为多接 dashboard 即可：需要的是「一次请求完整复盘」，而非更多面板。

考察基础设施层的隔离能力：K8s 默认调度不关心「Java 要 CPU 密集、Python 推理要 GPU + 内存带宽」，混部调度不当就是两栈互相拖累的物理根因。

混部调度隔离演进：① 默认调度混放——K8s 不区分 Java(CPU 密集)与推理(GPU+带宽密集)；② 拓扑打散 topologySpread——避免同节点堆叠；③ 节点池亲和隔离——AI 推理独占 GPU 节点池；④ GPU MIG/时间片共享——多推理安全共享一卡 + 显存限额；⑤ NUMA 亲和 + QoS 分级——内存带宽敏感负载绑 NUMA，Guaranteed/Burstable 保证关键负载。主线是「既提利用率又不互拖的物理底座」。

拓扑感知调度：topologySpreadConstraints 打散、节点亲和把 Java 与 AI 推理分到不同节点池。

GPU 共享：MIG 切分或时间片调度，让多推理负载安全共享一张卡；QoS 分级（Guaranteed/Burstable）保证关键负载。

NUMA 亲和：内存带宽敏感型负载绑定 NUMA 节点，减少跨节点访问延迟。

1. AI 推理独占 GPU 节点池，Java 业务放 CPU 优化节点，物理隔离。
2. 多推理共享 GPU 时用 MIG/时间片 + 显存限额防越界。
3. NUMA 绑定内存带宽敏感负载，cgroup 限额防饿死邻居。
4. 调度策略写入平台规范，新负载默认按类型入对应节点池。

判据：调度隔离的成熟度 = 「物理上像两个集群，逻辑上是一个服务」。故障域与资源都隔离，但对外是一套能力。

调度隔离是混部能「既提利用率又不互拖」的物理底座。资源利用率的提升（FinOps 的目标）恰恰来自「敢把两栈放一起」，而敢放一起的前提是调度层能把故障域与资源都隔干净。隔离与利用率是同一枚硬币的两面。

1. 默认调度不隔离：Java 与推理抢 CPU/带宽，物理根因不除。
2. 多推理共享 GPU 不限额：越界拖垮同卡其他负载。
3. 不绑 NUMA：跨节点内存访问延迟在高负载时拖累吞吐。
4. 新负载不按类型入池：平台规范缺失，隔离策略靠人记。
5. 以为利用率与隔离对立：实则一体两面——敢混部的前提正是调度能把故障域与资源隔干净。