当前的时代背景下，发展数字经济重要性已无需赘言，而做强和做优更是摆在了很重要的位置。政务领域作为服务社会建设、保障社会高效运转的基础领域，数字基础设施关键技术的自主掌控和优化创新尤为重要。
（节选自《求是》2022/02《不断做强做优做大我国数字经济》）
政务信息化现状与高性能数据库核心技术创新
政务云建设现状与技术挑战
随着各省、市级政府相继设立了大数据局/数据管理局职能部门，持续地进行信息化建设投入。现阶段各省市基本已经因地制宜建设了各类信息一体化平台，各地政务云基础设施也已初成规模。
在过去的政务云 1.0 时代，主要是整合行业领先的云厂商、大运营商人才、技术、基础设施资源搭建了基础政务云框架。各委办厅局利用新的一体化资源/服务平台搭建系统，以及将原先的信息化系统逐步迁移至政务云上。在如火如荼的政务云建设中也显露出技术因素的掣肘，其中最为常见的几类问题基本上都集中在最为重要的数据层：
- 一是政务云上高性能关系型数据库服务缺失限制了政务云下数据迁云的全面性和高效性；
- 二是政务云上数据库服务扩展性限制政务信息系统/一体化平台架构设计；
- 三是政务云上各社会面数据资源共享效率受到了基础架构的限制，存在许多数据孤岛。
数据层技术挑战分析和架构创新实现
上文问题一的表象是云上缺乏像 Oracle 一样的高性能关系型数据库产品，并且不能提供高度的 Oracle 开发生态兼容性；从而导致不少委办厅局的现有核心系统无法低成本平迁云上，往往要么先将应用迁移至云上，数据库仍使用云外物理服务器；要么需求整体重构应用，采用拆分策略将核心系统拆小分而治之（但是往往很多核心系统在应用层面的拆分十分困难而且可能引入诸如跨库共享、关联、一致性等复杂性得不偿失）。
问题二和问题三则是同一个问题的两面表现：一方面省/市级各类一体化平台设计时受制于云上关系型数据库的性能和扩展性限制，架构设计在数据库层面必须去切分很多数据库实例，而不能完全按照业务数据共享的需求去实现“一个库”，这反过来造成在数据共享层面的数据冗余副本过多、同步实时性差，或者数据共享依赖上层服务调用效率较低的问题。
笔者认为深挖问题表象的技术因素在于现在主流的“关系型云原生数据库”的实现往往依赖云平台层面本身的虚拟化技术，没有实现数据库层的资源云化。除开对云厂商的云底座绑定这一固有限制之外，云平台虚拟化技术当前在计算资源损耗控制上（CPU、内存）已经比较出色，但是在关系型数据大规模多机分布式计算以及高性能数据库最关注的 IO 指标上却存在技术难题：
- 单一虚拟化计算规格难以跨越底层物理服务器；
- 本地磁盘时延低性能高（NVME）但扩展性受限；
- “云盘”扩展性好、总体吞吐高但时延和稳定性往往不如人意。
再往下深挖则是主流的“关系型云数据库服务”内核基本上基于集中式时代的产品（MySQL、PostgreSQL 或其他“自研”产品），没有原生云化的设计（如原生多租户能力、分布式计算存储资源利用能力）；又由于当前国内主流云/数据库厂商对于数据库内核技术的掌握程度不足以支持其深度重构内核（例如引入分布式存储/计算引擎或 RDMA 等方案），只能在外围或者上层中间件修改，所以无论是对于云下主流商业化产品的兼容性支持，还是核心查询计算性能都不能完全满足要求。
具备分布式数据库内核完全自主设计能力的专业数据库厂商 ，其原生云化设计的通用型分布式关系型数据库则可以解决这个问题：
- 可以不依赖平台级虚拟化直接利用硬件计算和 IO 能力避免损耗；
- 支持分布式计算引擎，可实现计算资源的跨机利用而无需依赖“分布式中间件”；
- 支持分布式文件存储引擎，而不需要依赖“云盘”，从而获得存储层低延时；
- 可以在 SQL 引擎层面原生实现 Oracle 或其他主流产品生态兼容性支持。
政务云高性能数据库做强做优的探索与实践
高性能分布式关系型数据库 OceanBase 的引入
OceanBase 是蚂蚁集团科技投入内部全面去 Oracle 和 MYSQL 孵化的核心产品，是完全自研的原生分布式关系数据库，具有云原生、易扩展、强一致性、高度兼容 Oracle/MySQL 等特性，历经 10 年业务打磨。在 2019、2020、2021 连续登顶刷新国际 TPC 组织关系型数据库交易、分析型场景性能榜单后开始广泛进入大众视野。单独成立子公司并开放生态后，其多云输出形态和原生云化分布式数据库技术特点与政务云当前阶段广泛存在的数据库诉求非常匹配。
浙江省政务云为提升数字化建设水平，更好地服务各委办厅局，在充分调研当前高性能数据库需求基础上，引入了 OceanBase 分布式数据库服务。
浙江省政务云OceanBase资源截图
浙江政务云政法云高级人民法院整体迁云实践探索
在浙江省高级人民法院整体迁云实践探索中，主要完成的尝试是：已上云系统透明扩展；核心业务系统平滑去 O 迁云和全面国产化；在数据资源管理上实现“一个库”横向扩容，高效数据共享。
浙江省高级人民法院官网截图
云下整体迁移云上的架构实现和工程实施步骤如下图所示，根据业务现状特点、业务耦合性和迁云紧迫性制定迁云路线。
- 优先满足第一类已上云业务数据库资源可无限扩容需求（档案、卷宗），无需分库，解决集中式数据库实例容量上限问题。
- 对数据生产源头且推送数据中心的第二类核心业务（审判、执行、送达、案款），逐个向云上 OB 迁移，同时建立相应的数据同步链路。
- 对于依赖数据中心推送数据的第三类业务系统（如各类移动端应用），逐个迁移业务库，同时建立对应的原数据中心到云上 OB 的同步链路。
- 通过对一二三类业务的解耦分步迁移以及对应的数据中台大数据分析业务逐步迁移，原线下数据中心逐步变瘦直至完全迁云。
在数据资源“一个库”设计以及数据共享实时性和效率提升上，通过分布式水平扩展实现数据可根据业务需求聚合，数据资源可直接共享。如下图所示不同业务可依据实际业务需求使用租户/用户，租户之间通过数据同步组件进行共享。同租户用户之间通过用户权限实现共享，实现数据共享高度实时，并通过分区级读写分离技术实现数据共享和主业务生产之间的竞争避免。
OceanBase多租户间、租户内多用户数据共享和读写分离示意
OceanBase业务透明在线扩缩容，数据、负载自动重平衡示意
业务收益上，在无需重构应用架构的前提下，成功使用云上高性能数据库支撑了全省法院审判、执行、案款、送达等业务数据汇聚。支持了档案、卷宗数据的长期完整保存，支持各类数据碰撞聚合分析。
信息化收益上，实现了云上、线下数据库集中汇聚云上纯国产化数据库OceanBase；应用统一了开发技术栈，40+ 服务器资源缩减一半，资源可管理性提升；数据库服务故障恢复时间从小时级降低到分钟级。
