云原生数据库国标实施，医疗信创库搬上 K8s 我复盘了3个取舍

一句话简介：云原生数据库国标把"弹性伸缩"写成了技术要求，可医疗核心库的第一诉求是"稳"；国标落地真正的难点，是 License、Operator 和混合架构这三笔账。

作为医疗云原生架构师，最近在给一家三甲医院的影像云做信创改造，数据库这一层要从 Oracle 换到国产库、还要跑进 K8s。正赶上 GB/T 47343-2026《信息技术 云原生关系数据库管理系统技术要求》在 2026 年 10 月 1 日正式实施——这份由全国信息技术标准化技术委员会归口、华为云、腾讯云、阿里云、达梦、人大金仓、南大通用、平凯星辰、奥星贝斯等三十余家单位共同起草的国标，明确了云原生关系数据库的技术参考架构，并把基础功能、弹性伸缩、资源管理、高可用、安全性、智能化运维都写成了技术要求。国标来得正是时候，但真到落地这一步我发现，最难的三个问题都不在标准正文里。这篇复盘一下。

一、国标把"弹性伸缩"写成了技术要求，可医疗核心库的第一诉求是"稳"

国标的技术要求里，"弹性伸缩"是明确条目。这符合云原生的原始定义，但放到医院，直接照抄会出事。

1、先分清"能弹"和"该弹"。医疗核心库（HIS 交易库、影像索引库）的第一诉求是稳，不是弹。门诊高峰的写入压力确实会涨，但涨的幅度是有限的、可预测的，而一次计划外的自动扩缩容带来的风险（连接中断、执行计划翻转、缓存失效）往往大于它带来的收益。我们的做法是：把弹性需求在架构上分层承接——服务层做弹性（读写分离、只读副本、连接池、无状态应用水平扩缩），数据库层本身保持收敛的有状态部署。

2、把国标条目当"体检表"，而不是"采购目录"。国标里每一条技术要求，落地时都要多问一句"这条在医疗生产环境怎么验证"。比如"高可用"，标准关心的是机制，医院关心的是"主备切换时门诊挂号会不会断"；比如"智能化运维"，标准关心的是能力，信息科关心的是"告警能不能告诉我该找谁"。我们把这套条目拆成一张逐条问答表，逐条填"验证方式 + 验收人 + 证据形式"，填不出来的条目就是方案里最虚的地方。

3、有状态负载的部署形态要早定。数据库上 K8s，本质是把一个有状态的东西放进一个为无状态设计的调度系统。StatefulSet、稳定的网络标识、持久化存储的绑定方式、优雅停机的时长，这些必须在方案评审阶段定死，而不是等到割接前夜才调。我们踩过的一个坑是：Pod 的 terminationGracePeriodSeconds 用了默认值，数据库还在刷盘就被 kill，重启后走了一遍实例恢复——业务上表现为一次"莫名其妙的卡顿"，排查花了半天。

二、License 模型和弹性伸缩天然冲突：这是国产库上 K8s 最容易被忽略的一笔账

这一点国标不会写，招标文件也常常不写，但它是真金白银。

1、国产库的计费模型差异很大，而且直接和"弹性"打架。达梦是按 CPU 核数授权：16 核的服务器就要买 16 核的 License，而且虚拟机 vCPU 超配（比如物理 16 核分配 32 vCPU）仍然按物理核数计费；OceanBase 按租户内存容量计费，memory_limit 这个参数直接关联费用；TiDB 开源版免费，但企业版按节点数收费，而且 TiDB Server、PD Server、TiKV Server 是分别计费的。这意味着：在 K8s 里 HPA 把 Pod 从 2 个扩到 6 个，对达梦的 License 没影响，但节点扩容就要重新谈；对 OceanBase 来说，内存往上弹就是费用实时往上走；对 TiDB 企业版来说，多一个实例就多一份钱。

2、所以弹性策略必须先算 License，再定阈值。顺序反了，就会出现"系统自动扩容得很优雅，月底账单很惊悚"。我们的做法是把 License 上限换算成 K8s 的硬约束：内存类弹性必须卡 memory_limit 的上限、达梦用 SP_SET_PARALLEL_DEGREE 限制单 SQL 并行度避免单条语句吃掉过多 CPU、TiDB 用 tidb_server_memory_limit 防 OOM（顺便也防了超支）、OceanBase 侧调整 memstore_limit_percentage 降低 MemStore 内存占比来减少 License 消耗。这些参数平时看着像性能调优，实际上同时也是成本阀门。

3、采购阶段就要把"弹性上限"写进合同。核数、内存、节点数的封顶值，以及超限的计价规则，必须在签合同前谈清楚。我们见过的情况是：合同只写了"按核授权"，没写"虚拟化环境下如何核算"，等到扩容时双方对"按物理核还是按 vCPU 计"各执一词。这种事在项目验收期发生，非常被动。

三、Operator 成熟度决定你能做到哪一步，"支持 K8s"不能当结论

选型时最容易听到的一句话是"我们支持 K8s"。但"支持"这两个字的含金量差别巨大，因为它背后是 Operator 的能力边界。

1、三类能力差异，必须逐条问清。TiDB Operator 支持 TidbCluster 这类 CRD，可以用 spec.pd.replicas 定义 PD 节点数、用 spec.tidb.config 动态注入配置；OceanBase 的云原生版本提供 ob-operator，用 ObCluster 资源定义、通过 spec.storageClassName 绑定持久化存储；而达梦的 DmOperator 目前只支持 StatefulSet 部署，不支持自动扩缩容。这三句话里，最后一句是关键——如果你的弹性方案依赖数据库侧自动扩缩容，那这个组合从一开始就不成立。

2、把三个问题写进验收清单，逐条在预生产环境实测。第一，能不能自动扩缩容；第二，能不能滚动升级而不中断业务；第三，出问题能不能一键回退到上一个版本。这三条必须现场实测，不接受 PPT 演示和"理论上支持"。测试方法也很具体：在预生产环境制造一次真实的版本升级，记录业务中断时长、回退耗时、以及回退后数据一致性怎么验证。

3、别指望 Operator 帮你做跨站点容灾。Operator 解决的是单集群内的生命周期管理，跨院区主备、同城双活这些是架构层面的设计，需要独立的复制链路、独立的切换决策机制和独立的演练。把"高可用"完全托付给一个 Operator，是我们在评审里见过最贵的一种天真。

四、信创混合架构 + 等保留痕：数据库层还有两个不能外包的附加项

最后两个问题，都不属于"数据库"本身，但都必须由数据库层来兜。

1、混合架构下，镜像和性能台账都要分架构。信创现场的真实形态是混合的：鲲鹏、飞腾（arm64）和海光、兆芯（x86_64）在同一套 K8s 里跑，操作系统可能同时有银河麒麟 V10、openEuler、麒麟信安、龙蜥几种，容器运行时和 K8s 版本也常有差异。数据库镜像必须按架构分别构建（多架构 manifest 或分别打 tag），并用节点亲和把实例钉在目标架构上；同时性能台账要分架构记——同一个库在鲲鹏和海光上的执行计划可能不一样，验收只跑一个架构的跑分，是自欺欺人。

2、等保要求的日志与告警，要落在数据库层的审计策略里。等保对日志保留期有明确要求（一般不少于 180 天），对 DROP TABLE、GRANT 这类敏感操作要求实时告警。这两条很多人默认交给日志平台处理，结果是数据库层根本没开审计、采集不到，日志平台再强也是空转。正确做法是把它当成数据库交付的一部分：库侧开审计、用采集器（如 filebeat）把日志送出去并触发 Webhook 告警，同时配合权限最小化和账号分离一起设计。医疗场景还有个特有要求：谁在什么时间动了哪张和患者相关的表，要能回答得出来——留痕是审计的输入，不是运维的副产品。

亮点与结论（可直接落地的五条）

1、国标是体检表，不是采购目录：逐条拆成"验证方式 + 验收人 + 证据形式"，填不出来的条目就是方案里最虚的地方。

2、先算 License，再定弹性阈值：把核数、内存、节点数的 License 上限换算成 K8s 的硬约束；弹性上限和超限计价规则必须在签合同前谈清楚。

3、"支持 K8s"不能当结论：能不能自动扩缩容、能不能滚动升级不中断、能不能一键回退，这三条必须现场实测；跨站点容灾不要指望 Operator。

4、混合架构下镜像分架构构建、性能台账分架构记录：验收只跑一个架构，等于没验收。

5、留痕与审计从数据库层设计：审计开关、日志留存期、敏感操作告警是数据库交付的一部分，不是日志平台的事后补救。

一句话总结：云原生数据库国标解决的"标准问题"，而医院真正要解决的是"取舍问题"——弹性与稳定、License 与扩容、能力与边界，这三组取舍想清楚了，国标才落得下去。