金融机构架构面临的挑战

本文涉及的产品
对象存储 OSS,标准 - 本地冗余存储 20GB 3个月
文件存储 NAS,50GB 3个月
对象存储 OSS,恶意文件检测 1000次 1年
简介: 新一代信息技术推动金融行业数字化转型,银行通过微服务、云计算等构建高可用、高性能的技术体系。容灾作为关键环节,涵盖数据、应用与业务三级,强调RTO/RPO指标及“两地三中心”向“多活中心”演进,提升业务连续性与抗灾能力。

以云计算、大数据、人工智能、区块链等为代表的新一代技术已经崛起,不断向金融领域渗透、银行也通过信息科技转型、数字化来应对挑战,保持传统金融行业“高可用、高标准、低风险”特性的同时,也增加了互联网金融对“高性能、高弹性、低成本”方面的要求。

经过多年的发展和演进,走出了一条解决海量数据存储、计算以及应对高并发交易的道路,通过微服务分布式架构、云计算和大数据等技术构建了一套能满足业务发展要求的技术体系。

1.1 容灾

在系统高可用架构设计中,容灾能力的建设不可或缺,容灾设计强调的是系统对灾难时间具备快速响应能力,保障系统持续高可用,系统面对异常情况,如软硬件自身故障,外界环境影响(自然灾害)需具备快速恢复能力,保障系统的持续高可用。

衡量灾难恢复能力的级别有两个技术指标,RPO(Recovery Point Objective,恢复点目标)和RTO(Recovery Time Objective,恢复时间目标)。RPO用于表示灾难发生后,系统和数据必须恢复到的时间点要求。RTO用于表示灾难发生后,信息系统或业务功能从停顿到必须恢复的时间要求。RPO和RTO与灾难恢复能力登记的关系与时间有着密切的联系。

容灾方案须满足3个要素:①应用和数据都具有冗余性②冗余备份位于距离较远的物理位置③数据备份系统具备全方位的数据复制能力。

容灾从保护等级上划分可以分为3个级别,分别是数据级别、应用级别及业务级别,三者的关系可以用3个嵌套的同心圆表述,业务恢复等级逐步提高,需要投资的费用也会相应增加。

1.1.1 数据容灾

可靠的容灾能力除了应用、数据都具有冗余性外,还需要确保备份在物理上具有长距离性(上百千米以上)。可以的容灾能力需要具备全方位的数据复制能力。

1.1.2 应用容灾

应用容灾在数据容灾纸上,建立一套与生产系统相当的备份应用系统,在灾难发生后,将应用迅速切换到备用系统,备份系统承担生产系统的业务运行,其核心关注点是连续的应用服务,是在数据容灾的基础上,把应用系统也备份到容灾站点。应用容灾和数据容灾最大的区别是在生产中心发生灾难时,灾备中心是否具备接管中心的业务的能力,能否保障业务的连续性。应用容灾确保系统能提供可持续的服务,当灾难发生时,让用户的服务请求能够透明地持续正常处理,保证信息系统提供完整、可靠、安全的服务。

银行核心应用系统(如账务)一般部署在主机平台上,使用小型机(一种介于PC服务器和大型机之间的高性能计算机,主要支持UNIX操作系统)构建,可用性高,运行稳定,但也存在风险集中、处理能力触达瓶颈后伸缩性不够、价格昂贵等问题。

1.1.3 业务容灾

业务容灾是最高级别的容灾方案,数据容灾和应用容灾都是在IT范畴之内,而业务容灾除了做到数据和应用的容灾外,还需要确保非IT系统的连续性,比如电话、办公地点等。

1.1.4 部署结构

以“同城双中心”(生产中心、同城灾备中心)和异地灾备中心组成“两地三中心”的部署结构可以支撑较高的业务连续性保障水平。该结构可解决单机房在电力、面积等方面的限制,规避数据中心所在楼宇发生的灾难、地域性自然灾害和人为破坏(如网络光纤被挖断)等导致的数据中心故障风险。

传统的“两地三中心”部署结构并不能很好地应对“同城双中心”同时发生故障的情况,当进行异地灾备中心切换时,数据同步到异地灾备中心的过程存在延迟,即RPO不等于0。

在实践过程中,当发生城市级别故障时,在同城两个数据中心都不可用的情况下,企业往往不敢切换到异地灾备中心,而是等待“同城双中心”故障恢复,忍受一段服务不可用时间。

有别于“两地三中心”,“多活中心”的部署结构在少数数据中心发生故障或灾难时,其余每个数据中心都可以正常处理业务并对关键业务或全部业务实现接管,实现用户的“故障无感知”,多数据中心之间地位是均等的,已无“主备”之分,在正常模式下协同工作,并行为业务访问提供服务,实现对资源的充分利用,避免了个别数据处于限制状态,造成资源浪费。但要实现“多活”数据中心的架构需要解决流量调配、数据拆分、时延等方面的问题,挑战巨大。



目录
相关文章
|
1月前
|
监控 JavaScript 编译器
从“天书”到源码:HarmonyOS NEXT 崩溃堆栈解析实战指南
本文详解如何利用 hiAppEvent 监控并获取 sourcemap、debug so 等核心产物,剖析了 hstack 工具如何将混淆的 Native 与 ArkTS 堆栈还原为源码,助力开发者掌握异常分析方法,提升应用稳定性。
381 39
|
27天前
|
机器学习/深度学习 人工智能 搜索推荐
Thinking Machines Lab最新研究结果如何复现?On-Policy Distillation让训练成本直降10倍
Thinking Machines Lab提出On-Policy Distillation技术,让小模型高效继承大模型能力。相比传统强化学习,训练成本降低90%,效率提升十倍,支持本地部署、降低成本与延迟。结合vLLM加速与独立DeepSpeed配置,MS-SWIFT框架实现开箱即用的高效蒸馏训练,助力轻量模型具备“会思考、能纠错、可进化”的智能。
252 10
|
30天前
|
负载均衡 Java API
《服务治理》RPC详解与实践
RPC是微服务架构的核心技术,实现高效远程调用,具备位置透明、协议统一、高性能及完善的服务治理能力。本文深入讲解Dubbo实践,涵盖架构原理、高级特性、服务治理与生产最佳实践,助力构建稳定可扩展的分布式系统。(238字)
|
1月前
|
人工智能 自然语言处理 算法
【2025云栖大会】AI 搜索智能探索:揭秘如何让搜索“有大脑”
2025云栖大会上,阿里云高级技术专家徐光伟在云栖大会揭秘 Agentic Search 技术,涵盖低维向量模型、多模态检索、NL2SQL及DeepSearch/Research智能体系统。未来,“AI搜索已从‘信息匹配’迈向‘智能决策’,阿里云将持续通过技术创新与产品化能力,为企业构建下一代智能信息获取系统。”
299 9
|
28天前
|
存储 前端开发 Java
基于Spring AI Alibaba 的 DeepResearch 架构与实践
基于SpringAI Alibaba Graph构建的Java版DeepResearch系统,实现信息搜集、分析到结构化报告生成的全自动流程。支持多轮推理、RAG检索、MCP扩展、可观测性及可溯源输出,集成主流搜索工具与多种数据源,具备高可扩展性与企业级应用能力。
基于Spring AI Alibaba 的 DeepResearch 架构与实践
|
23天前
|
存储 算法 Java
深入理解JVM:内存管理与垃圾回收机制探索
JVM是Java程序的运行核心,实现跨平台、自动内存管理与高效执行。其架构包括类加载、运行时数据区、执行引擎等模块。内存模型历经演变,JDK 8起以元空间替代永久代,优化GC性能。JVM通过分代回收机制,结合标记清除、复制、整理等算法,管理对象生命周期,提升系统稳定性与性能。
|
28天前
|
消息中间件 人工智能 Apache
阿里云两大 AI 原生实践荣获 2025 年度 OSCAR “开源+”典型案例
恭喜阿里云微服务引擎 MSE、Apache RocketMQ for AI 获权威认可!
191 16
|
1月前
|
数据采集 存储 人工智能
从0到1:天猫AI测试用例生成的实践与突破
本文系统阐述了天猫技术团队在AI赋能测试领域的深度实践与探索,讲述了智能测试用例生成的落地路径。
从0到1:天猫AI测试用例生成的实践与突破