银行技术架构概述

摘要：本文主要介绍作为支撑应用和数据技术基础的技术架构概述，包括介绍银行技术架构的内容，CAP原理和银行IT系统分类等内容。

技术架构是支撑应用和数据的技术基础，其领域涵盖应用及数据服务所需要的技术 组件、技术平台，以及支持开发、运维所需要的环境工具、技术能力等。在银行信息系统架构规划中，技术架构具体体现为支撑数据快速、安全传输的网络基础环境，保障应用及数据稳定、高效运行的计算和存储资源，适应应用需求灵活、通用的基础软件，以及为保障业务连续性所进行灾备设计等内容。

1.技术架构的内容

（1）传统技术架构的构成

按照企业架构的方法论，技术架构被描述为底层支撑、“业务无关”的IT基础架构(InfTastructure )。传统上，技术架构可以用企业技术框架(Enterprise Technology Framework, ETF)来表示。

ETF包含结构化、按层次分组的一系列组件。一般说来，不同的企业其应用及数据 可能差异较大，但是其技术架构可能存在一定的相似性。一个银行的典型ETF包括以下几类：平台服务(Platform Services)、网络服务(Network Services)、公共系统服务 (Common System Services) 、接入渠道(Channels)、接口服务(Interface Services)、 安全服务(Security Services)、系统管理服务(System Management Services) 测试和开发 服务(Test and Development Services)。

（2）云环境下的技术架构构成

随着云计算的广泛应用，传统技术架构设计也需要与时俱进，按照云计算的思想方 法来进行改进。云数据中心(Cloud Enabled Data Center, CEDC)代表着银行数据中心的未来。岀于安全性和监管要求等方面的考虑，银行的技术架构应该以私有云(Private Cloud)为主，结合部分公有云(Public Cloud),构建混合云(Hybrid Cloud)。在构建云化的数据中心时，一个重要的原则是面向服务的架构(Service Oriented Architecture, S0A)。SOA最初是软件系统设计和开发的重要原则，但现在已经成为包括云在内的IT系 统建设的普遍原则。相对于以前的架构设计，SOA更加强调面向服务、松耦合及标准化。

目前，业界通用的云服务模型分四层:IaaS (基础设施即服务)、PaaS (平台即服 务)、SaaS (软件即服务)及BPaaS (业务流程即服务)。从云的角度来看，技术架构会涉及IaaS及PaaS的部分内容。IaaS层由服务器、存储系统、网络、操作系统、系统管理及系统软件组成，而PaaS层包括交易中间件、应用服务器中间件、消息传输中间件、数据库等基础软件。

2.CAP 原理

2010年3月，美国加州大学伯克利分校的Eric Brewer教授提出了CAP原理。CAP是指任何一个分布式系统都包含三个最重要的属性：一致性 (Consistency),是指在分布式环境中，多 点读岀的数据是否相容；可用性(Availa・ bility),是指是否能够及时获得数据；分区容忍性(Partition Tolerance ),是指数据的 分区特性对系统性能的影响程度。CAP原理指的是，这三个要素最多只能同时实现两点，不可能三者兼顾。因此，在进行分布式架构设计时，必须在CAP三者之间进行取舍，由此导致了不同的应用场景需要采用不同的系统架构。例如，银行的核心交易系统和互联网类的Web应用系统就是两个差异非常大的典型应用场景。

交易系统对于ACID ( Atomicity, Consistency, Isolation, Durability)有着严格的要求。这类系统一般采用数据库集群技术来实现。

而互联网类的应用一般采用BASE (Basic Available, Soft-state, Eventual consistency) 的策略。也就是说，对于大多数互联网应用，其实并不需要像关系型数据库那样的强一致性，而是只要系统能达到最终一致性即可。因此互联网应用一般通过大规模的多节点 并行处理，牺牲一致性而换取高可用性。

3.银行IT系统分类

（1）按照系统的重要程度和时间敏感性分类

在设计银行总体技术架构时，从非功能性需求角度来看，可以按照《银行业信息 系统灾难恢复管理规范》的要求，根据风险分析、业务功能分析和业务中断影响分析 的结论，将信息系统按重要程度和时间敏感性分成三类。

第一类系统：是指短时间中断将对国家、外部机构和社会产生重大影响的系统；短 时间中断将严重影响单位关键业务功能并造成重大经济损失的系统；单位和用户对系统短时间中断不能容忍的系统。

第二类系统：是指短时间中断将影响单位部分关键业务功能并造成较大经济损失的 系统；单位和用户对系统短时间中断具有一定容忍度的系统。

第三类系统：是指短时间中断将影响单位非关键业务功能并造成一定经济损失的系 统；业务功能容许一段时间中断的系统。

大多数银行会把核心银行、信用卡、关键渠道服务、企业服务总线(ESB)等系统划归到第一类系统；把外围系统，如客服中心授权及历史交易查询等系统划归到第二类系统；把分析、管理系统，如数据仓库、风险管理及绩效考核系统等划归到第三类系统。这三类系统的非功能性需求是不一样的，在进行技术架构设计时，应该根据不同类别系统的特点，选择其相应的技术架构。

（2）按照系统的特点与作用分类

随着互联网时代的到来，按照系统的特点与作用，又产生了一种新的分类方法，可 以将银行的信息系统分为：互动参与系统(Systems of Engagement),特指渠道交互类应用，帮助提升客户体验的系统；分析洞察系统(Systems of Insight),特指统计分析处理类应用，帮助提升银行精细化营销和决策支持的系统；记录交易系统(Systems of Record),特指传统的联机交易和批量类应用，是实现银行最基本、最关键的账务处理的系统。

对应于前面提到的CAP原理，互动参与系统及分析洞察系统可以采用互联网架构, 从非功能需求上看，需侧重弹性、可扩展特性，来满足系统负载难以预知的变化，可通过横向扩展P以获得A,同时弱化C；而记录交易系统对高性能、可用性、安全性等有着非常严格的要求，必须满足交易的完整性及数据的一致性，故必须在保证C的前提下满足A, —般采用纵向扩展而不是横向扩展的架构。相信这种分类方法在未来随着互联网技术的广泛应用将会被越来越多的使用。

---

说明：（1）文中的配图大多来自互联网上授权图片提供商，并已获得免费使用授权，如果文中内容或是图片侵犯到您的权益，请及时告诉我。（2）本文主要内容来自王汉民等著由机械工业出版社出版的《银行信息系统架构》一书，本文主要目的是学习金融行业知识，如果您想了解更多内容，请购买原版图书。如果文中内容侵犯到您的权益，请及时告诉我。

文章来源: https://www.toutiao.com/group/6685727624574009860/