摘要：银行类企业使用云的方式无非有三种：分别是自建云、公有云和专有云。不管是哪种方式，都会面临一个最重要工作，那就是数据库上云。问题是，为什么很多企业选择云原生数据库?自建云原生数据库会面临哪些挑战？如何正确选择云原生路线？本文将根据云原生数据库在渤海银行的实践进行分析，梳理出云原生数据库建设的关键点，谨防踩坑。

　　本期分享嘉宾：渤海银行总行科技部高级经理 曹啸

　　简介：拥有近十年的金融科技领域工作经验，曾就职于头部国有大行和股份制商业银行。在银行科技系统开发条线和运维条线均有丰富经验，重点技术领域集中在各类数据库的架构设计与生产运维。近些年主攻开源数据库、国产数据库、云计算技术等领域，对云原生数据库、开源数据库的底层运行机制和源码分析亦有所研究。

　　放眼望去，银行类企业使用云的方式无非有三种：分别是自建云、公有云和专有云。

　　所谓“自建云”，就是以开源技术为核心，基于银行自有的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只要有一个处于活跃状态就能够成功解析，无论云上云下应用怎样切换，相互访问的规则都不变。

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