《云上容灾交付服务白皮书》——2.容灾技术架构——1.3 行业容灾现状分析(上)

简介: 《云上容灾交付服务白皮书》——2.容灾技术架构——1.3 行业容灾现状分析(上)

在国家政策引导及数字化转型的大趋势下,我国的各主要行业根据自身业务特点及需求来规划容灾建设步伐,并以稳健而有序的方式推进。同时,随着业务的发展及整合,核心业务系统承担了更多更重要的责任,对业务连续性要求也更高。因系统集中而带来的风险集中就越发突出,如何防范就变得尤为重要。公共行业涉及国计民生,其中金融和医保两个行业尤其受到国家和公众的关注,因此本文将重点围绕这两个行业进行分析。


1.3.1 金融行业

行业规范性要求


无论是传统金融业,还是步入新模式的现代金融业,均与科技创新有着密不可分联系。一方面,科技创新的过程在不断放大资金的需求;另一方面,科技创新的成果运用到金融业务后,会显著提升金融服务的质量和效率。


金融行业有着极高的业务连续性要求,在高速发展中对 IT 系统的信息化、数据安全的依赖越来越高,对于保护信息系统免受自然灾害、物理损坏、人为故障等的挑战也越来越高。


我国政府及金融监管机构历来高度重视金融行业安全稳定运行及发展,出台一系列标准及规范以促进金融行业的灾备建设,如下:


《网上银行信息系统安全通用规范》(JR/T 0068-2020)

《云计算技术金融应用规范 容灾》(JR/T 0168-2018)

《金融行业信息系统信息安全等级保护实施指引》(JR/T 0071-2012)

《商业银行数据中心监管指引》(银监办发 [2010] 114 号)

《银行业信息系统灾难恢复管理规范》(JR/T 0044-2008)


其中,JR/T 0168-2018 由中国人民银行制定并于 2018 年 8 月 15 日实施,是云计算技术金融应用规范的系列标准之一。该标准规定了金融领域云计算平台的容灾要求,包括云计算平台容灾能力分级、灾难恢复预案与演练、组织管理、监控管理等内容。在遵循 GB/T 20988-2007 标准的基础上,该标准针对金融行业特点,更新定义了 4 个容灾等级和 4 个能力要素,是指导金融行业容灾建设的核心标准。其中,容灾等级 3 级并未对异地机房有强制要求。从容灾等级 4 级开始,建议异地具备相应的数据处理及备份能力,这是异地容灾的需求来源。同时,建议在异地可用区具备灾难恢复所需的全部备用数据处理能力,并处于就绪状态或运行状态。这项能力在实际落地时会存在一定的时间周期,即分阶段实现。


JR/T 0168-2018 中对容灾等级进行了定义,其中的关键指标如下:


RTO:恢复时间目标(recovery time object),指灾难发生后,信息系统或业务功能从停顿到必须恢复的时间要求。


RPO:恢复点目标(recovery point object),指灾难发生后,系统和数据必须恢复到的时间点要求。


image.png

表 1-1 应用于金融领域的云计算平台容灾能力等级关键指标要求


由于大部分项目的容灾等级在 4 级及以上,本文以金融行业常见的 4/5/6 级为例,其核心技术要求如下:


同城和异地均需提供数据灾备能力

同城和异地均需部署同等能力的网络及数据处理能力

应用系统具备高可用能力

具备自动或集中式切换能力

至少每年进行一次相关预案的更新和演练



因此,金融行业尤其是银行机构,通常会将容灾目标等级定位为 5 级,并将“两地三中心”作为目标架构。“两地三中心”可理解为同城双机房和异地灾备机房组合,即在同城可抵御单机房故障,又可利用异地机房抵御地域级灾难。同城机房通常选择在几十公里内,异地机房则要求是数百公里外,需要避开同一地震、同一电网及同一江河流域。


容灾建设现状分析


金融行业中,银行机构的容灾建设进度是最快的。早在 2002 年左右,国内大中型商业银行普遍开展了容灾体系建设。随着银监办发 [2010] 114 号《商业银行数据中心监管指引》中明确提出了灾备中心建设模式及建设时间,更进一步促进了容灾体系建设。


目前,在我国 4000 多家商业银行中,无论是大型国有商业银行、股份制银行、城商行,还是农商行,有相当比例的银行已经建设或正在建设容灾基础设施。


特别要提到的是城商行和农商行,虽然自身规模相对有限,但很多银行在容灾建设上不遗余力。考虑到业务范围、建设成本及资源利用率的因素,多数城商行或农商行会首选同城容灾,业务上以互联网金融应用作为优先试点对象;而部分城商行或农商行已经开始两地三中心或多地多中心的建设。同时,这些银行对于云计算及云化基础设施用于容灾建设的方向,也在做积极的探索和实践,利用云计算为金融服务、为容灾建设服务已成为大趋势。


《云上容灾交付服务白皮书》——2.容灾技术架构——1.3 行业容灾现状分析(下):https://developer.aliyun.com/article/1229971?groupCode=supportservice


相关文章
|
8月前
|
人工智能 API 数据安全/隐私保护
Apifox 与 Apipost 的 API 文档引擎对比:底层架构、性能与可扩展性分析
深入探索市场上两大主流API工具——Apifox和Apipost的文档能力时,发现了令人惊讶的差距。这不仅仅是功能多寡的问题,更关乎开发效率与团队协作的质变。
|
5月前
|
Java API 开发工具
灵码产品演示:软件工程架构分析
本演示展示灵码对复杂软件项目的架构分析与文档生成能力。通过Qwen3模型,结合PlantUML,自动生成系统架构图、微服务时序图,并提取API接口文档,实现高效、智能的代码理解与文档输出。
337 5
|
5月前
|
存储 JSON 数据处理
ClkLog埋点与用户行为分析系统:架构升级与性能全面提升
随着越来越多企业在实际业务中使用 ClkLog,数据规模和分析需求也不断提升,部分用户日活已经超过10万,为了顺应这一趋势,ClkLog 秉持 “开放透明、持续演进”的理念,推出了迄今为止最重要的一次性能优化升级。新版本在大规模数据处理与复杂查询场景中,性能表现实现了跨越式提升。经过多轮研发与严格测试,新版本现已正式上线:在原有付费版 1.0 的基础上架构全面升级,并同步发布全新的 2.0 版本。为用户带来更强的性能与更广的适用场景。
|
9月前
|
机器学习/深度学习 人工智能 算法
大型多模态推理模型技术演进综述:从模块化架构到原生推理能力的综合分析
该研究系统梳理了大型多模态推理模型(LMRMs)的技术发展,从早期模块化架构到统一的语言中心框架,提出原生LMRMs(N-LMRMs)的前沿概念。论文划分三个技术演进阶段及一个前瞻性范式,深入探讨关键挑战与评估基准,为构建复杂动态环境中的稳健AI系统提供理论框架。未来方向聚焦全模态泛化、深度推理与智能体行为,推动跨模态融合与自主交互能力的发展。
772 13
大型多模态推理模型技术演进综述:从模块化架构到原生推理能力的综合分析
|
6月前
|
存储 前端开发 JavaScript
如何开发设备管理系统中的经验分析报表板块 ?(附架构图+流程图+代码参考)
设备管理系统(EMS)助力企业高效管理设备生命周期,涵盖采购、维护到报废全流程。本文详解经验分析报表模块设计与开发,涵盖动态看板、点检、巡检、维修、保养及库存统计功能,提供代码示例与架构设计建议,提升设备管理效率与决策水平。
|
8月前
|
运维 监控 数据可视化
一文详解:工业软件“低代码开发平台”技术架构研究与分析
本文围绕工业软件低代码开发平台的机遇与挑战,提出基于自动化引擎的技术架构,由工具链、引擎库、模型库、组件库、工业数据网关和应用门户组成。文章分析了其在快速开发、传统系统升级中的应用模式及价值,如缩短创新周期、降低试错成本、解决资源缺乏和提升创新可复制性,为我国工业软件产业发展提供参考和支持。
|
8月前
|
负载均衡 Java API
基于 Spring Cloud 的微服务架构分析
Spring Cloud 是一个基于 Spring Boot 的微服务框架,提供全套分布式系统解决方案。它整合了 Netflix、Zookeeper 等成熟技术,通过简化配置和开发流程,支持服务发现(Eureka)、负载均衡(Ribbon)、断路器(Hystrix)、API网关(Zuul)、配置管理(Config)等功能。此外,Spring Cloud 还兼容 Nacos、Consul、Etcd 等注册中心,满足不同场景需求。其核心组件如 Feign 和 Stream,进一步增强了服务调用与消息处理能力,为开发者提供了一站式微服务开发工具包。
747 0
|
4月前
|
Cloud Native Serverless API
微服务架构实战指南:从单体应用到云原生的蜕变之路
🌟蒋星熠Jaxonic,代码为舟的星际旅人。深耕微服务架构,擅以DDD拆分服务、构建高可用通信与治理体系。分享从单体到云原生的实战经验,探索技术演进的无限可能。
微服务架构实战指南:从单体应用到云原生的蜕变之路
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。