谁说数据库不适合Docker？解读MySQL DB Mesh的创造性实践

痛定思痛。 2021-12-11 11:15 194阅读 0赞

> 以 Docker 为代表的容器技术正在以一种不可阻挡的趋势席卷全球，但真正的落地过程依然十分坎坷。6 月 20 日北京，在 2019 企业容器创新大会上，业内首家覆盖业务全流程、运营全体系的移动信贷整体技术服务商飞贷金融科技的副总裁陈定玮分享了飞贷的数据库生产容器化及 Istio 应用的经验。基于飞贷金融科技容器化道路的实践与经验，InfoQ 记者也专访了陈定玮，并将其分享和思考整理如下。

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

# 1、传统金融行业的痛点 #

**如何快速响应用户需求**

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

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

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

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

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

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

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

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

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

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

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

# 2、历时4年的容器化之路 #

飞贷的容器化建设，起点很特别——**公司内部所有的系统都是自研开发**。容器化建设其实是对基础架构层的重新打造，自研系统的优势就在于对原系统和架构的改动不用经过第三方。陈定玮提到，“如果飞贷是采用第三方系统，那么每次新技术引进都需要跟合作方去谈，但问题是传统的软件系统对于基础架构这一层的事情并不太关注，这会在一定程度上阻碍基础架构层的技术改进。另外，飞贷的技术基因与其他公司有些不同，我们非常看重基础架构层的建设，因为这是整个飞贷赖以生存的一部分。从业务层面来看，飞贷本身有 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 端客户的技术人员也比较认可的方式。

**飞贷容器云平台建设思路**

![13894260-0dfd5cd69a5aa63c][]

谁说数据库不适合Docker？解读MySQL DB Mesh的创造性实践

容器云平台架构

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

*  是否勇于尝试新技术；
 *  新技术能否结合实际来运用；
 *  评估技术成熟度和技术团队掌握能力，这里面包括两点，一是评估新技术是否足够成熟；二是判断技术团队是否有能力掌握。

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

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

![13894260-c4a0bafbad83b234][]

谁说数据库不适合Docker？解读MySQL DB Mesh的创造性实践

飞贷容器化建设历程

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

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

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

**容器化建设的坑与经验**

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

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

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

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

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

![13894260-5d61fb36e890c634][]

谁说数据库不适合Docker？解读MySQL DB Mesh的创造性实践

MySQL 容器化 DB Mesh 架构

飞贷不是第一个做数据库容器化的公司，之前一些公司也尝试过，但都失败了。飞贷做数据库容器化可借鉴的一些思路是：

**限制 DB 的容量**

只有单个 DB 容量进行限制，有了标准，才能够快速部署交付。但是对于银行和一些传统金融机构，一般采用 Oracle 数据库，数据全部堆在那儿，就很难做数据库的容器化，因为“牵一发而动全身”，如果改变数据库，那势必上层就要做很多的调整，这是数据库容器化的难点之一。

**结合中间件演化 DB Mesh**

飞贷在数据库容器化实践中，通过自研中间件，一个中间件对应一个 DB，下面对应不同的服务。在数据处理上，中间件可以让数据存储变得简单可控，这是数据库容器化的核心，形成一个类似 Service Mesh 的 DB Mesh 架构，DB 与 Service 解耦，使得 DB 的弹性调度非常灵活。

**改变传统的思维模式**

飞贷做数据库容器化，整套体系用于服务生产环境上的一切应用。但其实这套体系不利于分析和报表，因为做了很多分库，那么在做数据分析和报表的时候效率会非常低。陈定玮和团队想到了解决方案——用大数据做分析，把所有的报表、分析等文献，全部实时同步到大数据去，让大数据来处理。这样既保证了 B 端客户的处理数据的秒级体验，又能快速高效地做数据分析。

MySQL 容器化，透过 Istio 生成可视化图形界面，可以去做自动追踪，判断库的健康状况。但也存在一个问题，当数据库中断，再把它恢复的时候，Istio 追踪服务就不见了，需要手工注入。陈定玮提到，“这个问题我们进行了研究，没有找到很好的解决方案，可能还是要手工去处理一下，没有办法做到自动恢复。但是在应用与服务管理这部分，飞贷已经做到了完全自动化的 Istio 注入，实现了微服务访问、安全加固、控制、观察、服务追踪、限速、熔断、调度、负载等。”

**飞贷容器化平台成果**

飞贷做容器化平台以后，生产力得到了极大地提升：80% 的基础运维实现自动化；交付能力大幅提升，1 小时可以交付 100 套；实现极致弹性容器化调度、灰度升级、预发布、蓝绿部署、持续交付。在安全 / 敏捷 / 高效率上，实现业务数据全量备份分钟级；在灾难故障方面，业务应用一键恢复分钟级；数据快照秒级；资源利用率提升 10 倍，数据库交付能力提升百倍。

![13894260-8d2fcc510aaef3e2][]

谁说数据库不适合Docker？解读MySQL DB Mesh的创造性实践

Rancher Labs 大中华区总经理秦小康这样评价飞贷容器化平台：**在容器时代，飞贷金融科技仍然保持了领先的创新，并通过业界领先的数据库容器化技术，提升数据库服务交付效率，大规模的容器化分布式数据库集群部署开业界先河，值得大家参考学习。**

# 4、开源初心 #

谈及飞贷容器化建设的未来规划，陈定玮提出由 DevOps 向 AIOps 发展。“比如现在做了一个飞贷自动化运维 App，实现监控及消息告警，对接运维机器人，这其实就是大家一直在谈的 AI 概念，只是我们把 AI 的概念变到运维体系里面，结合容器化提高效率，实现更稳定的系统服务。这样，以后在这个 App 上面可以看到生产资源上所有的体系或者设备的状况；另外，我们会做很多自动化的策略，包含机器学习，就能快速知道问题发生后的处理办法，减少 RD 或者运维人员的压力，提升整个平台的自动化和智能化的能力，由 DevOps 发展到 AIOps，就是往智能化运维去发展。”

未来，飞贷希望把整个应用放到开源社区里，因为目前很少有这种整套的解决方案作为开源的技术去开放出来。这是飞贷未来努力的一个目标，陈定玮说，“我希望在明年能够实现。”

[13894260-0dfd5cd69a5aa63c]: /images/20211211/6231ec70eee74fa0bdb9b9bcea5b03ea.png
[13894260-c4a0bafbad83b234]: /images/20211211/86e111e16ff44856bd551a18d20a0b4b.png
[13894260-5d61fb36e890c634]: /images/20211211/b5a45bf08b94436ab2e6e9c3e598329b.png
[13894260-8d2fcc510aaef3e2]: /images/20211211/4f3d7aa9f72340338f56a15d1e89330f.png