2021亚马逊云科技中国峰会,构建新格局,重塑云时代。快来开启您的轻松云上之旅 了解详情
写点什么

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

2021 年 6 月 15 日

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

采访嘉宾 | 王晓征


十多年过去了,“去 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 年 6 月 15 日 09:371643

评论

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

我是如何从零开始学Python: (1)如何选择合适的Python学习工具?

广之巅

Python 4月日更

架构实战营 - 模块二作业

Sun

Spark运行状态监控与优化

小舰

4月日更

架构实战营 模块二:课后作业

👈

架构实战营

nginx反向代理和负载均衡策略实战案例

赖猫

nginx Nginx源码

让孩子爱上阅读(二)

箭上有毒

读书笔记 4月日更

阿里致敬武侠首发“Java架构修炼笔记”,深入内核,拒绝蒙圈

Java架构师迁哥

Nacos实践

程序员架构进阶

源码分析 nacos 微服务治理 28天写作 4月日更

业务架构训练营第 0 期模块二作业

目标一个亿

2020从干饭人到打工人

空城机

生活 生活记录 杂记 4月日更

Linux ifconfig 命令

一个大红包

4月日更

业务架构:作业二 朋友圈高性能架构设计

Nick~毓

阿里遭拒,90天深造357页微服务手册,获京东offer

Crud的程序员

Java 编程 程序员 架构 微服务

Docker容器的安装和使用

攻城狮Chova

Docker 容器 4月日更 镜像仓库

模块2作业

灯火阑珊

【LeetCode】存在重复元素 III Java题解

HQ数字卡

算法 LeetCode 4月日更

Seldon 使用 (三): 模型服务如何运行

托内多

tensorflow kubeflow Kubernetes PyTorch seldon

模块2-微信朋友圈高性能架构设计

yu

Github接近10w点赞!阿里巴巴内部Java面试参考指南

云流

Java 程序员 架构 面试

如何做向上管理?

石云升

28天写作 职场经验 4月日更 向上管理

采访彩食鲜 CTO 乔新亮:数字时代,企业如何完成数字化转型?(采访提纲)

xcbeyond

数字化转型 4月日更 人物访谈

微信朋友圈的复杂度分析

Fleng

架构实战营

微信朋友圈高性能复杂度分析

Flutter 学习笔记(二) Container 组件

U+2647

flutter 四月日更

架构实战营 模块二:学习总结

👈

架构实战营

陪伴的进化

小天同学

陪伴 爱情 个人感悟 4月日更 亲情

重读《重构2》- 引入参数对象

顿晓

重构 4月日更

wkhtmltopdf实践

风翱

4月日更 wkhtmltopdf

微信朋友圈高性能结构设计构想

我不是坏人

这套Java面试题推出第二天就惨遭全网封杀!已帮我拿下15个Offer

Java架构追梦

Java 阿里巴巴 架构 面试题总结 金三银四

阿里巴巴用实践告诉你,架构师到底需要掌握什么样的技术?

Java架构师迁哥

快手2020年春晚活动基础组件演进

快手2020年春晚活动基础组件演进

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