数据库混部：核心系统替换的“中间态”

信创迁移进入核心系统后，数据库的部署方式开始分化。过去“一库一用”是默认做法：每个业务一套数据库、一组服务器、一个独立资源池，简单、隔离好，但资源利用率低。到了国产化替换阶段，硬件成本、机房空间、许可费用和多芯兼容问题同时出现，“混部”重新被拿出来讨论。

2026 年初，北京金融科技产业联盟发布《数据库混部技术研究与应用》课题成果，由中国银联牵头，平安科技、网联清算、北京国家金融科技认证中心、蚂蚁科技、中兴通讯、飞腾、达梦等参与。报告把混部分成三条路径：资源混部、分时混部、多芯混部，并给出了容器化数据库云、CPU 超分配、主备异构芯片兼容、双模态弹性扩缩容等工程做法。

混部不是“临时凑合”，也不是“把所有库塞进一个集群”。它更像核心系统替换过程中的一个“中间态”：在旧栈和新栈并存、x86 和 ARM 并存、在线和离线并存的阶段，用共享资源池降低迁移成本和硬件投入，同时保住关键业务的确定性。

一、为什么会出现混部

混部的出现，有四个现实原因：

一库一用浪费严重。 很多数据库的 CPU、内存、存储长期低负载，但为了隔离和峰值预留，资源不能共享。
HTAP 和混合负载带来资源争抢。 交易型和分析型负载跑在同一套库上，白天交易、晚上跑批，峰谷明显。
在线与离线的峰谷不匹配。 在线业务白天高、夜间低；离线跑批夜间高、白天低。分时共享可以提升利用率。
多芯异构成为常态。 海光、鲲鹏、飞腾、龙芯等芯片并存，应用和数据库需要在不同芯片之间迁移、主备、灰度。

这四个原因决定了混部不是“要不要做”，而是“哪些系统可以混、混到什么程度、怎么保证隔离”。

二、三条混部路径

表 1　数据库混部的三条技术路径

路径	解决什么问题	典型做法	适用场景	主要风险
资源混部	单库资源利用率低，硬件成本高	容器化数据库云、CPU 超分配、资源池化管理、QoS 分级	外围系统、开发测试、多个中小库	噪声邻居、资源争抢、故障扩散
分时混部	在线/离线峰谷不匹配	按时间窗口调度在线与跑批负载，动态调整资源	日间交易、夜间跑批的分析型/报表型库	窗口冲突、跑批延迟、调度复杂度
多芯混部	x86/ARM 等异构芯片并存，迁移成本高	主备异构芯片兼容、集群级/服务级混部、灰度切换	信创过渡期、双轨运行、多芯资源池	芯片差异、驱动/固件兼容、切换失败

报告里的几个工程细节值得注意：

容器化数据库云 + CPU 超分配。 通过容器隔离和资源池化，提高单节点利用率；但超分配必须有 QoS 和限流，否则一个高负载库会拖垮同节点的其他库。
主备异构芯片兼容。 主库和备库可以跑在不同芯片上，切换时应用无感；这是多芯过渡的关键能力，但需要验证驱动、固件、网络和存储路径。
双模态弹性扩缩容。 阈值触发 + 短时预测，既能在负载突增时快速扩容，也能在负载下降时回收资源；预测算法要避免滞后和误判。
隔离技术。 容器 QoS、CPU 绑核、NUMA 亲和、SR-IOV 网络隔离、CEPH/RBD IOPS 限流、TBF/IFB 带宽控制，都是防止“噪声邻居”的基础。

三、混部的技术底线

混部能不能上核心，取决于四条底线。

第一，隔离。 CPU、内存、IO、网络都要有隔离和限流。没有隔离的混部，只是把故障域扩大了。核心库和外围库混部时，至少要保证 CPU 绑核、内存预留、IOPS 上限和网络带宽上限。

第二，故障域。 混部不是把所有库放在一个故障域里。主备异构芯片、跨节点/跨机房部署、集群级隔离，都是为了在单点故障时把影响限制在最小范围。核心系统要做切换演练，不能只看“能启动”。

第三，弹性。 混部的收益来自“按需分配”，但弹性策略要能识别业务峰谷。阈值触发适合突发流量，短时预测适合周期性峰谷；两者结合，比单一策略更稳。

第四，许可与成本。 混部可能改变数据库、操作系统、虚拟化、监控工具的许可模型。按核、按节点、按实例、按容量，计价方式不同，五年 TCO 差别很大。混部前要把许可账算清楚，不要只看硬件节省。

四、混部的成本账

表 2　混部的收益与隐性成本

项目	收益	隐性成本
硬件	提高 CPU/内存利用率，减少服务器和机房空间	超分配带来争抢，可能需要更高规格网络和存储
许可	共享资源池可能降低按节点/按实例许可	部分厂商按核/按容量计费，混部不一定省钱
迁移	多芯混部降低信创迁移的一次性切换风险	驱动、固件、芯片差异增加适配和测试成本
运维	统一资源池、统一监控，减少孤岛	故障定位更复杂，需要更强的可观测性和值班能力
弹性	峰谷调度提升资源效率	调度策略误判会影响在线业务，需要持续调优

公开案例里，混部的收益通常体现在利用率和迁移成本上。比如有保险公司公开披露，采用“一云多芯”完成核心系统迁移，迁移周期较行业平均缩短约 30%，业务代码改造量降低约 70%，性能提升约 50%；也有银行公开案例提到，通过异构服务器和数据库评估模型，节约 CPU 资源约 13%，数据库瘦身超过 1PB。这些数字来自厂商或案例披露，测试基线不同，不能直接复制，但说明混部的价值不只是“省硬件”。

五、哪些系统适合混部

表 3　混部的适用性判断

系统类型	建议	原因
外围系统、办公、门户	适合资源混部	负载相对可控，SLA 要求低于核心
开发测试、准生产	适合资源/分时混部	峰谷明显，资源可以复用
报表、跑批、分析型	适合分时混部	夜间跑批与白天交易错峰
核心交易、账务	谨慎，优先独立资源池/强隔离	对时延、故障域、审计要求高
监管报送、清算	谨慎，按监管要求隔离	窗口固定，失败代价高
多芯过渡期系统	适合多芯混部	降低一次性切换风险，保留回退

这张表不是绝对规则，而是一个决策起点。核心系统不是不能混部，而是要用更强的隔离、更清晰的故障域和更严格的演练来换。如果混部带来的利用率提升，抵不过故障定位和切换风险的上升，就不值得。

六、混部决策清单

在决定是否混部之前，建议回答七个问题：

业务 SLA 是多少？核心交易能接受多大的时延抖动和故障影响？
隔离要求是什么？CPU、内存、IO、网络是否需要独占或绑核？
芯片组合是什么？主备是否异构？切换演练做过没有？
许可怎么算？按核、按节点、按实例，混部后是省还是贵？
故障域怎么划？一个节点/机房故障，会影响多少业务？
运维能力够不够？监控、日志、链路、容量、值班能不能支撑混部？
退出路径是什么？混部失败后，能不能回退到独立资源池？

混部是手段，不是目标。 它的价值是让信创迁移更平滑、资源利用更充分，而不是为了“先进”把核心系统放进一个更复杂的资源池。对核心账务来说，确定性永远比利用率重要。