10倍DB交付效率飞贷金融科技的数据库生产容器化实践

29次阅读

共计 4304 个字符,预计需要花费 11 分钟才能阅读完成。

2019 年 6 月 20 日,由 Rancher Labs(以下简称 Rancher)主办的第三届企业容器创新大会(Enterprise Container Innovation Conference, 以下简称 ECIC)在北京喜来登大酒店盛大举行。本届 ECIC 规模宏大,全天共设置了 17 场主题演讲,吸引了近千名容器技术爱好者参加,超过 10000 名观众在线上直播平台观看了本次盛会。

来自 Rancher、阿里云、百度云、平安科技、中国联通、飞贷金融科技、中国人寿、SmartX、华泰保险、厦门航空、JFrog、新东方、Cisco 等十多家企业的技术负责人出席了本届 ECIC,现场带来关于企业容器项目实践经验的精彩分享,为参会的容器技术爱好者带来企业容器化的经验分享。

飞贷金融科技副总裁陈定玮

大会现场,飞贷金融科技作为金融行业数据库容器化的典型案例,为现场的容器爱好者带来了题为《金融领域数据库生产容器化及 Istio 应用》的实践经验分享。

对于飞贷金融科技而言,生产容器化及数据库应用的难点在于,如何针对金融领域生产容器化及数据库容器应用进行实践创新,如何结合研发及业务场景落地,提升资源利用效率、提升产品研发、运维管理效率。

飞贷金融科技副总裁陈定玮表示:“金融行业数据具有相较于其他行业更为严格的安全高标准,在安全合规的情况下用飞贷自研中间件,解决金融领域 DB 应用场景难题,带来 10x 的 DB 交付效率,极致的弹性扩容能力。”

演讲实录

飞贷金融科技成立于 2010 年,是移动信贷整体技术服务商。我们以科技创新作为企业发展的动力,在科技创新的道路上不断前行。

2011 年到 2015 年,飞贷做的是传统的小微金融业务。2015 年,我们决定进行线上互联网化转型。到 2017 年,我们整个公司进行了战略升级,为金融行业客户提供互联网服务。迄今为止,飞贷为人保、北京银行、华润信托、通联支付等多家金融行业企业提供了全链路的科技服务。

2018 年,我们登上了美国《时代周刊》,被《时代周刊》称为“全球金融科技最佳实践”。同年,我们还拿到了世界银行和 G20 共同推出的首届全球小微金融奖最高荣誉——“年度产品创新”铂金奖。

接下来,我会和大家详细介绍一下,飞贷作为一家互联网金融科技企业,是怎样和容器化相结合,又是怎么在业务上应用容器化的。

飞贷应用容器化与前面分享的企业一致,同样也是基于整个企业的容器化应用。值得一提的是,飞贷做的是金融领域,所以我们对安全、对容错、对高恢复的部分相较于其他行业的企业而言更加在意。我们关注的不仅仅是应用,更多的会关注到如何迅速地进行灾难的恢复。

我们利用容器进行了整体的架构部署,从大家比较熟悉的 DevOps,到我稍后会重点介绍的 DB Mesh 的部分。我们划分了几大平台,包括容器化平台、产品研发平台和数据平台。下面的是应用安全、数据安全、网络安全、容器安全、运维安全等部分。容器对我们而言帮助非常大,现在我们的 RD 都是基于容器 Kubernetes 做应用开发。在这一部分,飞贷在金融领域已经达到了领先的水平。

下图是飞贷的容器发展路线图。我们从 2015 年开始研究容器,2016 年开始投产在 RD 环境上。在当时我们还没能完全选定 Kubernetes 还是另外一个容器技术,所以暂时停留在 RD 阶段。2017 年,Kubernetes 技术越来越成熟、越来越稳定,我们就把整体的方向往 Kubernetes 方向进行迁移。到了今年,我们的生产环境已经可以大量运用容器技术进行多个方向上的应用了。

刚才 Rancher 的 CEO 梁胜博士提到,现在 Rancher 已经可以做到多 K8S 集群管理和部署,多数据中心。这是和我们的业务发展比较贴合的。我们提供基于飞贷的金融云服务,同时我们有多租户集群管理的业务需求。目前,我们已经可以针对 K8S 多集群进行应用服务、中心服务、数据库服务等多个方向的多集群管理,同样,我们也可以做到多租户网络隔离。

从客户的角度来说,在客户和我们合作之前或者是过程当中,他们先前可能并不了解小贷的业务运营是这样的,所以银行会把他们的整体服务放在我们公司,飞贷就变成了一家金融云厂商。而飞贷的特殊之处就在于,我们专注于和我们业务发展相关的内容,我们为客户提供的不是一个整体的平台,而是应用。

刚才提到的所有内容都是和容器息息相关的,容器的特性包括安全审计、动态存储、高可用灰度发布等等,我们把容器的特性应用到了飞贷生产环境上,并且发挥到了极致。

下图是飞贷容器化的平台组件。无论是我们的 RD 还是外面的人员,飞贷会为他们提供应用商店,他们要做什么事情,就在我们的管理平台点击一下,我们会自动生产一个容器的应用帮他们进行处理。我们镜像仓库的部分是在一起的。

除了这几个部分,我们还有 Prometheus 和 Jenkins,这些体系和我们研发的相关度比较高,现在飞贷能实现自动集成、自动打包、自动发布和自动部署,这是我们研究了两年多的平台组件成果。

飞贷为什么要让 DB 容器化?因为微服务部分的应用层已经发展得比较好了,但是对于 DB 而言还有很多的问题。假如 DB 宕机了,我想要迅速恢复这个 DB,让业务生产能够正常运行,我们需要花费多长的时间呢?如果 DB 非常大,这个启动时间是非常久的。这就是为什么银行或者是大型金融机构没有小型机,不敢用开源的 MySQL 或者是 MangoDB 等资料库,因为他们要保证安全和持续运作,这是一个比较大的挑战。

这就是我今天要重点讲述的几个问题,为什么要 MySQL 容器化?MySQL 容器化安全稳定吗?容器化 MySQL 的具体实现是样的?

我们刚才介绍了飞贷要做多集群管理的容器,里面存在一些限制以及要求。第一,会涉及非常复杂的网络结构;第二,故障要频繁地切换,我们认为这在金融行业是非常重要的一个部分,因为一旦发生故障,金融行业的业务基本上就会停摆了;第三,要控制容量大小;第四则是要依赖网络存储。

我们之所以要做这个部分,有三个方面的原因。第一,我们需要实现标准化快速部署,因为应用快速部署完之后,如果 DB 部署很慢的话,对于我们而言,整体效率还是一样地低,这是站在整体效率的部分而言的;第二就是微服务场景,我们现在的系统已经是全部为服务化进行终端的调整,在这种场景下,如果数据场景不能微服务化,那我上层所做的内容毫无意义,我们不希望数据库成为业务弹性伸缩以及管理的短板;第三就是 MySQL 服务化、自动化、网络化和智能化的需求。

我们进行 MySQL 容器化的效果很明显。第一,我们可以实现高效弹性伸缩、扩容、备份、导入、导出、恢复、快照、迁移;第二,我们可以实现整体数据库的性能监控和审计;第三,分布式存储、资源、数据多副本可以实现实时同步。我们在大数据应用的部分可能和一般的公司也有所区别,我们生产环境的一些数据和大数据实时数据是拆分开的,但我们做到了实时同步;第四就是计算资源分布式,多节点,技术设施高可用;第五是拥有故障自愈的功能。我的 MySQL 如果宕机,我们可以迅速恢复。

下图是我们 MySQL DB 的架构,底下的应用服务对应的是中间件,我们所有的中间件对应每一个单独的库。我们为了实现 DB 容器,把库做到了非常大的空间压缩,并且把库进行了容量限制,这样才有可能在库故障的时候,可以迅速的启动它。这部分考验了我们整体的业务运作部分,数据分表分库的能力、读写分离的能力。而这部分都是通过我们自行研发的中间件完成的。如果没有我们自行研发的中间件,DB Mesh 这部分内容是我们也无法完成的。

以上基本就是飞贷 DB 的网络发散图,架构特征包括几个部分,一是高并发、低延迟,每秒 10000 事务处理,延迟小于 100 毫秒;二是支持 IDC 多活;三是支持数据路由;四是可以自动化或者人格化决策切换;五是数据多副本。

截至目前,飞贷的 DB 量级是 PB 级别的,我们大概是十几个 PB 这种应用数量,可对外同步实施,故障容器数目大于二分之一可以自动回复,这就是为什么我们要做 DB Mesh 的原因。

另一部分是关于我们容器化整合 Istio 的,右边是我们生产应用的图形界面,可以看到注册进去之后,我们就可以进行自动追踪,了解库的健康程度。但是里面还有一些小问题,当 DB 断掉再恢复之后,这个服务就不见了,需要再次手工注入。关于这个问题,我们研究了 Istio 的很多文档,但还没有克服这一问题。所以在 DB 这一部分,我们只做到在生产的时候,一开始可以注入,但是当它挂掉之后,我们还是需要手工处理,暂时没有办法自动恢复。

而在应用和管理服务的部分,我们已经做到了完全自动化,整合 Istio 实现微服务 Service Mesh,实现了微服务访问、安全加固、控制、观察。服务追踪、限速、熔断、调度、负载等部分。

以上是飞贷整体服务的应用部署,从应用服务到中间件,这是我们整体部署的发布图,所以现在我们的 RD 人员基本上只负责开发,开发之后,所有一切都通过我们的平台去进行集成、发布和管理,上了生产环境之后,也会由我们的运维来处理,不会由 RD 来处理。在这一点上,我们做的还比较符合银行的要求。

最后,我想介绍一下飞贷容器化带来的成果:

第一是提升飞贷整体生产力。飞贷 80% 的基础运维都是自动化的;其次,交付能力也有所提升,一小时我们可以交付上百套的服务应用,目前来说有上千台容器在我们整个生产环境上面运作,如果我们没有进行微服务容器化的话,微服务架构部署时间会非常长;最后一个是我们具备生产环境上数百个 MySQL 的实例,这也是我们的一个容器化成果;

第二就是研发和扩展,可以按照容器的 pod、物理主机节点、机柜及数据中心级别做扩展,这块我们也结合了很多 CMDB 的内容,但在这里就不详表了;

第三是 IT 成本的投入,这也是我们企业比较关注的一个内容,我们之前的私有云是用 CloudStack 作为平台去搭建的,现在我们全部换成了容器。这大约节约了我们 40% 的资源,节省了 60% 的人力投入。以前我们要部署一个应用还需要提供虚拟主机在 RD 上面部署,现在容器一键部署就可以完成了。另外项目研发投入时间也节省了 40%,因为部署应用之类的内容现在已经不需要 RD 人员来处理了,都是由我们平台自动化处理的;

第四是安全、敏捷、高效,这部分业余数据的全量备份我们也是分钟级的,我们的库缩得足够小,所以我们可以在几分钟内迅速备份;第二在容灾故障的时候,我们的业务运用一键恢复也是分钟级的,数据快照是秒级的,资源利用率提升 10 倍,数据库交付能力提升近百倍,我们整个应用有上百个 MySQL 节点,如果一个个部署非常慢,我们现在已经把镜像做起来了,所以部署是非常迅速的;

最后一点是运维变得非常简单,自动化、极致的、弹性容器的调度,灰度发布、预发布、蓝绿部署、持续交付。

正文完
 0