浙江移动十年“国产”路：自主可控和云原生，一个也不能少

采访嘉宾 | 王晓征

十多年过去了，“去 IOE”浪潮已经逐渐退去，但企业自主可控的脚步却并未停下，其中不乏在“去 IOE”上取得不错成效的企业，浙江移动便是其中之一。

2011 年前，浙江移动还是典型的 IOE 架构，当时研发团队停留在彻底研究清楚 IOE 体系的阶段。但在十年后，云原生技术不断升级的同时，浙江移动在“去 IOE”上也取得不小进展：核心应用全部去 I、核心存储全部去 E，完成了 AntDB、Oceanbase 等 6 类自主可控数据库的引入，开源或国产数据库按套数统计占比达到了 53%。

凭借这份成绩单，浙江移动成为电信行业单位竞相学习和借鉴的对象。那么在整个期间，浙江移动都做了些什么？又总结了哪些经验和感想？InfoQ 对中国移动通信集团首席专家王晓征进行了专访，希望可以对大家有所启发和帮助。

“云原生 + 自主可控”的双线程改造

浙江移动这十年的技术演进，可以总结为“云原生 + 自主可控”的同期双线程改造，这是浙江移动无意中走出来的特色路线，但对于企业整体技术发展却起了很重要的作用。

2011 年到 2014 年，是浙江移动云化架构初步转型的时期。这三年间，移动互联网彻底爆发。随着流量的迅速增长，很多企业的业务支持系统开始面临大规模、高并发能力的考验，浙江移动也是其中之一。单体式架构能不能支撑业务量、能否带来较好的客户体验、能否确保系统的稳定性、安全性等，成为大家讨论的焦点问题。

也是在这个时期，国内“去 IOE”意识彻底觉醒。如果说 2009 年阿里提出“去 IOE”概念时还在被质疑，那么 13 年“棱镜门”事件便让大家真正意识到了“去 IOE”的重要性。当时很多企业已经开始做去 I 去 E 方面的工作，只是并不彻底。

2011 年，浙江移动开始了自己的自主可控探索历程。这年年底，浙江移动基本去掉了 CRM 系统的小型机，换上了 X86、虚拟机，同时开始升级应用开发框架。

这些改变让浙江移动尝到了技术带来的甜头。“过去，我们常常因一台小型机宕机就要深更半夜跑去抢修、维护，但在最后一台小机退服后，运维同事再也没有因为这个加过班。”事情很小，却让王晓征印象深刻。

之后，浙江移动把目光转向了数据库。当时的数据库只能放在 I 和 E 上，浙江移动的计划是至少从一个技术方向上做突破。13 年底，浙江移动启动了数据库层面的国产化一体机方案，用了近 4 年的时间实现全部服务器 X86 化。

这个时期，浙江移动逐渐降低了对传统 IE 设备的依赖，同时开始探索核心数据库如何摆脱对底层 IE 依赖。这个阶段在浙江移动内部被称为“云原生 1.0”阶段。

2015 年到 2018 年，浙江移动迎来微服务架构的重要转型时期，即被称为“云原生 2.0”的进阶阶段。

这个时期，4G 业务快速发展，IT 系统除了要扛住流量增长，还要能够快速响应各种业务的要求。高容量和对响应速度的要求开始让传统的架构和研发方式难以招架，研发部门常常要花很多的时间和精力去满足各种业务需要。

为走出当时的困境，享受过技术红利的浙江移动再次将目光放到了技术升级上。在 16 到 17 年的中心化项目中，浙江移动以微服务化领域自治为原则，将业务支撑系统拆解成系列高内聚低耦合的业务中心，各业务中心应用和数据库基本独立。这也为之后数据库去 O 打下了基础。

与此同时，浙江移动在自主可控方面也有了很大进展。2017 年，全部核心库实现 X86 化去 I 去 E，基本实现 CRM 系统全面微服务化及容器化、中间件全面自主可控；18 年，实现全部 CRM&BOSS 系统微服务化及容器化，浙江移动也成为电信行业第一个实现全部核心系统存储自主可控、去 E 替换的单位。

值得注意的是，去 E 并非有意为之。起初，浙江移动并没有非要核心存储去 E，只是在实践中发现，架构的升级必然会伴随着一些技术的淘汰。

“当时浙江移动的核心系统已经实现去 I，容器平台变得非常关键。有一次容器平台发生抖动，经排查后发现是因底层存储性能不稳定引起的。虽然有多种解决方案，但我们意识到这个零件其实是多余的。那我们为什么要修好一个多余的零件？”王晓征讲道。当时浙江移动的应用架构已经完全是分布式的，不再需要集中式存储，最后该存储被下掉了。

2019 年至今，到了浙江移动“云原生 3.0”的发展后期。这期间，浙江移动的主要目标就是云原生技术升级和自主可控转型。

在这一阶段，王晓征最大的直观感受就是升级中不再做大的系统割接。之前，浙江移动要用小步快跑的方式改进，将一次大割接分成几十次小割接，而现在浙江移动已经具备了全业务灰度发布的能力。

浙江移动割接期间全省业务量环比变化

浙江移动通过充分利用冗余资源和容器弹性伸缩的敏捷能力，实现了双平面架构。升级发布时，浙江移动将两个平面的应用引到一个平面，然后在另一个没有使用的平面做引流发布，这样实现了部署与发布的分离。基于灰度架构能力，目前浙江移动上线次数增加了 100%，75% 需求在白天上线，上线故障减少 80%，大型项目割接业务影响降低 99%。

X86 系统架构在供应链安全上并非完美。近两年，浙江移动在核心系统上用华为鲲鹏芯片和 X86 做了一个异构的双平面承载，在 19 年 10 月，全部 CRM&BOSS 核心系统承载到自主可控鲲鹏 &X86 异构双平面上。

2019 年 11 月，浙江移动实现全部小机下线，彻底去 I。2020 年进一步扩大 ARM 资源池规模及应用迁移范围，并在 11 月完成最核心的交易型数据库软硬件自主可控。

在王晓征看来，云原生架构升级和自主可控改造是互相促进的关系。云原生不断演进不仅降低了自主可控改造难度，同时倒逼团队提升研发和运维能力，在自主可控改造上发挥更大的作用。

去 O 不只是产品与产品间的替代

具体到数据库去 O 问题，这并不简单。数据库去 O 时，主要会面临以下风险：

• 数据安全。去 O 本质上是在用一个不成熟的产品替代一个成熟产品。需要承认的是，国产数据库在成熟度、适配性等方面或多或少存在些问题，与 Oracle 有一定的差距。替换过程中，数据的完好转移、存储会是一个考验，数据丢失有时比业务中断更可怕。

• 稳定性。数据库替换后，关键是要做业务迁移。国产数据库与 Oracle 数据库很多方面并不兼容，需要进行很多改造工作，尤其核心系统的迁移对安全性和稳定性的要求更高，整个评估、改造和测试的工作量非常大。所以，替换成国产数据库后不可避免地会产生新的投资和维护成本。从这个层面来讲，业务从 Oracle 数据库迁移到国产数据库的成本并不低。

• 割接问题。数据库割接对数据的持久化、准确性和校验等是很大的考验，如果用时间换空间策略进行规避，又可能出现停机等问题，这就很容易被客户感知到，甚至引起投诉。

但实际上，数据安全问题并没有成为浙江移动改造过程中的很大阻碍。在“云原生 1.0”阶段，浙江移动的数据库已经按地市进行了从省到市等更细化地拆分，在微服务改造时又做了垂直拆分，整个过程下来，核心数据库的体量已经大幅度变小。通过控制数据库体量和有效改造数据库链和存储过程方式，最大程度地保护了数据安全。

“技术发展就是一个不断积累的过程。很多时候都是第二阶段进行了积累，第三阶段就很快用上了，并成为了非常重要的助力。国产化改造也是如此。”王晓征说道。

针对最重要的稳定性问题，浙江移动采取了整体架构去 O 而非直接换库的方式。浙江移动在数据库和应用之间增加了数据库中间件 DADB，将部分功能和风险放到中间件上，实现应用与数据库解耦的同时，弥补自主可控数据库性能、稳定性等方面的不足。这种方式虽然对团队在管控和运维方面提出了更高的要求，但却是将问题转化到了浙江移动更擅长的领域内，从而实现了不可控到可控。

浙江移动架构去 O 思路

在割接问题上，运维团队发挥了很大的作用。上线前，运维团队针对新的国产数据库进行了大量的功能和压力测试，有问题便能及早发现，大大降低了割接风险。

在王晓征看来，去 O 不是简单的产品与产品间的替代，而是架构与架构间的替代。在做技术选型时，企业不能一味地技术崇拜，而是要找到最适合自己业务的技术。

当前，主流的架构可以分为单层库、分布式数据库和云原生数据库。单体库最传统、体验也最差，存算分离的云原生数据库比较好，而分布式数据库架构最激进、似乎也最理想。只从技术角度考虑都有一定的道理，但在实际应用中却并非如此。

每种数据库有不同的使用场景和产品，不同产品的成熟度也不一样。单层数据库虽然并行性、可扩展性较差，但架构简单，使用门槛会比较低、安全问题也会小一些。另外，如果单层库可以与一个发展较快的硬件结合，那它自身的天花板也会提高，逐渐可以满足更多的场景。分布式数据库在自动化程度、容量等方面有很大的优势，但是也存在一些问题，比如不能突破的 CAP 原理。企业可以想办法做平衡，但肯定会牺牲一些性能，并使开发迁移成本提高。

除了技术问题上的考量，产品生态和对外商务合作也是选择国产数据库时需要注意的问题。

目前数据库生态基本上有两类：一类是基于开源演进的数据库，另一类是完全自研的数据库。前者生态比较活跃，但也存在数据库掌控难等问题，而后者自主可控程度更高，但可能会面临生态问题，两者各有利弊。而商务合作其实是关系到了企业供应链的安全。如果选择了一个性能、技术控制上都不错的数据库，但在生态合作上有距离的话，就存在不可持续的供应链风险。

虽然在提倡去 O，但这并不意味着对立。王晓征强调，对于企业而言，保护供应链生态、发展自主可控技术路线是必要的，但与国外供应商保持良好的生态合作也很重要，两者并不是非此即彼的关系。在未来很长一段时期内，国产数据库会和国外商业数据库将会并存，浙江移动对于国外商业数据库支出也不会下降。

容易被忽视的运维转型

必须承认的是，国产数据库与 Oracle 还存在着一定的差距。国产数据库一些性能不如 Oracle，两者机制也不同，在数据库去 O 过程中，国产数据库需要充分的时间与业务磨合。在这个过程中，运维会发挥巨大的作用。

通常情况下，团队交付产品有三种降低风险的方式：本身稳定性好、中间切换成功率高和有强大的运维保障。如果这三道防线中没有任何一道防线靠谱，那么设备的风险就很大。运维工作作为重要一环，主要任务便是故障域隔离、降低故障概率和降低故障时长，团队快速、及时感知问题、找到并解决问题的能力就很重要。

之前单体式架构稳定、故障率较低，排障也比较容易，但随着架构升级，排障难度也会随着升级。同时在自主改造初期，国产设备故障率也会相对较高，排障过程比较复杂。这时，完全靠人力是不行的。

在浙江移动提出的“数据汇通、能力融通、组织拉通和机器沟通”的“四通”概念中，机器沟通是很重要的一部分。机器沟通不存在信息接受损失，可以降低沟通成本，并将人从繁琐重复的劳动中解放出来。“一个库在快‘倒下’时，数字化运维会把它‘扶起来’。我们天天都在扶，靠我们的 AIOps 去‘扶’。”王晓征说道。

国产库的一些原生版本在子事务锁上数量有限制，如果沿用之前的开发习惯，新国产库上的子事务锁会很快耗尽，一旦耗尽则意味着这个数据库不能用了。这个问题通过版本升级更新可以解决，但需要比较长的时间。这个期间，数字化运维体系可以将问题提前侦测到，并做自动化处理，同时不被外界感知。

经过多年的容器化微服务改造，浙江移动已经非常擅长处理复杂的运维问题。通过建立数字化运维团队的建立，浙江移动增强了将“急性病变成慢性病”的能力，而这些能力在做自主可控时又得到了充分发挥。

与常规运维团队不同的是，浙江移动的新型数字化运维团队不仅是运维团队，也是架构改造和优化团队。比如，要实现故障自愈需要逃生通道，但有的系统没有逃生通道，那么在做架构优化时，新型运维团队就可以自己加上逃生通道，且不需要太多研发支持。

浙江移动团队经历了从毫无经验，到编制常见故障标准手册，再到将这些标准变成自动化的脚本的过程，通过不断地积累，现在的系统已经很少出现问题。

“成功是一个很漫长的过程，运维保障体系的建立是一个作用很大但不容易被人看到的优势。”在王晓征看来，国产数据库需要一个长时间的技术沉淀和生态运营才能弥补与 Oracle 的差距，单凭砸钱是出不来一个好产品的。

对于国产数据库的崛起，王晓征预测市场会先大浪淘沙筛出一些头部企业，这些企业在集中研发力量和生态资源发展后逐步成为巨头。到了这个阶段，国产数据库才能开始实现从量到质的转变。王晓征乐观估计，整个过程可能需要 10～20 年的时间。

先行者困惑

对于当前讨论的数字化转型，本质上是生产力由资源驱动向创新驱动的转变，而创新驱动背后主要依靠技术和数据来支撑。企业大力发展技术是一个必然趋势。

持续扩大自主可控覆盖率还是要坚持做下去，但这对浙江移动来说已经得心应手了，并不是很大的挑战。真正的挑战在于，完成从“追赶者”到“领头羊”角色转变后，浙江移动未来的路该怎样走。

对标互联网企业，浙江移动在过去十年里以一种“全速奔跑”的状态努力追赶，这期间哪怕是一个小的改进都会带来很大的效益。现在，浙江移动在业界已经走在前列，但这也意味着越往后发展，技术所带来的边际效应会越小。

所谓“先行者困惑”是现在摆在浙江移动面前的一个重大挑战，这也是所有高速发展起来的企业都会面临的问题，而这个问题需要时间和不断地摸索才能得出最佳答案。

王晓征表示，未来浙江移动计划将从深度和广度两方面拓展自己的技术能力。除了继续深耕云原生，浙江移动也将深入研究大数据、云计算、区块链、边缘计算和人工智能等各种影响架构演进的技术。

各种新技术的深度融合将成为未来发展的重要引擎。企业个体引入新技术容易，但要普遍应用就需要整个行业达成共识。这个过程如何进行，对浙江移动来说也是一个任重道远的课题。

采访嘉宾介绍：

王晓征，中国移动通信集团首席专家（IT 领域）、中国移动科协信息技术学部专家，现任中国移动浙江公司信息技术部党总支书记、总经理，兼任云智能中心主任，兼任中国移动（浙江）创新研究院常务副院长，Oracle 9i OCM（2003 年中国第一批 Oracle 认证资深专家），华为 Gauss 数据库、甲骨文 Oracle 数据库客户顾问委员会数据库专家委员。