端游云原生化改造：500 万/年成本是怎么省下来的

背景

英雄联盟端游的服务端原来跑在 IDC 物理机上，机器利用率只有 20-30%。游戏的负载有极强的日周期和活动尖峰，为了扛住峰值，不得不备一大批机器——固定容量，等于永远按峰值付费。

迁到 K8s 的动机就两个：成本（利用率太低，养的机器太多）和交付（发布、回滚流程需要标准化）。同时要说明：这是在线的核心业务，「不停服迁移」是硬约束，整个方案都是围绕这个约束设计的。

最关键的设计：runtime 双态兼容

迁移必须灰度——在线游戏不可能一夜之间把所有服务从物理机切到 K8s。问题是：如果服务在两种环境下的运行方式不一样（启动方式、依赖注入、配置加载），那每个服务都要改代码，切换也没法回退。

我的做法是把物理机和 K8s 的运行时差异抽象掉：游戏服务只要切换一个 runtime 关键字，就能在两种环境之间无缝切换，业务代码零改动。这个设计的价值不是技术上多炫，而是让高风险迁移变得可灰度、可一键回退——先切一小部分到 K8s，观察，有问题就把关键字切回去。核心业务的迁移风险被降到了最低。

配套做了 Grafana 统一观测：迁移过程中物理机环境和新 K8s 环境必须同时可观测，面板统一。否则出了问题连是哪边的问题都说不清，就成了「盲迁」。

钱是从哪省的

先说结论：500 万/年来自利用率，不是来自砍预算。

逻辑链：

迁移前：物理机固定资源，利用率 20-30%，为扛峰值只能多备机器
              ↓  迁到 K8s：统一调度 + 混部
迁移后：利用率 50-60%
              ↓
同样的业务量 → 不再需要原来那么多机器
              ↓
省下的机器数 × 单机年成本 = 500 万/年

关键在一句话点破：不是「砍了 500 万预算」，而是「利用率上去了，同样的活不用养原来那么多机器了」。 统一调度让资源可以流向真正需要的地方，混部把低谷时段的空闲资源用起来承载更多负载——利用率就是这么翻倍的。这个数字按实际淘汰的机器数量和成本口径计算，是项目整体的财务口径；项目由我牵头，runtime 双态和监控体系是我负责的部分，团队一起落地。

方案复用：无畏契约

这套方案跑通之后，新游无畏契约的上线直接复用了同一套双态兼容 + 统一观测的方案——第二个项目不用再踩一遍同样的坑。

事后看，值得记下来的

迁移最大的风险不是技术，是「退不回去」。 runtime 双态花了最多心思，就是为了让迁移从「一次性赌博」变成「可进可退」的过程。任何迁移项目，如果回答不了「出问题后怎么在分钟级退回去」，就不应该开工。

降本应该从利用率入手，而不是从砍配额入手。 一刀切砍资源配额在报表上立刻见效，但本质是把成本问题转嫁成稳定性问题——最后一次事故就赔回去了。让同样的资源承载更多负载，才是正的。

观测要先行。 统一监控不是迁移完再补的锦上添花，而是敢不敢开始灰度的前提。没有它，整个迁移就是盲迁。