易华录 X ShardingSphere|葫芦 App 后台数据处理的逻辑捷径

猿人谷

共 2804字,需浏览 6分钟

 ·

2021-09-03 15:51


“ShardingSphere 大大简化了分库分表的开发和维护工作,对于业务的快速上线起到了非常大的支撑作用,保守估计 ShardingSphere 至少为我们节省了 4 个月的研发成本。”

——史墨轩,易华录·技术总监

今年以来,伴随着易华录旗下面向个人用户的云服务产品【葫芦 App】正式上线,后台架构所承受的业务压力也与日俱增。

为此,葫芦 App 研发团队选择采用 ShardingSphere 分库分表的功能对数据进行了横向的拆分,围绕 ShardingSphere 灵活敏捷的特性,满足了葫芦 App 业务对数据层扩展性的要求,避免团队重复“造轮子”,最大程度简化了随着业务增长而带来的愈发复杂化的分库分表的开发与维护工作。

1

从能力扩展到业务上新,葫芦 App 所面临的增长压力

对于数据存算能力的高要求,深深铸在了葫芦 App 技术团队的基因中。

由于葫芦 App 正处于快速成长期,业务和功能的调整需求相对频繁,这就需要后台技术团队能够根据前端业务变化而快速做出适配调整。用户数量和业务所产生的数据体量都在飞速增长的同时,也为后台底层数据库带来了更大的压力。

随着 2020 年 5 月 17 日葫芦 App 的正式上线,用户数据和业务体量也呈现出快速增长的态势,后台数据库不可避免地需要进行多次水平拆分。同时随着业务需求的快速变化,新的挑战也不断随之出现:

  • 能力扩展问题

随着用户量的快速增长以及产品形态的演变,用户数据出现了爆发式增长,过去传统架构的存算能力遭到了极为严峻的挑战,因此葫芦App 对于后端数据处理平台的要求是在具备扩展能力的同时,也要保证一定的灵活性。

  • 效率提升问题

为应对快速多变的业务,葫芦 App 的研发团队需要能够根据业务诉求来进行快速调整,以提升后台架构对业务的适应性,高灵活、易拓展特性的数据架构将能够极大提升团队研发效能。另一方面在大体量数据的影响下,数据库的检索效率难免出现延迟、读写慢等问题,进而会影响到最上层的用户体验。

  • 业务上线问题

功能上新频繁、上线时间提前等是任何一款新产品在上市初期都会遇到的问题,这对研发团队的研发能力提出了极大挑战。此前葫芦团队本计划通过内部研发力量并结合业务情况打造出自己的 Sharding 方案,不过由于时间关系,从方案设计、研发再到方案落地的自研路线已无法走通,因此敲定 Sharding 方案迫在眉睫。

  • 系统稳定问题

在引入新技术的同时,系统稳定性也会面临较大的挑战,尤其是面向底层技术的引用,大多具备一定的平台业务侵入性,在引入后大概率会对业务系统的稳定性产生一定影响。葫芦 App 研发团队需要一款对底层数据库侵入性低、适应期短、稳定性高的数据应用产品。

2

利用 ShardingSphere 的特性构建灵活高可用的数据架构解决方案

围绕上述的一些诉求,葫芦团队用了 2 周左右时间对 ShardingSphere 及同类解决方案进行了全面评估,综合考虑了如产品功能、成熟度、稳定性、性能等多方面评估指标,最终 ShardingSphere 凭借完善的功能支持程度以及高成熟度,充分满足了葫芦团队的业务诉求。

从上图中可以看出,葫芦团队将 ShardingSphere 部署在了阿里云的 RDS 之上,相较于对本体数据库做调整,葫芦团队更倾向于在数据库之上来进行数据治理。而 ShardingSphere 能够从可插拔架构所带来高扩展性、距离业务更紧密的贴合性以及对于业务架构的零侵入性这三个层面对葫芦的后台数据架构进行有效改进,并带来了明显的效果提升:

可插拔架构的『高扩展性』

由于业务特性,葫芦 App 原本有限的存储空间被消耗得非常快,并逐渐开始影响用户在前端的响应效率。通过采用 ShardingSphere 的分片策略,葫芦研发团队在应对海量计算+存储所带来的业务问题同时,能够确保分片扩展策略的灵活性。基于此,葫芦团队可以在ShardingSphere 上快速做出相应的功能扩展,为后续架构调整提供优化方案,进一步强化突出了 ShardingSphere 分库分表的优势。

距离业务更紧密的『贴合性』

后台架构的变化越小,对于业务而言就越可控。ShardingSphere 这种位于数据库之上的生态,距离业务更近,部署起来也更加轻量,无疑是解决葫芦 App 前台业务变更与后台架构调整之间矛盾的最优解。此外在灵活性层面,ShardingSphere 通过相关配置即可实现的方式,极大简化了葫芦研发团队在分库分表层面的研发与维护工作,对于业务的快速上线起到了非常大的支撑作用。

对于业务架构的『零侵入性』

葫芦 App 选择了 ShardingSphere-Proxy 部署模式,在不更换底层数据库的前提下通过 Proxy 来管理真实的数据库集群,基本无需对业务进行改造就已经完成了业务与数据在架构层面的分离,并避免了因更换数据库导致的业务不可用、漫长稳定周期等风险。另外,ShardingSphere 的无状态模式,几乎不会对前端用户产生任何可感知的影响,业务层也无需关注数据的存储方式。

因此对于葫芦 App 这种上线时间紧张、功能迭代快的产品来说,ShardingSphere-Proxy 通过复用原有数据库的能力,帮助葫芦研发团队在数据库之上实现分片、数据加密等增量能力的开发,且向下不需考虑底层数据库的配置,向上能够屏蔽用户感知,从而快速构建起面向业务的数据库直连能力,从系统架构层面进行了比较好的分离,确保后续数据库代理层的问题修复、版本更新等日常维护工作都不会影响到业务。

3

写在最后

此次与易华录葫芦 App 研发团队的合作,助力葫芦研发团队平稳度过了数次业务体量翻倍的历程,正是 ShardingSphere 在全球多种应用场景下的一个缩影。在商业化公司 SphereEx 的推动下,ShardingSphere 正在持续向着云化、商业化稳步迈进。在社区和商业化公司的双重加持下,未来 ShardingSphere 将继续深耕数据应用场景,持续挖掘 ShardingSphere 在各领域场景下的深层次价值,为用户提供覆盖更全面、性能更强大的数据服务。

目前,ShardingSphere 作为 Apache 基金会下的顶级开源项目,在 GitHub 上获得了超 14K Star 的关注,已成为行业内最受欢迎的开源项目之一,全球有超过 170 家企业用户登记使用,覆盖金融、电子商务、云服务、旅游、物流、教育、文娱等多个领域。


浏览 51
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报
评论
图片
表情
推荐
点赞
评论
收藏
分享

手机扫一扫分享

分享
举报