写点什么

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

  • 2021-06-15
  • 本文字数:5561 字

    阅读完需:约 18 分钟

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

采访嘉宾 | 王晓征


十多年过去了,“去 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 数据库客户顾问委员会数据库专家委员。


2021-06-15 09:372926

评论

发布
暂无评论
发现更多内容

得物(毒)APP,8位抽奖码需求,这不就是产品给我留的数学作业!

小傅哥

Java 小傅哥 编程开发 七日更 数学逻辑

小白干货奇遇记

熊斌

个人成长 七日更

Windows安装MySQL5.7教程

Simon

MySQL windows 安装 七日更

突破程序员基本功的16课

田维常

程序员

AWS云上安全最佳实践

雪雷

安全 AWS 云安全

Polkadot系列(三)——如何实现共享安全性

QTech

区块链 polkadot 跨链

OLAP计算引擎怎么选?

数据社

OLAP 七日更

【理论篇】浅析分布式中的 CAP、BASE、2PC、3PC、Paxos、Raft、ZAB

merlinfeng

大数据 分布式

发布会直播技术及业务实践

vivo互联网技术

分布式 服务器 直播技术

Gridea+GitHub搭建个人博客

Simon

GitHub Pages 博客 七日更

四币连发交易所系统开发技术

养猫了!

小林coding

生活

为什么现代系统需要一个新的编程模型?

华为云开发者联盟

编程 模型 语言

智慧社区综合信息服务平台搭建,智能社区建设解决方案

t13823115967

智慧社区系统开发

模糊匹配、相似度查询怎么破?看PG亿级检索毫秒响应

PostgreSQLChina

数据库 postgresql 开源

Fair World智能合约APP系统软件开发

系统开发

合成游戏app系统开发软件技术

数字货币交易所系统开发功能方案

堪称完美!阿里架构师用60个实战案例讲明白了Spring Boot

Java架构追梦

Java 架构 面试 微服务 springboot

差点跳起来了!全靠这份“Java核心知识笔记”我成功拿到美团offer

比伯

Java 程序员 架构 计算机 编写

我敢说这是全网最详细的基础讲解,附源码实例,没人学不明白

小Q

Java 学习 架构 面试 基础

执法办案信息化建设,情报研判管控分析平台搭建解决方案

t13823115967

智慧公安

做音视频最好用的几款跨平台框架

anyRTC开发者

flutter uni-app ios android WebRTC

【经验分享】遵循10步法,应用系统发布效率大不同!

嘉为蓝鲸

敏捷 运维自动化 部署 发布流程 应用发布

向我看齐!京东智联云成 2020 TOP100 Summit“技术标兵”

京东科技开发者

DevOps 云原生 数字化

盘点 2020 | 鲜衣怒马少年时,不负韶华行且知!

程序员的时光

程序员 成长 编程之路 计算机 盘点2020

Spring 源码学习 09:refresh 大概流程

程序员小航

spring 源码 源码阅读

dForce挖矿APP系统开发|dForce挖矿软件开发

系统开发

浙江移动十年“国产”路:自主可控和云原生,一个也不能少_语言 & 开发_褚杏娟_InfoQ精选文章