首页 > 行业资讯 > 银行四类业务负载的存储技术路线和方案选择

银行四类业务负载的存储技术路线和方案选择

时间：2023-10-31 来源：浏览：

银行四类业务负载的存储技术路线和方案选择

twt社区 twt企业IT社区

twt企业IT社区

微信号 talkwithtrend

功能介绍 talkwithtrend.com社区（即twt社区）官方公众号，持续发布优秀社区原创内容。内容深度服务企业内各方向的架构师、运维主管、开发和运维工程师等IT专业岗位人群，让您时刻和国内企业IT同行保持信息同步。

收录于合集

【摘要】 在当前的云环境下，满足业务混合负载需求的多存储服务共存是当下主题，在存储架构选择方面，分布式和集中式两种架构各有优缺点，因为分布式架构更复杂，所以一般能用集中式解决的就无需考虑分布式，千万不要为了分布式而分布式。

【作者】邓毓， 江西农信运维技术经理

随着金融科技技术的飞速发展，当前银行信息系统业务负载的数据特征并非完全单一类型，而是呈现出混合的数据特征，需要应对多种IO类型的存储需求，包括高并发IO（交易）、高吞吐IO（分析）、普通文件存取IO（文件交互）、海量文件存取IO（对象交互）等。例如银行的信贷系统，通过手机银行等互联网渠道办理信贷业务时，有高并发、低时延的IO需求；通过信贷管理端在线统计分析信贷相关数据时，有高吞吐、高性能的IO需求；信贷系统和其他业务系统交互数据文件或者信贷系统各应用节点共享文件数据时，又有便捷可靠的文件存取IO需求；通过柜面等线下渠道办理信贷业务产生海量的影像文件时，还有海量小文件归档和调阅的IO需求。在对存储的需求上，越来越多的银行信息系统呈现出像信贷系统这样混合的负载需求，非某一类某一种存储（集中式或分布式块、文件或对象）能够完全满足。在当前的云环境下，满足业务混合负载需求的多存储服务共存是当下主题，在存储架构选择方面，分布式和集中式两种架构各有优缺点，因为分布式架构更复杂，所以一般能用集中式解决的就无需考虑分布式，千万不要为了分布式而分布式。下面以某银行真实业务负载为例，分类剖析其存储技术路线和方案的选择，旨在帮助读者结合企业实际业务负载需求进行合理的决策。

一、渠道 / 前台类业务

银行各类业务渠道非常多，是直面客户办理业务的信息系统，主要线下渠道包括柜面、ATM、POS、智能柜台等，主要线上渠道包括手机银行、网银、移动营销（平板）、微信营销、互联网金融等。

1）这两类渠道系统要么是间接为客户办理业务的柜员、POS收银员，要么是客户自己。所以在办理业务过程中，客户等待办理业务的时间或者自己的体验感非常重要，这就要求渠道系统自身的耗时要绝对小（业务办理的体验感是全链路的，渠道系统是业务链路最前面一个环节），在存储端需求表现为小IO但延时要求低，量级最好在毫秒以内。随着越来越多的渠道系统也开始上云，采取分布式存储却不是一个最佳的选择，因为采用通用X86带SSD盘，用软件搭建的分布式存储，即使其IO响应时间达到极致，无论如何也比不过现如今的全闪存储阵列，这是因为高端全闪采用了大量硬件加速IO，专用硬件的效率是软件所不能比拟的，因此建议云上这类对IO延迟严苛渠道系统数据库底层存储能用全闪最好。

2）针对高并发的渠道系统，如手机银行、互联网金融等，其他线下渠道受限于柜员、终端或客户端总数量，其TPS或者QPS会存在上限，并发需求的极限也是容易预测的，采用集中式全闪完全足够。而高并发渠道的业务TPS兼具爆发性和难以预测性，集中式架构越来越捉襟见肘，尤其是这类渠道系统如果采用单体集中式的数据库很容易就达到瓶颈，采用分布式数据库不可避免成为趋势。对存储需求而言，更多要求的是IOPS能力，所以目前而言分布式数据库+分布式存储是最佳组合。

3）即使是渠道类系统，也有业务管理的功能需求和文件共享需求，主要是报表查询、统计和分析，管理和应用文件系统共享等。在存储需求角度，这类业务管理IO是轻分析类型，数据特征为低IO吞吐，云环境下对接集中式存储或者采用底层为分布式存储的块存储服务均可，文件共享可以采用集中式NAS或者云上NAS服务。

二、平台 / 中台类业务

银行的业务平台类有两种，一种是共享服务平台类，对全行信息系统提供基础性服务，包括通讯、影像、公共业务和安全等内容，如ESB企业总线、影像平台、业务中台、安全中台等。另一种是业务产品平台，如信贷大平台、中间业务平台、支付平台、银行卡系统、电子银行平台、互联网能力中心等。

1）针对通讯及安全校验类服务平台，其数据库往往仅需提供配置的存取功能，通常是异步松耦合的架构，整体IOPS较小，对IO响应时间也不敏感，应用节点大量横向扩展满足TPS要求即可。因此存储端需求采用集中式存储或者云上普通块存储服务即可，有ESB文件FTP共享的需求的，可以采用云下或者云上NAS服务。

2）针对影像类服务平台，主要体现在影像数据库和影像文件本身的存储需求。影像数据库会存储影像与业务的关联关系，以及与影像文件的映射关系。业务大量接入影像平台后，海量的影像文件快速增长，对数据库的压力也陡然剧增，其数据访问特征是高IOPS小吞吐低延迟，站在存储的角度，分布式数据库+分布式存储较集中式数据库+集中式存储的架构更有远景优势。针对影像文件本身的存储选择，毋庸置疑选择云上或云下对象存储服务即可，传统NAS或者云上NAS服务在海量数据面前有着先天劣势。

3）针对业务产品平台，如信贷系统一样，其数据特征类型比较多，属于混合负载类型，因此需要结合各类需求，针对性地选择存储方案，如针对数据库既有高并发低延时需求，又有高吞吐高性能需求时，一方面数据库可以进行数据拆分，实时表和历史表要分库，实时库用集中式数据库+全闪组合，历史库用于统计查询和分析，则可考虑分布式数据库+存储的组合。另一方面新建系统的数据库可以直接采用当前比较火热的HTAP分布式数据库，同时高质量承担OLTP和OLAP的能力，但技术选型的要求和后续的运维成本会比较高昂。

三、管理 / 决策类业务

银行的管理决策类系统大多为业务数据存储、加工和分析型系统或平台，包括大数据平台（数据仓库）、数据集市、反洗钱、数据报送、财务管理、绩效考核、风险合规等等。

1）数据存储加工类平台数据特征为高吞吐高IOPS，目前技术也非常成熟，有采用云下Hadoop、ES、Kafka三大集群，也有采用云上专有大数据云服务，存储需求目前也是行业公认的分布式存储体系架构。

2）数据分析类系统对存储需求主要体现在数据库层面，单体实例的数据库目前来看，越来越捉襟见肘，一是单体实例计算能力达不到要求，二是单体实例下整体存储能力的瓶颈点比较多，包括操作系统磁盘和队列瓶颈，网络层面的带宽瓶颈，存储层面的IOPS瓶颈等，虽然有各类解决方案，但终归是按下葫芦起了瓢，尤其是面对实时性数据分析的需求时更加如此，因此分布式分析型数据库+分布式存储的方案才是最优解。

四、后台类业务

银行的后台系统一般称作核心系统，它是银行最基本的存贷款业务为主的系统，是其他业务子系统的基础。核心系统是交易处理系统，主要完成处理客户账务及内部账务的分户核算处理；同时核心系统也是会计处理系统，处理银行科目的清算核算。核心系统是银行最重要的系统，作为业务全链路过程中的最后一个环节，其数据特征是高IOPS低延迟需求。每日的日终批量又涉及复杂的批量逻辑和数据加工，数据特征是高吞吐高IOPS。目前有部分银行进行了新核心系统建设，将核心系统改造为分布式核心，以满足这些严苛的要求。也有大部分银行目前是保持现状，以大型机或高端小型机+高端存储阵列（全闪或者混闪）为主，一方面也是这些高端硬件的组合的确能够HOLD住这些需求，多年来运行也非常稳定，尤其是大型机和AS400的银行用户，内在外在因素驱动进行新核心系统建设的动力不是非常充足。另一方面这套传统架构在两地三中心的体系下非常完善，而分布式数据库+存储的组合，其两地三中心体系在银行案例中尚未成熟和经历历练。