互联网金融核心云原生数据库应用与实践

银行企业使用云的方式有三种：私有云、公有云和混合云。无论如何，它都将面临最重要的工作之一，即数据库上云。问题是，为什么许多企业选择云原始数据库？私有云原始数据库将面临哪些挑战？如何正确选择云原始路线？本文将根据渤海银行云原始数据库的实践进行分析，梳理云原始数据库建设的关键点，小心踩坑。

银行类企业使用云的方式有三种：私有云、公有云和混合云。

所谓私有云，是以开源技术为核心，基于银行自己的IDC搭建。在此期间，虚拟化技术和K8S容器技术将被使用。它具有较高的独立性和可控性，运维成本相对较高，对技术人员的要求也较高。因为，从每个服务器和上述操作系统软件到云平台的整个IaaS和PaaS层都由银行自己构建。

公有云是指银行将选择购买第三方云厂商的服务。服务器和产品部署在云厂商的基础设施上，所有底层技术均由云厂商完成。这种方法的优点是相对简单方便，操作和维护要求非常低。然而，这种方法也有一个缺点，即定制程度相对较高。银行只能遵循云厂商的结构，不适用于许多关键业务或重要水平较高的系统。此外，由于业务性质的要求，银行的关键业务不能部署在公有云上。

混合云，一些企业也被称为专有云，事实上，基本形式是相似的，即公有云的业务模式在银行机房完全输出，包括通过云原始技术能力为银行业务提供服务。混合云带来的最大优势是降低了搭建私有云平台的难度，使技术人员更加注重业务应用开发，支持运维系统相对完整，云运维难度较低。问题是，云在银行业务中并不完美。虽然混合云是大多数银行的最佳选择，但银行的独立控制能力相对较高；但由于相对封闭，了解内部应用的每一个细节和逻辑都需要很多时间。同时，由混合云提供商提供运维服务的银行难以独立控制，定制程度相对较低。

为什么选择云原生数据库？

银行核心业务上云，最重要的工作，就是数据库上云。那么，我们该如何理解诸多企业都在推崇的云原生数据库？和传统数据库相比，云原生数据库有哪些优势？

综合来看，我们可以从5个方面来对比：

1、 并发处理能力。

基于云原生本身的特性，在弹性扩展、高性能支持方面有出色表现，所以高并发的处理能力也比传统数据库更强一些。当前，银行互联网业务高速发展，传统数据库的单机模式以及相关的硬件资源配置，已经很难满足业务量快速增长的需求。

2、 可扩展性。

云原生数据库一般都是自带高可扩展性和数据重分布能力，而且对业务的影响也比较低。相对而言，传统数据库的可扩展性较难。之前，银行同业也基于Oracle、 MySQL等做过数据库弹性扩容机制的尝试，但由于技术能力和传统数据库的技术架构受限，实现起来比较难。

3、 架构统一性。

云原生数据库有着先天的技术统一性和融合性，凭借云内数据库体系和相关逻辑，可依赖云平台能力解决架构统一性问题。但是，如果是传统数据库，各个产品的使用以及特殊场景的融合能力，需要单独考虑，比如：AP数据库、TP数据库或者缓存数据库路径融合，需要对应哪个产品，只有深度掌握和了解，才能做更好的融合。

4、 运维复杂度。

云原生提供的产品种类繁多，关联性强，但问题排查能力比较低，需要依赖云原生能力；而传统数据库在运维上相对更容易，基于现有的硬件、IO、内存和CPU，比较容易定位产品问题，便于纵向深度探索。当然，最终运维水平如何，还依赖于人的能力。

5、 场景灵活性。

在场景灵活性方面，云原生数据库相比传统数据库更低一些，因为所有能力都是相对封装，可定制化和DIY的能力比传统数据库差。

问题是，了解了云原生数据库和传统数据库的差异化能力以后，我们应该如何去构建云原生数据库？渤海银行的一些经验，或许能为更多银行类的企业带来参考和借鉴作用。

从2018年开始，渤海银行引入混合云，经过三年多的技术平台建设以及运营体系的不断完善，目前已基本形成了应用改造上云的标准流程体系，先后有些关键和一般业务类系统都已经逐渐完成上云，目前已经上云的最重要的系统就是互联网金融核心业务系统，承载了绝大多数的互联网业务和对外接口。未来的计划是进一步完善多中心混合云体系，构建同城多活、多地多中心的云体系。

云原生数据库建设如何按照规划搭建？

那么，从实践的角度来看，云原生数据库建设该如何按照规划逐步落地？

首先，要完成同城三机房布局，巩固异地机房建设，形成同城三中心、多地多中心的架构。并且，同城中心生产云有2个主机房，计算节点是双活，包括缓存和MQ双活或者主备模式，能够支持同城机房的快速切换。其中，数据库应用同城三副本，可以更好地满足对RPO和RTO的要求；存储层主要还是用同城双活，异地机房整体上是冷备架构，所以对应用层、计算层、分布层都做了整体测试；开发测试云和生产云是同构状态，主要用来跨同城三中心，支持应用开发测试上云的版本升级以及全平台应用。

其次，在关键业务系统承载方面，建立互联网金融核心数据库体系与互联网业务中台，关键的互联网业务系统都要通过互联网金融核心进行业务流的展开，包括传统银行所有的电子渠道、手机银行、企业网银等等。目前，该系统已经完成了云上建设和云上投产，由于业务系统本身很复杂，所以对数据库技术有着更高要求。

如图所示，业务逻辑层包括账户中心、认证中心、产品中心、配置中心，都是微服务中心；向上是OLAP体系，包括流计算、列存储、BI和消息队列，用来进行实时分析；向下是数据缓存层，也是应用层关联到数据库的过渡层，数据库用的是云原生的缓存数据库。其中，关系型数据库是两种架构：一种是分布式；另一种是主备集群，都是通过数据库中间层的方式进行管理。数据迁移模块是云下数据库如Oracle向云上关系型数据库进行数据迁移的通道；数据集成模块是实现数据共享与互联互通的有效方式；数据同步模块支撑了各个系统实时数据同步的各类需求；集中监控模块对所有数据库产品进行统一管理和监控。

云原生数据库实践如何避免踩坑？

大体来看，云原生数据库实践不是“拍脑门行为”，而是要依靠平台架构思维从创建云平台之初就对数据库体系进行整体规划。

具体而言，企业应该关注三个重点：

第一，云专有网络与经典网络的融合；混合云平台在进行部署的时候，一般会用专有网络。问题是，专有网络如何与原有IDC经典网络进行融合，这是一个难以回避的课题，必须在最初规划的时候就解决掉。渤海银行的建设思路是，减少不必要的网络交换机与防火墙限制，避免云上云下系统相互访问的时候，在数据库网络节点上产生不必要的开支。如果网络融合做得不好，数据库的整个链路会产生一定的网络延迟，对业务的影响非常大。

第二，根据数据库产品特性和业务应用场景提前规划数据库产品部署方式。现在，大部分云厂商都能提供多种部署方式，包括容器的部署、虚机的部署、裸机的部署等等。那么，关系型数据库如何部署需要根据实际场景进行规划，目标是发挥各类数据库产品的特长，提升全局的性能，提高资源使用率。

第三，云内外相互系统的访问规则要提前设置好。云内外的相互访问数据库和数据库间的场景需要提前规划好，梳理出相应的场景，后续应用上云和迁云改造的过程中，要进行场景限制，不能对应用上云天马行空，随意更改架构，而是要在场景范围内去做架构设计。最终的建设目标是，降低数据库链路产生异常的概率，便于对后续问题的排查，进而提升云上云下应用相互访问的效率。

众所周知，银行在使用传统数据库的时候都有很多规范，在项目开发的时候要严格遵守。其实，云原生数据库也一样，只不过云原生数据库需要使用多种架构对应多套开发规范。比如：交易型数据库、缓存型数据库和大数据产品等，都有自己的通用规范；在云原生体系下，也要遵循相应的通用规则。

与此同时，银行关键业务对连续性有高标准要求，同城和异地容灾能力尤为重要。与传统架构相比，云架构的同城容灾能力实现起来更为复杂，难度也更大，其中数据库容灾体系的规划和建设是重中之重。

关于容灾体系建设，不管是国内的头部厂商，还是新兴厂商，对银行业务的理解以及系统架构的部署，还有进一步提升空间，尤其在同城容灾、异地容灾体系的建设和规划方面，还相对比较初级，所以选用云原生体系、云原生数据库，一定是要在最初架构设计的时候做出同城容灾、异地容灾选择。

容灾架构的选择：一个是集群内的容灾；一个是集群间的容灾。集群内的容灾，就是在同城跨机房环境中采用MySQL主从或者Oracle RAC之类的架构进行部署。一个集群的各个节点都被打散，分散到各个不同的机房，其实这种方式有优势也有劣势。优势，是可以用数据库集群原生的容灾能力实现同城高可用，实现难度是很小的，几乎没有二次开发的地方，切换能力也可以复用；劣势，是把集群拉大的同时，大大增加了集群各个节点之间的距离，提高了节点间的通讯延迟。对比多家银行的机房环境，同城机房大多距离是40-70公里之间，相应的光纤距离就是50-100公里左右，所以对集群节点拉开的影响到底有多大，需要具体评估。因为延迟会直接影响到数据库各个节点之间的通信，也会影响到业务交易响应时间。集群间的容灾，是指数据库多个集群之间去做一个两集群或者三集群的数据同步，保障各个机房数据的可用性。但是，做集群切换的时候，数据的一致性比较难保证。

值得一提的是，银行关键业务系统容灾，对RPO和RTO都有严格要求。比如：RPO大小衡量的就是同城切换可能会丢失多长时间的数据，RPO=0的要求就是一定不能丢失任何数据，RTO代表着整个数据库同城切换以后对外恢复的时间是多长，一般是几秒或者十几秒。

一般情况下，混合云架构的同城容灾需要从全平台层面进行控制，包括会采用三机房的应用和数据库部署架构，因此相较于传统架构技术难度更大，同时需保证同城RPO为零，可全量保留所有数据。

容灾体系建设，还有一个最大的难点，就是应用的关联关系。传统银行业体系包括国有大行、股份制银行、城商行，大部分机构目前处于架构转型阶段，很多大行的关键业务还跑在IBM大型机上，全国范围来看肯定是长期保持云架构和传统架构的并用。不管是私有云还是混合云方式，云上关联访问场景必然存在，这中间除了应用链路、访问效率问题，容灾体系建设存在很大挑战。因为多数情况下云上应用和云下应用切换的规则和逻辑不同，当单边发生切换的时候，怎样保持系统间互访？同时如何保持各业务的连续性？

渤海银行的方案是，通过全局的DNS改造和全局的域名解析，来解决应用系统关联问题。目前，商业化混合云基本上已经能够全部实现云内全面DNS访问，数据库集群和中间件产品通过域名也都能够访问，但银行传统架构下大部分的应用都是通过IP直联的访问方式或者VIP的方式。DNS改造就是采用单一域名对应多个服务IP或VIP的方式，实现集群发生切换时即便VIP发生了变化，多个VIP只要有一个处于活跃状态就能够成功解析，无论云上云下应用怎样切换，相互访问的规则都不变。

总结：其实，根据经验来看，云原生数据库也好，云架构也好，并没有统一选型标准。企业如何选择云架构和看待云原生，都应结合自身实际情况进行分析和判断。

微云 网络作为国内的云服务商，密切关注云计算的发展动向，搭建良好的云生态，为企业提供MPLS VPN、SD-WAN、云专线、混合云组网等服务，如果您有相关应用场景可随时拨打400-028-9799电话进行咨询。