银行数字化转型开年布局，金融级架构面临的6大挑战和应对思路
2021 年 12 月和 2022 年 1 月，两份关于银行数字化转型的重量级指导文件——中国人民银行的《金融科技发展规划（2022—2025 年）》（以下简称“发展规划”）和银保监会的《关于银行业保险业数字化转型的指导意见》（以下简称“指导意见”）先后印发，这对在积极筹备数字化转型工作的各类银行而言，正是 2022 年开年布局的最好指导。
值此之际，金融级IT架构的设计显得颇为重要，本文就来分享一下金融级IT架构面对的挑战和应对思路，希望对银行数字化转型的架构设计有所帮助！
金融机构大规模运用高端产品，在IT架构领域一直是高可靠、高标准、低风险的典范，IT投入也远超其他行业，早期主要采用集中式架构和高端硬件设备，在较长时间周期内有效地支持了存款、贷款、支付、结算、理财、外汇等业务的开展，信息技术已成为银行业经营发展的命脉。
在数字化时代的当下，金融需求出现了场景化、碎片化、多样化、长尾化、普惠化的新特点，百年未有的变化冲击着传统金融级IT架构。新金融级IT架构应该包含什么样的新能力，关键挑战是什么？应对思路又是如何的呢？
这里从多个方面进一步阐述金融级架构面临的诸多挑战，并结合网商银行信息科技多年来的发展经历给出一些应对思路。
挑战
挑战1：容灾
据Gartner（高德纳）分析报告显示，在大灾难事件发生之后，五分之二的企业再也不能恢复运作，三分之一的企业在两年内发生倒闭。
此外，据美国明尼苏达大学的研究发现，如果企业在发生灾难后两周内无法恢复业务系统，其中75%的企业会发生业务停顿，43%的企业再也无法重新开业，在遭遇灾难时没有灾难恢复计划的企业中，将有超过60%的企业在两到三年后退出市场。对金融行业而言，哪怕是极低的小概率自然灾害，也可能导致数据被破坏，影响业务连续性，如用户数据不能恢复，轻则机构停业，严重情况下可能导致机构破产。
银行核心应用系统（如账务）一般部署在主机平台上，使用小型机（一种介于PC服务器和大型机之间的高性能计算机，主要支持UNIX操作系统）构建，可用性高，运行稳定，但也存在风险集中、处理能力触达瓶颈后伸缩性不够、价格昂贵等问题，而具备同等计算能力的x86服务器价格虽然只有小型机的十几分之一，但稳定性不如小型机高，硬件故障率较高，诸如磁盘损坏、内存损坏这些问题较常见。
无论是基于小型机的集中式主机平台架构，还是使用x86处理器的分布式开放平台架构，是否具备应用级别的容灾能力直接决定了对客服务的稳定性。
挑战2：容量
这里的容量指的是单位时间内系统能吞吐的最大业务量，一个系统的吞吐量通常可以通过QPS（Queries Per Second，每秒查询率，是系统在规定时间内所处理查询流量多少的衡量标准）和TPS（Transactions Per Second，每秒传输的处理事务个数，即服务器每秒处理的事务数）来衡量。
每个系统的容量都有一个相对的极限值。伴随着业务的快速发展，系统处理的流量和数据量也在上涨，当系统达到容量上限时，系统的吞吐量就上不去了，如果业务流量继续上涨，系统的吞吐量不但不能维持高位，反而会快速下降，原因是超出系统容量后会导致系统超负荷工作，服务器的内存、CPU（Central Processing Unit，中央处理器）、网络、IO（Input/Output，输入/输出）、存储等出现瓶颈，导致系统性能下降，业务连续性得不到保障，进而妨碍业务的发展。
挑战3：成本
在应对海量用户和交易量时，需要确保较高水平的容灾能力和较大的容量以满足业务发展需要，这就需要在IT基础设施和前沿架构与技术上进行投入。而基础设施层面的投入巨大，投入成本需要是可控的，如果成本过高，会吞噬业务利润，伴随业务竞争的加剧，利润空间进一步下降，IT成本问题将越发凸显。部分银行单个账户涉及的IT成本少的几十元，多的达上百元，如果能将每个账户的IT成本降低到几元，甚至几角，在用户快速增长的过程中，规模效应会非常突出，银行无疑将获得巨大的竞争力。
由于金融行业对灾备的要求较高，灾备能力的建设往往会带来投入的增加，特别是数据中心的灾备能力建设。中大型银行以及部分互联网银行（包括网商银行），往往同时建设了同城和异地灾备数据中心，投资规模至少要一千万元，数据中心日常运行费用高，并且服务器每年存在折旧，几年后将超出保修期，故障率上升，必须汰换。如果这些数据中心不能最大程度上日常使用，而仅仅在灾难场景中启用，将会是巨大的资源闲置。
另外，业务运营活动往往会带来流量的急剧上涨，比如在“双11”大促（大型促销活动）期间，网商银行的系统峰值水平达到全年最高，但日常系统峰值水平要低很多，如果仅根据峰值水平简单地增加服务器规模，也会出现资源闲置。如何减少单笔交易的处理成本，获得稳定性、可靠性以及容量的支撑，需要一套良好的架构体系来实现，分布式、单元化、云计算、混合云、混合部署等架构的运用可以大幅提升成本控制和优化水平。
挑战4：安全
数字银行的业务性质决定了数字银行在安全方面必然面临巨大挑战：
安全威胁大。数字银行在线资产价值高，若黑客攻击成功则可能获得巨额收益，因此黑客愿意付出更大的成本来攻击数字银行。
防御难度高。数字银行对外暴露的攻击面更大，业务更新迭代的速度更快，因此防御难度更大。
需要兼顾安全和效率。在保证安全的同时，数字银行需要兼顾低成本和高效率的目标。
安全要求严格。金融行业是强监管行业，随着《网络安全法》《数据安全法》的出台，监管对网络安全和个人隐私信息保护的要求日趋严格。
金融业务中贷款、存款、转账、计息、清算和账务等业务和钱都密切相关，有着天然的安全诉求，也有着对应的高风险。不法分子以前是在现实中铤而走险抢银行，现在则是在网络上不露面就可以抢银行了。当利益足够大时，攻击也会足够强。若黑客攻击成功则可以获取巨额收益，这促使一些人在黑暗中默默观察，等待发出致命一击。同时，数字银行没有实体柜台，用户开户、登录、收钱、转账均通过APP在线上操作，完全暴露在互联网上，所以数字银行比传统银行的暴露面更大，整体的防御难度也更大。
挑战5：研发运维效率
在互联网金融背景下，业务快速迭代，发布频率高，如何在保障稳定性的前提下确保投产效率，保证业务需求快速落地，特别是保证核心业务全年零停机维护，挑战巨大。传统架构下的运维模式对应用版本发布与变更管控粒度过大，一般是选择机房级别变更，不能实现比机房级别粒度更小的变更，线上环境运维风险高，对系统稳定性、可靠性的保障难。
在新型互联网技术体系下，随着系统依赖的复杂度逐渐提升，底层基础设施的演进开始对上层业务研发产生影响，特别是在一些安全加固场景下，基础设施的升级往往对业务研发迭代产生极大的干扰，严重影响业务生产效率。
挑战6：技术风险防控
银行业的运营高度依赖信息系统，特别是像网商银行这样没有设立线下网点的互联网银行，业务开展完全依赖信息系统提供服务，系统资源和业务数据都依赖数据中心进行集中化处理，信息系统7天×24小时不间断运行，每时每刻都有可能发生故障，另外信息系统的运行也会受系统使用部门、运维保障部门、外部供应商（数据中心、网络、电力供应商）等的影响，同时也可能受地震、洪水、火灾等自然灾害影响，这对业务的连续经营带来极大的挑战。一旦出现信息系统自身故障或者数据中心故障，将会导致运营中断，出现业务停顿，如处置不当，可能会造成巨额经济损失。
另外，监管要求越来越严，业务经营透明度越来越高，社会各界对经营出现差错、服务不稳定的容忍度越来越低，所以运营中断还会诱发重大声誉风险和法律风险，极端情况下可能会诱发全行业的业务中断，所产生的损失难以预估。
随着分布式微服务架构和云计算的运用，无论是服务器、系统和服务规模，还是架构复杂度都在上升，同时，大量使用x86架构的PC服务器，硬件自身的可靠性也在下降，系统开发越来越快，业务变化频繁，业务复杂度高，用户多，并发性高，系统运行过程中的风险可能隐藏在某些“看不见，摸不着”的微小环节和部位，可能是一个运维端口，也可能是一条命令的下发通道，业务连续性保障难度也越来越大。
应对思路
随着移动互联网、云计算、大数据、社交网络等信息技术的蓬勃发展，互联网金融应运而生，促使银行业向互联网模式逐步转型。一个看似简单的愿景：“任何人在任何地点、任何时间、任何场景中，通过多种手段均可使用银行服务”，使得新一代的金融级系统必须直面海量用户，以及随之而来的海量交易与数据，从而面临着巨大的技术挑战。金融机构应该如何应对这些挑战呢？
目前国内一些互联网银行在应对新时代背景下的技术挑战积累了很多可以借鉴的经验。以网商银行为例，它从诞生之日起就是一家将核心系统架构在云上的银行，建成了基于云计算“基座”的分布式架构，逐步完成了“两地三中心”架构落地。在这基础之上，又开展了单元化“异地多活”架构、弹性架构、混合云架构、云原生架构的探索和实践。
图1描述了网商银行从云架构走向金融级云原生架构的三个阶段，通过技术架构升级，逐步应对信息系统在容量、稳定、安全、成本、合规、效能等多方面的挑战。
图1 网商银行三代架构发展历程
以下是网商银行在面临技术风险挑战时的一些应对思路：
01．微服务化
微服务指将大型复杂软件应用拆分成多个简单应用，每个简单应用描述着一个小业务，系统中的各个简单应用可被独立部署，各个应用之间是松耦合的，每个应用仅专注于完成一件任务并很好地完成该任务。
微服务实现了应用架构的细粒度变化，应用之间相互独立，服务之间相互解耦，变更周期不再联系在一起，可以有各自相对独立的变更计划。可以独立地对每个服务进行重启、升级改造、发布部署和增减服务节点等，频繁更新不会对用户产生影响。
与传统的集中式架构相比，微服务架构可以将系统的变更范围收窄，从而更好地管控技术风险。
- “异地多活”单元化
单元化是将一个系统的架构按某种数据特征维度进行单元划分。比如银行有1亿名用户，假如按照用户维度进行划分，则可以分成20个单元，每个单元存储500万名用户信息。每个单元是一个从流量层、应用层到数据层的完整、自治、独立的生态系统，能为用户提供绝大部分服务，数据访问都尽量封闭在这个单元内。
因此，可以将一个单元部署到任何地域，单元和单元之间能够互为备份，这为“多地多活”部署提供了可能。通过异地多活架构部署，大幅提升了金融机构面临城市级别故障时的风险应对能力。
- 弹性架构
考虑到单个数据中心承载的服务器规模有限，当业务发展过快时，现有的数据中心承载不了增加的服务器，还需要建设新的数据中心，而数据中心的建设周期更长，从规划到投产长达一年以上，在这期间如果业务发生变化了，重新调整也是非常困难的。因此，需要一种灵活、快速、低成本地应对突发的或者周期性的业务流量洪峰的新架构。
以网商银行的弹性架构为例，本质上是以单元化架构为基础实现业务级别的弹性伸缩，这种架构不仅提升了业务需求响应速度，不用操心软硬件资源的额外成本（闲置成本），降低了IT成本，更关键的是当业务规模面临海量突发性扩张的时候，能不再因为平时软硬件资源储备不足而“说不”，有效地提升了IT基础设施的灵活性，保障了业务快速发展。
- 云计算
云计算能够实现对IT资源的动态调配，提升和简化IT管理，把IT资源作为标准化服务呈现出来，让使用者像用水、用电、用气那样消费IT资源。银行业是技术高敏感行业，每次重大技术创新都会对其运作模式产生影响。
对CIO而言，云计算可以让其将更多精力集中在满足业务需求、新业务探索、新技术跟踪等领域，完成从Chief Information Officer到Chief Innovation Officer的转变。
- 云原生
面向互联网的数字银行IT系统设计趋于复杂，微服务的数量也呈指数级增长，在业务需求快速变化，上线速度、投产频率要求越来越高的情况下，金融核心组件的抽象是一个大趋势，中台化架构已经逐渐成为新一代软件系统集成模式的重要方向，在强调业务核心组件复用能力的同时，如何保证业务系统迭代的效率是需要解决的迫切问题，而传统的运维模式支撑如此大规模的分布式服务变得越发艰难。
云原生技术带来了更高层次的基础设施抽象，让研发的关注点从基础设施进一步分离，聚焦于上层业务逻辑实现，基础设施能力下沉后具备独立演进能力，可实现业务低成本安全加固，降低业务风险。
- 安全架构
为应对数字银行安全威胁大、防御难度高、安全要求严格的挑战，需要将安全风险的发生概率降到最低，甚至安全风险零发生。传统金融企业要保证安全风险零发生，一般是通过管理手段和技术能力相结合的方式，其中管理手段较为严格，部分管控措施可能会在一定程度上降低工作效率。
例如，银行员工为了控制风险而需要不断切换办公设备和办公场所，来做本应是连贯性的工作。数字银行安全架构建设的目标不仅包括安全风险零发生，还需要达到数字化和互联网模式的生产效率。因此需要更多的技术投入，采用更加技术化的方案和创新机制来达成高安全性和高效率的双重目标。具体的应对思路包括两方面：
一是通过技术方案达成高安全性的目标，通过实现默认安全机制和可信级纵深防御来实现，并依靠实战演练检验安全体系的有效性。
二是提升安全工作的效率，以保证整体生产效率。为了达成默认安全机制和可信级的纵深防御，需要在服务更新上线前进行高频的安全评估和分析工作，带来巨大的工作量，如果不能高效完成，必然会影响整体的生产效率。因此，需要让所有的安全评估和分析工作都首先在线化和数字化，然后进一步自动化和智能化。
07．技术风险防控
应对信息科技风险挑战需建立健全内部防控体系，通过管理措施和技术能力，消除风险隐患，及时处置运行故障，快速“止血”恢复业务，提升风险防护能力，保证信息系统高可用和资金安全，保障业务连续性。以网商银行为例，该行构筑了以信息科技部门、风险管理部门、审计部门为主体的信息科技风险管理三道防线，共同防范和控制信息科技风险，如图2所示。
图2 技术风险防控体系
整个技术风险防控体系的可以从以下几个点进行思考：
（1） 在组织和文化上进行建设，从顶层架构设计出发，建立职责明确的技术风险防控管理组织架构，明确技术风险防控管理策略和制度，加强技术风险防控资源配备，增强技术人员对风险的敬畏意识，营造技术风险防控管理文化，促进技术风险防控水平的整体提升。
（2）在组织结构设计上，成立风险技术红队和业务技术蓝队，进行红蓝攻防演习，每年在约定时间段或不提前通知开展真实化、常态化的应急演练，进一步提升应急处置能力。
（3）为应对地震、洪涝等自然灾害，以及运营商网络或者电力网络不可用等基础设施故障，还需要建设全局容灾能力。全局容灾能力需要在常态化、周期性的容灾演习中不断打磨、完善、升级和“保鲜”，按月度制定全局容灾演习计划，基本保持每月至少一次的生产环境数据中心非断网和断网场景中的应急恢复演练。
（4）建立严格的变更管控制度，指导原则是“变更三板斧”：可观测、可“灰度”、可应急。
（5）做好资损“防”与“控”，“防”需要从产品设计、产品实现、人工操作三类不同的问题来源进行分类预防。“控”需要做好各项预案设计，当问题触发时能通过预案及时做好止损，控制影响面进一步扩大，同时尽可能消除影响。
本文节选自《金融级IT架构》一书，欢迎阅读此书了解更多相关内容！
▊《金融级IT架构：数字银行的云原生架构解密》
网商银行技术编委会 著
架构书中的“战斗机”！
引领数字化时代金融级别的IT架构发展方向
书中阐述的核心技术荣获“银行科技发展奖”
网商银行IT技术架构演进实践精华
本书介绍了网商银行成立至今的IT技术架构演进路线，涵盖了分布式、单元化、弹性混合云、云原生多个基础架构领域，同时介绍了技术风险、安全可信、业务架构等多方面的技术实践经验，我们希望和读者分享网商银行在金融级IT技术上做的独特探索，跟大家探讨数字化时代金融级IT架构的发展方向。
（扫码了解本书详情！）