解读 MySQL DB Mesh的创造性实践

传统的 IT 流程、基础架构和运维模式已经无法满足金融行业的业务发展需求,传统银行早已意识到转型的迫切性,但如何落地,其实对银行的智慧挑战很大。同时,客户对于金融服务的期望和要求日益增加,对于银行在全渠道体验、定制化内容、智能数据、实时、便捷及移动等方面的服务,不断提出更高要求。

传统金融行业的痛点

如何快速响应用户需求

金融行业信息化建设的关键是及时响应业务需求,适应不同商业环境的 IT 架构,满足不同部门、客户和合作伙伴的各种需求。然而,传统的研发模型已经成为应用交付和迭代速度的瓶颈。

烟囱式架构如何向分布式架构无痛转型

在 IT 基础架构层面,很多金融企业都是「烟囱式」架构,「烟囱式」架构带来的大问题是数据孤岛, 不同的应用系统之间的数据无法实现共享。并且,在金融走向普惠、拥抱长尾市场的过程中,传统金融 IT 架构无法支撑巨量涌入的长尾客户。

高复杂环境下如何确保系统的高可用性

金融 IT 运维人员的压力之大众所周知,这源于金融行业对业务连续性和可用性的严苛要求。随着金融信息化的不断发展,金融 IT 环境正在变得越来越复杂:应用纷繁复杂、IT 架构异构、系统规模日益增大……这些都导致运维的难度越来越大,运维部门需要全新的思路来应对复杂环境下IT系统运维的压力。

以 Docker 为代表的容器技术正在以一种不可阻挡的趋势席卷全球,其大的过人之处在于它统一了云的交付件,从而给企业 IT 转型带来变革性的思路,赋予企业 IT 快速响应和持续创新的能力。

容器技术的不断发展和成熟为传统金融企业的容器化建设提供了新思路,但真正的落地过程依然十分坎坷。正如飞贷金融科技副总裁陈定玮在接受 InfoQ 记者采访时提到的,“其实,现在任何行业对容器的看法基本一致,都是非常认可的。从金融行业的角度,认可归认可,但大部分的实践还是基于边缘系统,而真正的核心系统想要落实容器化建设,中间要经历一段时间的阵痛。这就导致虽然大家都看好容器的发展趋势,但由于金融行业本身的特殊性,还是有很多企业不敢贸然行动。”

不敢贸然进行容器化建设的原因有几点:

一是人的因素。银行的科技人员是否足够了解并掌握容器技术,如果运维人员不具备这样的技术能力,是没办法在进行容器化建设的。

二是金融行业的特殊性。银行对于新技术的引入非常审慎,由于追求安全第一的行业特殊性,金融行业与互联网行业相比,即使对新技术的“热情”很高涨也无法很快推行到核心系统。现在一些比较大的银行,渴望尝试新的技术和应用,但目前仍处在经验积累阶段,还是只能在边缘系统尝试。只有当容器及相关技术在边缘系统运用得非常成熟和完善以后,才有可能慢慢地去取代核心系统,进而将新技术推广到核心部分。而且由于传统银行系统体量大,复杂度高,“包袱”重,探索出真正适合金融行业的技术方案和路线,需要经过一个很长的时间技术迭代。

陈定玮提到,“金融企业做容器化建设是一种必然趋势,但是整个进程的速度关键在于技术决策者,也就是CTO或者科技主管。他们对于新技术的运用以及怎么运用这件事情如果想得比较清楚,那么新技术的推动速度就会大大加快。”

飞贷的容器化之路

飞贷的容器化建设,起点很特别——公司内部所有的系统都是自研开发。容器化建设其实是对基础架构层的重新打造,自研系统的优势就在于对原系统和架构的改动不用经过第三方。陈定玮提到,“如果飞贷是采用第三方系统,那么每次新技术引进都需要跟合作方去谈,但问题是传统的软件系统对于基础架构这一层的事情并不太关注,这会在一定程度上阻碍基础架构层的技术改进。另外,飞贷的技术基因与其他公司有些不同,我们非常看重基础架构层的建设,因为这是整个飞贷金融科技赖以生存的一部分。从业务层面来看,飞贷本身有 C 端业务,并且是在解决 C 端用户遇到的问题和痛点的过程中,形成了最佳的解决方案,然后赋能给金融客户,这是飞贷与其他软件企业的不同,我们的商业模式里是有实体运作的经验,经过了生产历练且成效不错。”

容器化建设有两点显著的好处:一是弹性伸缩,二是容器化建设后,架构变小,这样系统恢复部署/运维速度会加快。

飞贷对于整个容器技术的理解和做法是:通过容器化去改变 RD 整个开发模式。有些企业在做容器化时,往往只是把虚拟化的技术替换成容器而已,但是实质上里面的东西没有变,这样容器技术根本起不到效用。比如,如果仅仅是将虚拟机换为容器,虽然系统容器启动时间会大幅缩短,由几分钟变为几十秒,但是系统的容器化构建编排需要几个小时,这样整个系统的交付体系效率并没有提升,甚至是变得更慢。整体效率考量才是企业做容器化想要达成的目的和结果。

飞贷的容器化建设不只是把 CloudStack 换成容器,而是把整个应用程序及研发流程,根据容器的规范和要求也做了大量的调整与重构,所以整个分布式系统的应用与部署才能变得更加高效。

陈定玮提到,“我们的容器化建设其实相当于重新开发了一套系统,之所以付出这么多努力去做这件事,除了看重容器化对于系统整体效率的提升以外,还在于通过容器技术可以解决很多实际问题,比如最重要的一点是节省了成本,这里面包括人力成本、效率以及硬件投入成本等,这往往是技术管理者最关注的地方。对于新技术是否采用的出发点,都是以成本去考量。飞贷整个容器化建设完成之后,物理资源成本相比私有云节省40%,人力成本可以再节约60%,研发投入可以再节省40%,还有容器本身快速应用部署带来的效率的提升,比如可以在短时间内快速搭建出上百套现有环境,更快地服务 B 端用户。容器化对于飞贷而言意义重大。”

飞贷容器化建设的痛点

飞贷的客户主要由 B 端和 C 端构成,而促使飞贷进行容器化建设的动力来自于 B 端客户的需求。

飞贷采用混合云结构,私有云用 CloudStack 搭建,现有虚拟机规模在3000~4000台,如果没有做容器云平台,那么帮助 B 端客户搭建一套框架体系大概要花费1~2 周的时间。当容器云平台搭建成以后,一天时间就可以部署上百套系统。同样的环境下,效益提升了10倍以上,物理资源也节省了40%——也就是说,用原来的做法需要100台服务器,但是用容器之后只需要60台。

陈定玮提到,“B 端客户要在飞贷的平台上运行业务,就相当于将飞贷整个技术平台租给企业客户,由飞贷负责运维。这里面有两种模式:一种是我们提供金融云的服务,根据客户需求去定制化流程和服务;另一种是将飞贷的系统部署在 B 端。但这会存在一个问题,由于是分布式部署上百或上千台服务器,我们帮客户部署完,除了网路调通以外,他们后续的运维会非常复杂,不仅浪费资源,而且效率很低,但痛点就在于 B 端客户对资源的管控非常严格,导致后续在运维上比较棘手。”

做容器化以后,可以实现统一管理、统一调度,并且容器本身具有非常高的弹性伸缩的能力,因而在资源投入上会减少很多,这就满足了 B 端客户管控资源的需求。而且在容器化以后,不仅部署速度极大提升,也可以在一个管控界面上去追踪所有的应用与服务,从而节省人力的投入,这是B 端客户的技术人员也比较认可的方式。

　　飞贷容器云平台建设思路

容器云平台架构

对于飞贷的容器云平台的建设思路,陈定玮坦言,其实任何新技术的引入都要从三点来考虑:

是否勇于尝试新技术;

新技术能否结合实际来运用;

评估技术成熟度和技术团队掌握能力,这里面包括两点,一是评估新技术是否足够成熟;二是判断技术团队是否有能力掌握。

早在2015年,陈定玮和他的技术团队开始研究容器技术,并做了相应的调研评估。2016年开始试点,把容器1.0版本上到研发和测试环境。2017年,开始调研和使用 K8S ,“其实在2016年的时候,我们也尝试了很多方案,但是当时容器技术在大规模应用编排管理上不够成熟,所以那个时候我们不太敢上生产,而且那时候容器运维、安全防护方面也不是很完善,这两个原因导致容器技术迟迟没有开始上生产”。

到了2017年, K8S 迅速成为容器集群管理的主流平台。陈定玮和团队于是开始去调研和使用K8S。“我们一定要对新技术有一定的掌握度,到了2018年,基于K8S和容器2.0版本,我们做了MySQL容器化测试。2018-2019年,我们一直在做的就是改造所有的系统,要打造容器化平台生态圈,以容器为主导,慢慢替换 CloudStack 的环境。”

飞贷金融科技容器化历程

　　不要为了容器化而做容器化

　　很多公司声称要做容器化,其实只是“换汤不换药”,不是说把平台换成容器就能解决所有问题。陈定玮说,“我们不是为了容器化而容器化,整个飞贷的代码质量和产品都要符合容器的要求和规范。因此我们做了大量重写,才能达到容器标准,不然秒级容灾、秒级恢复怎么实现呢?如果DB 启动时间要5分钟,不管用容器还是传统的虚拟机部署,整套系统的启动时间还是5分钟,这个安全级别达不到金融行业的标准。容器大的好处是能够实现秒级启动和秒级恢复,但是容器只是对应用做封装,而不是提供一个环境(这跟虚拟机不同),所以应用也要随之修改,才能达到容器的标准,实现快速启动。其实我们背后做了非常多的改造。”

　　金融企业非常重视代码质量,飞贷因此开发了一个代码质量的管理体系,建立代码质量审查体系,只要 RD 代码的撰写与风格不符合规范,代码是没有办法提交的,这也是DevOps流程的一部分。同时飞贷也研发了基于容器的代码流程自动化系统,也就是RD从开发代码到打包、发布、到生产和测试环境,全流程由系统自动化生成。同时将自研中间件与微服务整合在一起,实现类似于“ Service Mesh ”的“ DB Mesh ”。据了解,业界在 DB 容器化实践上还没有比较成功的核心生产系统案例,飞贷是目前为止第一个拥有成熟解决方案的公司。

　　容器化建设的坑与经验

　　在谈及飞贷做容器化建设过程中踩过的坑时,陈定玮还是感慨万千,“容器技术在早期没有完善的运维部署和管理体系,导致从金融领域的行业标准的角度来看,我们是不达标的。虽然我们一直在前进,但底层技术不支持,无论我们在上层应用做什么都无济于事。这是我觉得飞贷在容器化这条路上遇到的一个坑点。其实根源还是金融行业的特殊性,对于数据安全、信息安全的要求非常高,所以每一步都必须达到高标准。在2018年以前,我们都只是在RD环境和测试环境使用。因此我需要花费大量的精力平衡人力成本,去处理效率低下和代码质量等等问题。后来随着技术和时机的成熟,我们的容器化才真正开始上生产,实现了系统部署和快速交付,我可以腾出时间去抓代码质量、代码规范、减少Bug率,整个容器化建设和容器化生态也有条不紊地快速落地。”

MySQL容器化DB Mesh的创造性实践

从应用层来看,容器化发展得很好,但是数据库仍然存在很多问题。如果数据库中断,重新恢复数据库和业务生产需要花很长时间。如果数据库非常大,那么启动时间会非常久。这就是为什么银行或大型金融机构不敢用开源数据库MySQL或MongoDB等的原因,因为他们要保证安全和持续运作。

飞贷要做数据库容器化的原因,一是为了要实现标准化快速部署。如果应用快速部署完,而数据库部署慢,那么系统的整体效率还是慢。二是飞贷现有系统已经全部实现微服务化,在这种场景下数据库实例如果不能做微服务,它就会成为业务弹性伸缩以及管理的短板。三是为了更长远的目标,就是真正实现网格化(DB Mesh)。

MySQL 容器化 DB Mesh 架构如下图所示。可以看到,多个不同的应用服务对应多个不同的中间件,每个中间件对应一个单独的数据库节点,形成一种类似于 Service Mesh 的 DB Mesh 架构,可以灵活调度迁移数据库节点。为了数据库容器化稳定,对业务数据实现分库分表存储,并限制单个分库节点的容量。在数据库遭遇故障时,可以多节点并行迅速恢复。可以说,飞贷在整体业务运作上拥有强大的数据分库分表、读写分离的技术能力,这些能力是由飞贷自研中间件完成的,中间件是实现 MySQL DB Mesh 的关键所在。