基于容器技术的金融生产级的DBaaS的建设经验

2018年8月15日，由中国信息通信研究院、中国通信学会、中国通信标准化协会共同主办的“2018可信云大会”在北京国际会议中心圆满落幕。会上，行业内多位大咖与权重人物就可信云与云计算的创新发展新路径进行了共同探索与分析。

以下是中国银联信息总中心数据库团队负责人曾玉成老师关于“基于容器技术的金融生产级的DBaaS的建设经验”的分享。

大家下午好，我是来自银联的曾玉成，我今天给大家分享的主题是基于容器的金融数据库云平台DBaaS实践，这是我们今天这个主题有状态云的很重要的一个数据库的情况。

我今天分享主要有四方面：

第一，我们为何会走做数据库云化这个方向？

第二，我们在走这个方向的过程当中一些解决方案。

第三，我们在做的过程当中碰到的一些问题和经验。

第四，我们这个产品和平台后期的一些远景规划。

在一些金融行业里面或者是传统企业里面，都是关于Oracle数据库的，比如商业数据库或者商业的服务器，在产品设计上也是集装式的架构，运维就是手工和脚本形式运维。

为什么会慢慢引发到这个地方来呢？

第一，是在一些开源技术的推动和国产化的要求下，这些几年国家也在强调自主可控，要做国产化这块。

第二，随着技术架构的发展，现在的技术发展慢慢出现了微服务化，分布式化、平台化这样一些特性。在这样一个发展趋势下，加上业务上的需求驱动，Mysql、Hadoop等慢慢就用起来了。结构慢慢由集中式走向分布式的特性，走向了开源自主可控的这样一个发展。

这是我们觉得在传统金融行业里面技术发展的一个趋势，我相信大部分的企业都在这个过程当中。

具体到银联发展这块业务驱动，首先我们刚开始主要是做一些POS、ATM，是传统的现象服务。随着移动互联网业务的快速发展，比如很多Pay的APP，更多呈现的是互联网的业务特点，有一些大规模的用户，要求快速响应、要求比较弹性、灵活。需要做有更高的交付能力、更高效的资源利用、更灵活的弹性调度以及大规模的高效管理的产品，要求我们技术适应这块的发展。

所以我们就要想办法找到一个解决方案，怎么来解决我们大规模的这种服务能力的这套技术方案。很重要一点就是在弹性这块，做技术的应该很清楚，最难做弹性的就是数据库，因为跟数据相关，要做好弹性首先就要把数据库做好。所以，当时就想到类似做快速交付的平台，DBaaS的平台，这个平台有几个目标：第一要有分钟级大规模交付能力、灵活的资源弹性调度能力、高效的资源利用率、服务安全可靠；以及具备大规模、多中心的服务管理能力。

确定好目标以后我们怎么做呢？在2014年的时候，我们做了一些平台性的东西，主要是做了一些自动化的工作，把手工脚本的工作做成了平台的点对点的自动化。当时，我们做了第一代的DBaaS平台，做了多租户隔离等等一些，同年还做了弹性管理。

2016年我们想把容器和数据库结合做一些事情，当时大规模的应用都在应用场景里面，数据库和容器化结合是非常非常少的。在网上流行的一些文章都是数据库未来容器化的七个理由。同时我们也看到容器这个东西带来了它的很多的好处的，如果这两个结合起来的话，对于数据库大规模的部署管理和弹性调度这块是一个非常大的一个好处，所以我们开始调研，做一些测算，就做了一些方案。2014年的时候我们就开始做这些方面的调研。

2015年我们拉富麦一起做了一些POC的测算，当时觉得容器化确实不成熟，他们讲的也是很有道理的，为什么？在数据库方面我们面临最大的问题，就是怎样提高数据库的响应能力，在原来的容器的体系底下，更多的是一些无状态的，数据量不大的情况下的场景设计。在大规模的网络交互的情况下，性能非常差的。后来我们想只有把它改进，使之适应数据库，于是决定去做这个事。

一年多的时间，2015年我们终于把基于其的DBaaS做出来了，2015年直接上了我们生产的环节，而且是应用于生产的很多核心的业务。在这个版本里面，基本上基于我们容器的框架去做。当时选择的是Swarm做的，主要是由银联定制的MySQL跟MySQL定制的数据库。这个版本实现了分布式化弹性管理的一些特性。

这个我们叫金融级数据库的PaaS平台，为什么是说金融级的呢？这里面有很多结合金融场景的一些设置，其中包括提供的服务UPSQL和UPREDIS，是针对场景定制的东西。目前已经可以做到自动可控、弹性伸缩等等功能。在国内金融行业里面据我了解是我们是第一家，我们是2015年底到2016年初在生产环境下大规模部署的。

用Docker分装数据库有五方面的问题需要解决：第一，选择什么容器管理框架，因为容器管理框架也挺多的。有状态服务的网络模式应该怎么做？存储管理模式怎么去做？集群服务管理能力，规模应该是集群组成的服务，这个集群服务本身的平台不提供这些东西的，你要自己去管理服务集群的能力。另外还有横向扩展方面。

关于容器管理框架，我们为什么选择Swarm而不是K8s，当时不管是Swarm和K8s两种方案都不行，当时为什么选择Swmarm，因为是轻量级的容器框架，开发难度低一些，当时在K8s流行的情况下选择了Swarm，不管做哪个我们都要自己开发，把我们已经实现好的解决方案用K8s的方式集成出来，这两种我们都可以支持并且落地。

关于网络方面，有状态服务区别于无状态服务非常重要的一点，就是怎么样把网络和存储这块的解决方案解决好。

在传统的Docker的网络模式下，要么就是安全不行，无法提供独立IP，另外就是数据库损耗比较大。有没有办法网络安全隔离，而且是没有损耗的，而且支持大规模部署的，当时我们就找到SR_IOV的硬件虚拟化的技术，这也是网卡上的功能，可以把王扩虚拟成180颗物理卡，把这些物理卡怎么给容器独立使用，在上面做QOS隔离这块，我们把这套方案做出来了，实际的效果是这套技术非常好，可以解决有状态服务的情况下网络的需求，而且物理环境下是无损耗的。两块物理卡虚拟128，在里面挑两个VF，在里面做，端口都是一样的，可以提供网络性能的保证。

而存储这方面是金融行业里面有区别于其他的一些互联网公司的做法，这里比较重要的是我们做了存储管理的Plugin，可以把金融行业的储备用的扇存储做起来了。

（编辑：核心网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!