首次独家呈现 OPPO 四大创新技术实践,尽在 QCon 上海 OPPO 技术专场! 了解详情
写点什么

为了让你搞定数据库选型,这些工程师重写了 26 万行代码

2021 年 10 月 07 日

为了让你搞定数据库选型,这些工程师重写了 26 万行代码

无论多么有主见的架构师,在做数据库选型的时候,也可能会犯难。


传统 SQL、NoSQL 还是 NewSQL?架构风格是以 久经考验的关系型数据库为主,还是偏向所谓原生的分布式架构?如果提及具体产品,那选择就更多了,TiDB、OceanBase、PolarDB、TDSQL、GaussDB、MongoDB…… 现在还有许多服务于新场景的产品,比如处理时序数据的 TDengine,处理图数据的 Nebula Graph……以及最老派又最完善的 Oracle。


如果从业务场景或即将面临的迁移成本来看,问题会更加复杂。牵扯到底层数据的选型和架构设计,有时更像一锤子买卖,一旦定了某种方案,再想替换代价可不是一般的大。


差不多在 10 年前,这事儿还没有那么棘手。Oracle、IBM Db2,二选一而已。但今时不同往日,这是一个数据量急速膨胀、业务高度复杂的时代,真正让人焦虑的不是单纯的选型问题,而是将“降本提效”推向极致的数字化转型问题。


那么,除了咬牙硬选一个数据库,或者基于现有数据库的基础上自研一套存储方案,真的没有其他路可走了吗?其实也有,只不过在分布式数据库热度越来越高的当下,显得有些“透明”,那就是中间件 + 多商业数据库的解决方案。


看到这个答案,你可能会有些失望。中间件方案出现的时间,尚在分布式数据库成熟之前。因此在业内很多架构师看来,这种方案在技术上不够超前,只能算是某种“过渡策略”,本质上是 NewSQL 数据库成熟前的无奈之举。


但来自金融等行业的诸多落地实践证明,事实可能并非如此。


我们为此特别采访了 全球顶级开源项目、数据库中间件产品 Apache ShardingSphere 的作者,以及背后商业公司 SphereEx 的 CEO 张亮,他一直对分布式架构设计保持关注,曾是京东科技架构专家、当当架构部总监。关于整个数据库行业的选型和架构设计问题,张亮有着特别的思考。

可插拔架构,或许是答案


“需求是多元化的,一部分用户适合分布式数据库,一部分用户适合用数据库中间件,甚至还有一部分适合两种都用,没有太绝对的答案”,张亮说。


这是个无错的答案,但也可以得出一个推论:如果场景是多元化的,数据库是多元化的,那么架构师应该尽量规避扩展性、兼容性不好的数据库解决方案。


无独有偶,Oracle ACE、数据库专家韩锋也在其个人公众号里发表过类似的观点:“(关于数据库选型)为了规避路线选择、厂商绑定的风险,比较现实的方法是选择一款兼容通用性协议的产品,并且在应用中仅使用标准数据库的用法。”


二者结合起来,我们能抽离出一些关键词:中立、兼容、标准,对于很多在选型问题上难以抉择的架构师来说,这让中间件路线看起来更加实际。


与数据库行业不同,以 ShardingSphere 为代表的中间件层由于不涉及存储引擎,如今已将目光从单纯的水平扩展问题转向业务支持和灵活性问题,也因此得以实现对异构数据库的统一管理。


灵活性、兼容性,是数据库中间件产品的核心,也是解决“数据库选型”问题的关键。据张亮透露,近两年的主要研发重点一直是可插拔架构,以将灵活性和兼容性推向极致。好消息是,ShardingSphere 的可插拔架构预计将在未来一段时间内正式上线。


所谓的可插拔架构,是指在架构层面,将整个系统分为基座和插件两部分,插件部分互相隔离、互不影响,基座可以自由接入多个插件。可插拔架构多见于相对轻量级的前端领域,属于微前端体系的一部分,但在基础软件部分则相当少见。


张亮认为,可插拔架构形式是未来数据库中间件的主要趋势之一,一则产品需要高度的灵活性,二则还有大量的能力需要被构建,比如数据安全、异构数据网关等功能,可插拔架构自然成为了产品核心。


话虽如此,但可插拔架构的设计难度却很大,让人望而生畏。这种设计难度,大致分可为两部分来谈:

第一,可插拔架构是对 OCP(Open-Closed Principle)原则的一次彻底执行,力图仅通过增加新模块来满足新需求,旧有模块完全保持 0 修改。这意味着,可插拔架构要清晰地定义出,什么是基座,什么是插件。它对上层、下层都无感知,一切面向接口。用张亮的话说,就是:“完全面向一个抽象的、虚无的东西,不涉及任何的业务细节”。


比如,ShardingSphere 转向可插拔架构后,其核心流程里已经没有分片功能了,分片会作为可插拔能力的一部分接入到服务中。对于数据库中间件来说,几乎属于产品重定义。与许多人对数据库中间件的固有认知相悖,因为在许多人的理解中,数据库中间件不就是为了分库分表而存在的吗?


但实际情况是,单体数据库的覆盖场景依然很多,分库分表并不是 0 级功能。这是在架构层面,必须具备的关键洞察。


第二,与微服务相似,只要涉及服务拆分,就会涉及颗粒度问题。对于可插拔架构来说,需要插件化的不一定只是产品功能,比如两阶段强一致事务和柔性事务,也是能够实现可插拔的。


基于这些拆分问题,ShardingSphere 把可插拔架构分为三层,分别是内核层、功能层、生态层,分别面向数据库内核、企业功能、数据库生态进行可插拔设计。其中,查询优化器、分布式事务引擎、调度引擎等是内核层的可插拔模块;数据分片、读写分离、数据库高可用、数据加密、影子库都是功能层的可插拔模块;数据库协议、SQL 方言等则是生态层的可插拔模块。


要实现可插拔架构,除了设计难度和颗粒度拆分,其工作量也令人叹为观止。ShardingSphere 有 190 多个模块,近 43 万行代码,核心 Java 代码 29 万行,张亮回忆道:“为了做可插拔架构,老代码留了不到 1/10。”这意味着,有近 26 万行的核心代码被重写了。


可插拔架构是 ShardingSphere 追求灵活性最重要的标志之一,但它对灵活性的追求又不仅限于可插拔架构。


比如,ShardingSphere 还额外提供了两种部署形态,分别为 JDBC 和 Proxy。JDBC 是 Java 访问数据库的标准接口,Proxy 是中间件最常见的服务形式,且两者经常能够在同一环境下进行混用,以满足多用户下多类型访问的需求。


这样多种类型的服务接口,一方面服务了不同类型的开发人员,另一方面也实现了性能层面的可定制化,工程师可以结合场景调整数据库分片的键值,实现不同场景下,性能的最大化提升;反之,“全包式”数据库方案,则往往需要放弃部分灵活性,以相对中庸的方案来换取无感知、低侵入的使用体验,体现了与数据库中间件方案的差异性。

真正的开源项目,是社区说了算


如果我们要做技术选型,需要注意的另外一点是,备选产品的维护主体是谁,备选产品的基因是什么,是开源,还是闭源?这与搞清楚产品的技术方案、技术理念同样重要。


当下,无论开源的热度如何,大部分分布式中间件、分布式存储、数据库都是闭源的,这是不争的事实。


看到的是,大量的开源创业公司正在出现,资本也在快速进入,比如 SphereEx、欧若数网、Neo4j,以及大家熟知的 PingCAP。同时也有许多数据库宣布开放源代码,比如 OceanBase、Tendis、openGauss。


为什么在数据存储领域,开源这么引人关注?


一个可能的答案是,开源在技术层面的想象空间更大,对开发者更友好。就像 ShardingSphere 的可插拔架构,架构设计完成只是第一步,后续还有海量的不同模块的开发工作。对于创业公司来说,如果不借助社区的力量,美好的可插拔架构也可能成为公司的研发黑洞。


产品的中立性,也是导致开源项目集中迎来爆发的另一个要素。尤其是在数据存储领域,最美好的答案可能是无依赖、跨多云,最差的答案才是被单一产品强绑定。


当然,开源再好,也抵不过现实的骨感。开源两年,Star 几百,花钱不少,效果为零,这恐怕是众多开源项目的常态。社区的健康程度,往往直接定义了开源项目的生死,这导致即便架构师想做选型,也没有太多的好选择。


在张亮看来,一个开源项目能不能成功,大致可以分为三个维度来考察


第一,能否耐的住寂寞,团队是真的相信开源,还是拿开源当做商业上的捷径。一个最简单的考核指标便是运营时间,“开源项目一定要度过‘静默期’才会迎来爆发,只做了半年、一年,是没法预估项目未来的”,张亮说。


第二,一些必备的运营技巧。张亮一方面把 ShardingSphere 捐献给 Apache 基金会,另一方面也带着项目参与了许多活动,比如谷歌举办的黑客马拉松、编程夏令营,除国内用户以外,也吸引了大批的海外开发者、学生参与到社区建设中来。


第三,观念的转变,也是最关键的部分。从小处着眼,是从“自己开发”到“社区开发”;从大处着眼,就是在真正意义上拥抱开源,而不只是嘴上说说。


“ShardingSphere 的项目发展是受社区的引导。比如说,社区认为 ShardingSphere 该做基于影子库的压测和可观察性,ShardingSphere 就真的做了。这些都不是项目自上而下的设计,只要需求爆发,且在项目的 Scope 内,就可以实现。但如果一个公司在运营开源项目时,遇见所谓的偏离主线设计的社区诉求,就拒掉它,那么大概率也会影响这个项目的成长,因为它不算真正扎根社区的开源项目。”

未来的发展方向


目前相关的中间件产品,还是把核心聚焦在水平分片、弹性迁移和 MySQL 实例管理上。


但某种程度上,ShardingSphere 可能代表了未来数据库中间件发展的核心方向之一,即 0 级功能是可插拔,1 级功能才是数据分片。开源和可插拔架构结合在一起,等于打开了数据库中间件在技术和产品维度的想象空间。张亮透露,SQL 审计、基于数据的权限引擎、多租户、TTL(Time To Live)都会被提上开发日程。


除此之外,ShardingSphere 还有一个正在开发中的构想,叫做 Database Mesh,力争实现数据库上云的原生体验,但还需要一定的开发周期。


Database Mesh 会在数据库集群之上,封装一层代理,做智能的负载均衡。传统的负载层无法识别 SQL 特征,只能用轮询或权重的方式透传。但 Database Mesh 会根据不同的 SQL,匹配计算实例的标签,更加智能选择要访问的数据库计算或存储节点。


对于架构师而言,最重要的是打开技术选型的眼界与想象力。分布式数据库对业务的侵入性更低,但中间件方案规避了对厂商的依赖问题,究竟如何选择,要以实际场景为判断依据。但这并不妨碍我们给出阶段性的推论:


很可能,在未来的 5 - 10 年间,数据库中间件都是底层架构最重要的解决方案之一,值得每一个架构师认真调研。

2021 年 10 月 07 日 16:435806

评论 1 条评论

发布
用户头像
神马文章,SQL都写成SOL
2021 年 10 月 11 日 14:41
回复
没有更多了
发现更多内容

Windows Core Audio 音频开发技术指南

拍乐云Pano

云图说|数据仓库服务 GaussDB(DWS) 的“千里眼、顺风耳”—数据库智能运维

华为云开发者社区

数据库 数据仓库 GaussDB(DWS) 云图说 数据仓库服务

Flink State 和 Fault Tolerance(二)

Alex🐒

flink 翻译 flink1.13

恭喜埃文科技战队荣获“强网先锋奖”!

郑州埃文科技

阿里技术官新推2800页Java面试大礼包,金九银十稳了

Crud的程序员

Java 编程 程序员 架构 面试

架构训练营模块 6 作业 - 江哲

江哲

华云大咖说 | 华云数据与福昕鲲鹏携手共建国产云生态

华云数据

好的目标管理:SMART原则

石云升

创业 职场经验 管理经验 6月日更

618技术特辑(三)直播带货王,“OMG买它”的背后,为什么是一连串技术挑战?

华为云开发者社区

CDN 直播 618 低时延 视频直播

测试开发之网络篇-常用服务协议

禅道项目管理

IP HTTP 协议

【架构师训练营】电商业务微服务拆分设计

eoeoeo

标准物模型:设备无缝对接,IOT界的福音

华为云开发者社区

物联网 IoT 物模型 标准物模型 IoT Stage

推理综艺的正确打开方式!爱奇艺玩转智能技术,“互动+内容”引爆迷综季

爱奇艺技术产品团队

Java性能问题定位命令

hasWhere

Java版本发布历史

hasWhere

GraphQL 初探

wangwei1237

RESTful API graphql

2021中国边缘计算企业20强榜单出炉,EMQ强势入围!

EMQ映云科技

开源 边缘计算 计算 emq

吃透这份Java面试调优高级手册等350道面试宝典,已涨30k

程序员改bug

Java spring 程序员 架构

cpu突然变高定位步骤

hasWhere

性能排查常用Linux命令

hasWhere

618技术特辑(四)疯狂剁手的同时,电商隐私安全你注意到了吗?

华为云开发者社区

电商 数据安全 云安全 618 隐私安全

超全Redis命令总结,墙裂建议收藏,说不定就用上了呢

北游学Java

Java redis

物联网发展,行业新领域

anyRTC开发者

音视频 WebRTC 智能硬件 智能安防 实时通讯

bzz节点挖矿分发系统开发案例

薇電13242772558

区块链

OpenKruise :SidecarSet 助力 Mesh 容器热升级

阿里巴巴云原生

容器 云原生

JAVA语言基础(五)--数组

加百利

Java 后端 6月日更

一文读懂云原生 go-zero 微服务框架

晨雨听风

Go GitHub Web

Cilium 首次集成国内云服务,阿里云 ENI 被纳入新版本特性

阿里巴巴云原生

容器 云原生

美团二面问源码社死当场!闭门偷学318页Spring深度源码笔记,再战

Crud的程序员

spring 程序员 架构 编程语言

Python——嵌套

在即

6月日更

Flink+Hologres助力伊的家电商平台建设新一代实时数仓

Apache Flink

flink

为了让你搞定数据库选型,这些工程师重写了 26 万行代码-InfoQ