一、金融行业结构转型需求随着移动和互联网的不断发展，我国金融业的业务模式和技术体系逐渐走上了一条道路这与西方世界完全一致。不同的路径。众所周知，欧美国家的手机普及率远低于我国，人口基数也相差几个数量级。这使得国内外金融行业面临的业务类型、数据量、并发量存在巨大差异，从而对整个IT基础设施提出了完全不同的需求。近一两年，国内一些技术领先的银行率先探索微服务和分布式技术，一些互联网金融新业务也开始尝试使用微服务架构、分布式技术、DevOps框架进行应用开发和应用。维护。甚至一些银行在规划下一代核心系统架构时，也会尝试适当引入分布式架构，以满足未来的业务压力和不断增长的数据量。与新一代分布式架构相比，传统的中间件加数据库的“烟囱”架构在面对海量数据、高并发、高响应速度的业务应用时存在诸多问题。从业务部门和系统来看，复杂的业务导致企业内部系统众多，分散，数据完全隔离，无法共享；系统缺乏灵活的横向扩展能力，性能瓶颈明显。容易遇到硬件瓶颈，无法满足灵活扩展的业务需求；系统无法快速响应海量突发请求，如双十一、闪购等业务瞬间爆发式增长，难以应对；采购和运维成本高，小型机设备和软硬件独立采购运维，导致总体拥有成本高；缺乏自主管控能力，对国外厂商依赖度高，问题严重，本地支持团队难以在短时间内解决问题，导致生产经营风险加大。2、银行架构的演进过程近二十年来，中国银行的IT架构经历了几个阶段的变迁。我国第一代银行核心系统建立在大型机上，采用典型的集中式架构。随着SOA概念的引入，一些银行也开始逐步去大型机，将核心业务系统从大型机或400上移到UNIX小型机上。虚拟化技术的增强使得一些银行和金融机构在其基础设施中引入虚拟化机制，将应用程序部署在开发环境和一些生产环境中的虚拟机上。如今，许多银行已经建立了基于分布式和PC服务器架构的大数据平台，一些基于微服务系统的应用将业务逻辑容器化，后台结合分布式存储和数据库技术，形成端到端的分布式架构体系。已实现。正如多家银行的技术部门经历了核心系统从集中式向SOA转型的艰辛一样，从目前的小型机系统向分布式架构的转型也面临着巨大的挑战，如技术栈的选择、应用开发、DevOps系统搭建等当应用开发从传统架构向分布式架构转型时，首先面临转型的自然是应用框架。如今的微服务框架已经非常成熟，其代表架构往往包括协议处理、服务组装、原子服务、底层持久化四层。将业务逻辑从传统的单一中间件拆解成多个微服务模块。每个微服务模块由一系列完全等价的容器组成。只需添加容器即可扩展服务的吞吐量和处理能力。但是微服务的拆分意味着每个服务都有自己独立的执行逻辑和存储。从数据库的角度来看，微服务体系的拆分对数据库存储提出了很大的挑战。如果每个微服务仍然将数据存储在传统的单点数据库中，随着微服务容器数量的增加，其存储和处理能力无法提供相同的可扩展性。在这种情况下，数据库将成为微服务架构框架中制约性能和扩展性的最大瓶颈。而如果每个微服务都使用独立的数据库进行存储，整个企业IT的数据架构就会变得碎片化。数据库数量从过去的数百个拆分为数万个数据库，整个运维团队的管理成本和数据库采购成本面临几何级数的增长。因此，分布式数据库的目标不仅仅是作为传统Oracle或DB2的单一替代品，而是将一个数据库无法存储的数据存储在多台物理机上。在实际环境中，大部分银行都有比较完善的数据生命周期管理策略，生产环境中一般不会积累大量的历史数据，因此数据量一般不是使用分布式数据库的最重要原因。3、分布式数据库架构体系分布式数据库的核心价值是为分布式应用提供一个弹性、可扩展的数据服务资源池，也可以称为DBPaaS平台。其主要能力是为上层不同开发者、不同业务类型、不同SLA安全级别、不同数据类型的数万个微服务提供一个可弹性扩展、响应速度快、易维护的数据库服务平台.支持高可用配置、容灾策略定义、多租户、业务数据逻辑与物理隔离、事务分析混合模式隔离、不同微服务数据间冷热数据隔离等一系列数据隔离与治理机制。对于一些采用微服务架构的互联网公司，20多人的数据库运维团队可以支撑数十万个不同的数据库实例。运维的核心是为企业搭建统一的DBPaaS平台。弹性扩容等机制，大规模简化运维人员对数据库的管理。目前业界有很多分布式数据库产品，主要分为三种架构体系。1.应用垂直拆分应用垂直拆分是最传统的分布式概念。其中一种实现方式是将应用拆解成多个独立的子服务，每个服务对应整体中的一部分数据；另一种实现方式是在一个服务中连接多个数据库连接，在应用程序中根据业务规则选择一个数据源。例如，应用程序根据用户帐户ID进行分段。ID在1到100万之间的用户存储在数据库A中，ID在100万和1到200万之间的用户存储在数据库B中，以此类推。该机制在应用程序中预置了一条规则，每次进行数据访问时，都必须从规则库中过滤掉目标所在的数据库实例，然后直接获取连接进行访问。使用这种机制，一方面，跨库事务极难实现；另一方面，从应用的角度来看，分布式能力的业务侵入性极强，需要大量的定制化开发才能完成基本的业务逻辑。扩容需要对应用逻辑进行完整的端到端梳理，这可能涉及到很多风险和二次开发工作。2.中间件分库分表随着分布式存储能力需求的普及，业界逐渐兴起了另一类技术体系，称为中间件分库分表。这类技术系统的思路是在应用程序和数据库之间建立一个SQL解析器服务，解析传统的SQL然后翻译成对应各个底层数据库的子查询，然后直接将查询发送给执行底层传统数据库。这种机制的优点是数据存储可以在传统关系型数据库的基础上保持不变，同时上层对应用程序接口进行了一定程度的封装。但从整个行业的角度来看，中间件分库分表的机制可以认为是传统单点数据库向分布式数据库的过渡阶段。在基于PC服务器的新型分布式数据库普及之前，一些急需数据拆分的应用可以通过这种方式来缓解业务和数据量激增的压力，但在未来原有的分布式数据库成熟和验证之后，其优势会大大降低。很难继续下去。同时，这项技术不能对应用程序做到100%完全透明。一般来说，在应用程序中组装SQL时，需要指定一些参数或使用独特的语法，所以很难做到对应用程序完全透明和不知情。3、原生分布式数据库不同于中间件分库分表技术。原生分布式数据库直接在PC服务器的基础上从底层存储引擎重构，从数据存储结构、数据安全机制、分布式事务控制等角度，针对分布式存储和执行进行了优化。原生分布式数据库是在底层完全从头开发，完全摒弃小型机系统的分布式数据库。它基于PC服务器硬件架构设计，自然地将高可用、容灾、分布式机制融入到数据存储系统的方方面面。例如，一些分布式数据库产品可以在100%兼容MySQL的前提下，实现对应用程序完全透明的分布式存储和执行能力。从开发者的角度来看，用户不需要关注一张表是几亿条记录还是几十亿条记录。只要在创建表时配置容量和最大物理资源消耗策略，数据就会自动分布到集群中的多个物理设备上。平衡的，从应用的角度，直接读写请求，就像访问标准表一样。4、原生分布式数据库技术趋势为了支持未来的IT微服务框架，分布式事务数据库的引入需要从传统技术兼容性和新技术前瞻性两个维度进行评估。ACID支持和SQL完整性支持是评价一个新的分布式数据库能否提供与传统数据库技术兼容性的两个关键指标。1）ACID支持从安全的角度来看，无论采用新技术还是传统技术，数据不丢失是所有数据库的必要基础。在分布式数据库行业，一些针对互联网技术设计的产品以分布式（PartitionTolerance）和高可用性（Availability）为目标，在安全一致性（Consistence）方面无法保证数据的正确性，难以在金融服务中使用.被广泛使用。因此，银行所关注的新型分布式数据库首先要保证数据的安全性和一致性，其中分布式事务、分布式锁、支持四种隔离级别等都是该指标的关键技术点。2）SQLIntegritySupportSQLIntegrity是指新型分布式数据库和传统关系数据库的开发友好性。分布式数据库越成熟，它的SQL语法就越能兼容传统的关系型数据库，它的数据切分对应用程序就越透明。如今，大多数分布式数据库技术都声称支持MySQL语法，主流的新应用程序也将MySQL作为默认支持的数据库选项。因此，MySQL语法协议支持的强弱成为判断分布式数据库SQL完整性支持的关键。新技术的前瞻性是指分布式数据库是否符合未来的发展方式和IT架构。3）分布式弹性扩展能力分布式数据库作为数据服务资源池，必须具备弹性扩展能力，才能不断增加服务于上层的微服务的种类和数量。同时，对于每一个微服务，其数据无论是存储在一个物理设备上还是多个物理设备上，都必须对其中的应用代码完全透明。4）多模引擎服务于来自不同开发者、不同业务场景、不同数据类型的上层微服务。分布式数据库必须支持多种SQL协议和计算引擎。从存储引擎的角度来看，结构化和半结构化数据可能同时在应用程序中使用。因此，新一代的分布式数据库需要从访问接口到存储结构都支持多模型（Multi-Model）引擎。5）HTAP（HybridTransactional/AnalyticalProcessing）HTAP是混合事务分析处理能力。在传统的银行IT架构中，在线交易和统计分析系统往往采用不同的技术和物理设备，通过定期执行的ETL将在线交易数据迁移到分析系统。作为数据服务资源池，相同的数据可能被不同类型的微服务共享和访问。当一些在线交易和审计服务同时运行在同一个数据上时，必须保证请求在完全隔离的物理环境中执行，使交易分析业务互不干扰。一般来说，分布式数据库技术的发展趋势需要从传统技术兼容性和新技术前瞻性两个维度来判断。其中，ACID数据安全和SQL完整性是传统技术兼容性的重要指标，而弹性扩展能力、多模式Engine、HTAP是前瞻性新技术的几项重要举措。5、金融分布式数据库应用场景在当前的金融行业，分布式数据库应用在五个主要领域：数据仓库、大数据平台、内容管理平台、数据中台、在线交易。对于在线分布式数据库的使用，目前业界主要围绕三类业务场景展开。1）网上交易系统网上交易系统是银行重要的生产经营环境。我国一些走在分布式技术探索前沿的银行已经开始逐步将核心业务流程系统从IBM和Oracle的大型机和小型机架构迁移到分布式环境中，使集群能够弹性扩展以满足业务随时爆发增长需求。一些典型的使用分布式数据库的系统包括网贷核心、渠道整合、信用卡积分等。2）数据中台如今，许多公司提出了强调中台而忽视前台的IT架构。数据中心作为企业IT数据集成的关键平台，将前台灵活多变的业务需求与后台相对固定的数据模型结合起来，起到“数据汇聚，前后连接”的作用。例如，银行可以先以缩减生产系统规模为目标，从历史票据的查询和打印做起，逐步扩展到用户画像、资产视图等准实时数据服务。3）内容管理平台传统的内容管理平台主要是为了事后监管和审计而搭建的，前端业务基本不直接参与非结构化数据的使用。随着自助设备和移动应用的普及，越来越多的流程处理需要非结构化数据的直接参与。因此，很多银行的内容管理平台正在从后台走向前台。大量面向客户的应用程序直接连接到内容管理平台。开户、授信，甚至大量的自助设备流程，都高度依赖内容管理平台的实时交互能力。使内容管理系统从传统的内部后台审核走向外部在线服务。可见，分布式数据库作为一种离线分析业务场景，已经在银行得到广泛应用。对于在线业务，MPP数据仓库和大数据平台在可靠性、并发性、响应速度等方面无法满足要求。4.小结目前，一些对分布式技术研究较深入的银行已经开始对分布式数据库进行试点应用。分布式数据库的核心价值不仅仅是将传统数据库无法存储的数据分散到多个物理设备上进行存储，更重要的是针对未来微服务的应用开发模型，面向不同的开发者，不同的SLA层次、不同的高可用容灾特性、不同业务类型的数据，提供可弹性扩展、多模式接口的数据服务平台（DBPaaS）。当前科技人员常问的一个问题：分布式数据库未来能否替代Oracle？这个问题的答案可以说是非常直观了。分布式应用框架和PC服务器集群化必然是未来IT发展的方向，微服务将取代烟囱式的软件架构，数据库必须从传统的平台“点”转向“面”。每个应用都有对应的迭代周期。现在我们可以看到很多应用已经开始使用MySQL等开源数据库作为默认的数据库选项。以后必须用Oracle的场景会越来越少。因此，分布式数据库在未来必将取代Oracle等传统的单点数据库。银行技术部门也应尽快对分布式数据库技术进行前瞻性研究，以适应未来银行IT架构从烟囱模型向微服务转型的趋势。
