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

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

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



1.3.2 医保行业行业规范性要求

国家医疗保障局于 2018 年 5 月 31 日成立。同年 8 月,国家医疗保障局“三定方案”正式出炉,统筹推进“ 三医联动 ”改革。2019 年国家医疗保障局领导在全国医疗保障信息化试点启动会上提出了“全系统要凝心聚力,攻坚克难,建设全国统一的医保信息系统”。从此,医保信息化建设的大幕也徐徐拉开。整体上,医保信息化建设遵从


“一二三四五”原则,如下:


一个系统:全国统一医保信息系统

两种模式:省级集中部署和省市两级部署两种模式

三项约束:强约束、基础约束、弱约束

四类应用: 公共服务、经办管理类、智能监控类、宏观决策类

五项建设: 标准规范体系建设、平台及数据能力建设、数据中心建设、容灾备份建设、网络安全建设


在国家医疗保障局的统一领导下,国家医疗保障局网络安全和信息化领导小组办公室完成了诸多技术规范的制定,用于指导各省市医保系统信息化的建设,如下:


《医疗保障信息平台 数据库设计规范》(YB-XJ-E01-2020)

《医疗保障信息平台 定点医药机构接口规范》(YB-XJ-K01-2020)

《医疗保障信息平台 应用系统技术架构规范》(YB-XJ-B01-2019)

《医疗保障信息平台 电子凭证技术规范》(YB-XJ-D01-2019)

《医疗保障信息平台 云计算平台规范》(YB-XJ-A01-2019)


其中,XJ-A01-2019 规定了医疗保障信息平台建设总体技术架构,给出了业务子系统应用架构分层设计、核心服务框架和云平台适配框架设计说明,明确了建立省级双数据中心,互为容灾的架构,为全国各省提供了统一化标准化的灾备建设目标。


容灾建设现状分析

医保系统关系到国计民生,是国家关键基础设施,必须是稳健可靠的,因此容灾建设成为必不可少的一环。


根据国家医保局在医保平台建设指南中对灾备系统建设指导意见:灾备系统的验收目标是实现业务系统持续运行。当遇到不可阻挡或不可预知的灾难时,能实现数据层和业务应用层的灾备系统快速切换,最大限度地减少或避免故障造成的经济损失及社会影响。按照 GB/T 20988-2007,医保系统容灾等级应不低于(含)第 5 等级。


根据 YB-XJ-A01-2019 中的总体原则及要求,各省开展建立省级双数据中心,并行运行、互为容灾,可进行生产维护、日常操作等工作。两个数据中心(数据中心 A、数据中心 B)总体设计保持一致。同时,根据 GB/T 22240-2020 中的三级要求,结合医疗保障业务的实际情况,将数据中心进行网络区域划分。


数据中心的总体安全域,可划分为基于双链路的核心业务区、基于互联网应用的公共服务区以及核心业务区与公共服务区之间的安全隔离区。在技术实现上,医保云平台建设模式采用公共服务区 + 核心业务区,分别归属两朵独立的云,其架构特点如下:


公共服务区和核心业务区,分别建设一朵云,每朵云都是跨越数据中心 A 和数据中心 B 部署。

公共服务区对接互联网,核心业务区对接医保专网、电子政务外网、银行 / 税务等第三方渠道系统的接入。

数据中心 A 和数据中心 B 中心均提供证书授权中心(CA,certificate authority)以及安全管理区。

通过网闸系统控制公共区与核心区之间的相互访问,数据中心 A 和数据中心 B 的网闸地址通常是不相同的。


image.png图 1-1 医疗保障信息平台网络架构




截止到 2022 年初,全国已经有多个省份完成了容灾建设,具备了一定的保护医保基础设施及抵御灾难的能力,将来会持续为医保业务保驾护航。在未来的医保容灾建设中,可以从提升容灾等级以及优化应用服务模式上持续演进,更好地满足业务连续性要求。

相关文章
|
8月前
|
人工智能 API 数据安全/隐私保护
Apifox 与 Apipost 的 API 文档引擎对比:底层架构、性能与可扩展性分析
深入探索市场上两大主流API工具——Apifox和Apipost的文档能力时,发现了令人惊讶的差距。这不仅仅是功能多寡的问题,更关乎开发效率与团队协作的质变。
|
5月前
|
Java API 开发工具
灵码产品演示:软件工程架构分析
本演示展示灵码对复杂软件项目的架构分析与文档生成能力。通过Qwen3模型,结合PlantUML,自动生成系统架构图、微服务时序图,并提取API接口文档,实现高效、智能的代码理解与文档输出。
327 6
|
5月前
|
存储 JSON 数据处理
ClkLog埋点与用户行为分析系统:架构升级与性能全面提升
随着越来越多企业在实际业务中使用 ClkLog,数据规模和分析需求也不断提升,部分用户日活已经超过10万,为了顺应这一趋势,ClkLog 秉持 “开放透明、持续演进”的理念,推出了迄今为止最重要的一次性能优化升级。新版本在大规模数据处理与复杂查询场景中,性能表现实现了跨越式提升。经过多轮研发与严格测试,新版本现已正式上线:在原有付费版 1.0 的基础上架构全面升级,并同步发布全新的 2.0 版本。为用户带来更强的性能与更广的适用场景。
|
9月前
|
机器学习/深度学习 人工智能 算法
大型多模态推理模型技术演进综述:从模块化架构到原生推理能力的综合分析
该研究系统梳理了大型多模态推理模型(LMRMs)的技术发展,从早期模块化架构到统一的语言中心框架,提出原生LMRMs(N-LMRMs)的前沿概念。论文划分三个技术演进阶段及一个前瞻性范式,深入探讨关键挑战与评估基准,为构建复杂动态环境中的稳健AI系统提供理论框架。未来方向聚焦全模态泛化、深度推理与智能体行为,推动跨模态融合与自主交互能力的发展。
756 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,进一步增强了服务调用与消息处理能力,为开发者提供了一站式微服务开发工具包。
737 0
|
4月前
|
Cloud Native Serverless API
微服务架构实战指南:从单体应用到云原生的蜕变之路
🌟蒋星熠Jaxonic,代码为舟的星际旅人。深耕微服务架构,擅以DDD拆分服务、构建高可用通信与治理体系。分享从单体到云原生的实战经验,探索技术演进的无限可能。
微服务架构实战指南:从单体应用到云原生的蜕变之路
|
弹性计算 API 持续交付
后端服务架构的微服务化转型
本文旨在探讨后端服务从单体架构向微服务架构转型的过程,分析微服务架构的优势和面临的挑战。文章首先介绍单体架构的局限性,然后详细阐述微服务架构的核心概念及其在现代软件开发中的应用。通过对比两种架构,指出微服务化转型的必要性和实施策略。最后,讨论了微服务架构实施过程中可能遇到的问题及解决方案。