首个多院区异构多活容灾架构,浙人医创新开新篇

首个多院区异构多活容灾架构,浙人医创新开新篇

KingbaseES数据库:首个多院区异构多活容灾架构,浙人医创新开新篇

2025 年 10 月 23 日消息,浙江省人民医院(浙人医)作为省内卫健系统信创 “领头雁”,依托金仓数据库搭建异构多院区多活数据底座,成为国内首个 LIS 国产化异构数据多院区多活改造案例。浙人医拥有多院区及托管分院,此前面临核心系统依赖国外数据库、多院区数据互通难等问题,遂选择 LIS 系统为信创突破口,联合电科金仓实现四大技术创新,达成 RTO≤10min、RPO=0 的 6 级灾容标准,业务连续性达 99.99%。目前 4 大院区数据双向同步,数据调用效率提升 60%,富阳院区还实现全栈信创与业务系统云化部署,为医疗信创提供可复制样本。

作为浙江省卫健系统信创“领头雁”,浙江省人民医院(下称“浙人医”)从LIS系统切入,实现从单系统突破到全栈国产化的跨越式发展。依托金仓数据库搭建的异构多院区多活数据底座,该院实现4大院区数据互相双向同步,灾容恢复能力达到6级标准,业务连续性达到99.99%,数据调用效率提升60%。浙人医的实践不仅为浙江省卫健行业信创规划提供了可复制的实践样本,更为多院区集团化医院信创建设探索出了一条以点带面、循序渐进的道路。

在这里插入图片描述

一、破局起步:集团化医院的信创突破口选择

浙人医是浙江省规模最大、实力最强的综合性三甲医院,拥有朝晖、望江山、越城、富阳四大已运行院区,滨江、萧山两个在建院区及全面托管的八家分院,横跨杭州绍兴两地。庞大的体量与业务规模,使其成为省内卫健系统信创试点的核心选择。

医院的核心信息系统若长期依赖国外数据库与硬件设备,不仅面临“卡脖子”风险,更难以满足医疗数据隐私保护、业务连续运行的高要求。在政策要求和业务需求的双重推动下,浙人医信息化团队借助越城院区建设启动信创。

相较于单一院区医院的信创改造,浙人医作为多院区集团化医院,其信创建设面临着更为复杂的挑战:

  • 各院区、业务系统之间数据兼容互通难度高;
  • 信创改造期间各院区需要保持互联互通能力,业务连续性要求高;
  • 考虑到跨院区跨城市之间的异地协同需求,数据库还需支持异构同步双写并行、多院区互为灾备、多院区负载均衡等容灾能力。

在反复论证与风险评估后,浙人医最终选择LIS系统作为信创建设的首个攻坚目标,背后有三层考量:

  1. 业务重要性突出:LIS是医疗核心系统之一,是连接检验科室与临床科室的数据桥梁,其效率高下患者体感明显;
  2. 数据规模适中可控:LIS系统支撑全院日均2万余个标本的处理需求,业务体量适中,应用场景集中,影响范围可控;
  3. 可复制性强:LIS业务覆盖面广,与院内其他业务系统和仪器设备均有对接,迁移经验可形成先易后难、逐步推广的良性循环。

二、金仓赋能:异构多活构建极致容灾

浙人医信息化与人工智能部副主任范玉林介绍,医院将产品成熟度、与原有Oracle数据库的兼容性、易上手、易运维等作为数据库选型重点,最终选定金仓数据库。

医疗行业业务逻辑异常复杂,厂商对于业务场景的理解深度尤为关键。金仓数据库在医疗场景适配经验丰富,已经服务301医院云HIS系统(点击了解详情)、陕西西京医院PACS系统(点击了解详情)、常德二院全栈国产化信创等项目(点击了解详情),在医疗行业蝉联国产数据库销量榜首(点击了解详情)。此外金仓数据库作为一款多模、多场景数据库,同时满足多种数据库改造需求,可实现技术栈收敛。依托多语法原生兼容和SQL、PLSQL反向兼容服务,无需大量修改代码。凭借出色的产品力和本地化团队带来的优质服务,浙人医和电科金仓达成合作,开启了浙人医LIS系统信创攻坚。

多院区集团化医院信创改造过程在面临传统医疗机构固有难题的同时,还需满足不同院区之间的数据同步和协同,对于双向双写和灾备能力提出极高的要求。医院信息系统灾难恢复能力6级标准要求医疗机构做到数据零错误丢失(RPO=0),从故障发生到系统完全恢复时间(RTO)小于10分钟,传统的灾备架构很难实现这样的需求。

浙人医在开启LIS系统信创时拥有越城、朝晖、望江山三个院区,此前LIS系统业务均由越城院区主系统承载,系统压力大,院区间如遇网络中断需要手动拉起灾备系统,RTO不可控。在LIS系统的国产数据库迁移过程中,浙人医联合合作伙伴制定技术方案,实现了如下四大技术创新:

  1. 异构组网:信创完成后,金仓数据库成为新的业务承载主力,原非信创数据库依旧保持活跃,双轨同步运行;
  2. 多活容灾:引入多活容灾架构,多院区互为灾备,支持多院区间的负载均衡和多活容灾,横向拆分多院区压力,故障发生时无需手动拉起灾备系统,帮助医院实现RTO≤10min、RPO=0的容灾目标;
  3. 多写同步:基于业务存量数据校验技术和增量数据校验技术,各数据中心通过KFS工具实现环状数据同步,进一步提升容灾能力;
    (注:院区布局参考:望江山院区(待建卫星站)、滨江/萧山院区(待建卫星站)、朝晖院区(中心站,机房Oracle)、越城院区(中心站,机房KES)、富阳院区(中心站,机房KES),院区间通过KFS实现数据同步)
  4. 卫星方案:小型院区重要工作位置布置轻量化卫星站,通过小型化节点保留核心功能,减少网络依赖,提升应急能力。
在这里插入图片描述

在数据迁移阶段,浙人医采用了电科金仓双轨并行、分阶段推进方案保障平滑切换:迁移至金仓数据库之后,原有非信创系统作为备用数据库保持活跃,遇有突发情况可随时切换回原系统。系统上线前浙人医还围绕故障应急进行了多轮演练,模拟Oracle主库故障切换到国产库、国产数据库集群故障自动转移、国产数据库单边故障、Oracle单边故障、院区网络中断国产数据库与Oracle各自独立运行、关闭部分服务器模拟硬件故障等多种场景,确保系统切换万无一失。

在电科金仓的支持下,2023年10月,浙人医完成LIS系统国产化适配;2024年4月同步完成双活+应急方案系统改造并完成程序更新,在越城院区国产数据库实际环境测试应用,5月正式在越城院区上线。目前浙人医LIS系统已经在越城、朝晖、望江山、富阳院区实现互相双向同步,成为国内首个LIS国产化异构数据多院区多活改造案例。

三、以点带面:全栈信创的浙江样本

LIS系统在多院区的成功落地,为浙人医信创建设的全面推进奠定了基础,其信创版图持续扩张。走进今年新启用的浙人医富阳院区,这个全省首个医疗全栈信创样板间集中展现国产生态的成熟度:

  • 服务器操作系统涵盖麒麟、统信、龙蜥、欧拉等;
  • 桌面操作系统以中科方德、统信为主;
  • 金仓数据库作为国产生态的重要一环,为富阳院区核心业务系统提供数据底座支撑。

浙人医的信创实践并非单点作战,而是深度契合浙江省健康云建设规划。在富阳院区的建设中,浙人医和浙江省健康云有限公司达成深度合作,富阳院区信息机房在本地建设,作为健康云的计算节点和容灾中心之一;医院按需从健康云购买服务。依托富阳院区的原生云生态,院区HIS、EMR、LIS、PACS等业务系统均已实现云化部署。

富阳院区试运行以来,系统每小时访问量达40多万次,数据库IOPS(每秒读写操作数)达到1万以上。与原系统相比,数据调用时间平均缩短了0.8秒,效率提升了60%。业务高峰时,系统响应延迟时间≤0.3秒,为患者和医护人员提供了更高效、更快速的服务体验。

四十载勇攀高峰,浙人医这家全国最年轻的省人民医院,不仅在构建学科高地、优化人才生态、推动集团化发展方面走在了浙江乃至全国前列,更领跑数智赋能领域前沿。浙人医与电科金仓也将继续携手,为构建自主可控的医疗信息化体系、守护人民健康福祉贡献更多力量。

四、KingbaseES数据库增删改查操作详解

1. 新增数据(INSERT)

KingbaseES中使用INSERT语句向表中添加新数据,基本语法为:

INSERTINTO 表名(字段1, 字段2,...)VALUES(值1, 值2,...);

示例:向用户表(user_info)插入一条新记录

INSERTINTO user_info(id, username, age)VALUES(1,'张三',25);

可同时插入多条记录,只需在VALUES后添加多组值,用逗号分隔。

2. 查询数据(SELECT)

SELECT语句用于从表中查询数据,基本语法为:

SELECT 字段1, 字段2,...FROM 表名 WHERE 条件;

示例1:查询用户表中所有记录

SELECT*FROM user_info;

示例2:查询年龄大于20的用户姓名

SELECT username FROM user_info WHERE age >20;

可通过ORDER BY进行排序,使用LIMIT限制返回条数。

3. 更新数据(UPDATE)

UPDATE语句用于修改表中已有数据,基本语法为:

UPDATE 表名 SET 字段1=新值1, 字段2=新值2WHERE 条件;

示例:将id为1的用户年龄更新为26

UPDATE user_info SET age=26WHERE id=1;

注意必须添加WHERE条件,否则会更新表中所有记录。

4. 删除数据(DELETE)

DELETE语句用于删除表中的记录,基本语法为:

DELETEFROM 表名 WHERE 条件;

示例:删除id为1的用户记录

DELETEFROM user_info WHERE id=1;

同样需要注意WHERE条件,若省略将删除表中所有数据。

以上四个操作构成了KingbaseES数据库的基本数据操作,通过合理组合使用这些语句,可以实现对数据库的完整管理。在实际应用中,需注意SQL语句的规范性和安全性,尤其是涉及删除和更新操作时要谨慎处理条件判断。

Read more

有了AI,还需要学Springboot吗?

一、结论先明确:非常有必要学 SpringBoot,AI 是 “助手” 而非 “替代者” AI(比如 Copilot、通义灵码、ChatGPT)确实能大幅提升开发效率,但它无法替代你对 SpringBoot 核心原理和工程化思想的掌握,原因主要有以下几点: 1. AI 是 “工具”,但你需要判断 AI 输出的 “对错” 和 “优劣” * AI 能帮你生成 SpringBoot 的基础代码(比如写一个接口、配置数据源),但它无法保证代码的正确性、安全性、性能,也不懂你项目的业务场景和架构设计。比如:AI 可能生成有漏洞的接口(未做参数校验)、不合理的配置(连接池参数设置错误),如果不懂 SpringBoot 的核心原理,你甚至无法发现这些问题,更无法修正。

By Ne0inhk
【终极对决】Kafka vs RabbitMQ:深入剖析消息中间件双雄,附选型指南与代码实战

【终极对决】Kafka vs RabbitMQ:深入剖析消息中间件双雄,附选型指南与代码实战

个人名片 🎓作者简介:java领域优质创作者 🌐个人主页:码农阿豪 📞工作室:新空间代码工作室(提供各种软件服务) 💌个人邮箱:[[email protected]] 📱个人微信:15279484656 🌐个人导航网站:www.forff.top 💡座右铭:总有人要赢。为什么不能是我呢? * 专栏导航: 码农阿豪系列专栏导航 面试专栏:收集了java相关高频面试题,面试实战总结🍻🎉🖥️ Spring5系列专栏:整理了Spring5重要知识点与实战演练,有案例可直接使用🚀🔧💻 Redis专栏:Redis从零到一学习分享,经验总结,案例实战💐📝💡 全栈系列专栏:海纳百川有容乃大,可能你想要的东西里面都有🤸🌱🚀 目录 * 【终极对决】Kafka vs RabbitMQ:深入剖析消息中间件双雄,附选型指南与代码实战 * 一、核心概念与架构模型图解:两种不同的设计哲学 * RabbitMQ:精密的“路由引擎” * Kafka:

By Ne0inhk
Redis:从消息中间件到分布式核心

Redis:从消息中间件到分布式核心

The open source, in-memory data store used by millions of developers as a database, cache streaming engine, and message broker. Redis 的初心.最初就是用来作为一个"消息中间件"的(消息队列). 分布式系统下的生产者消费者模型 当前很少会直接使用 Redis 作为消息中间件(业界有更多更专业的消息中间件使用) 一、Redis 概述与定位 Redis 是一种开源、内存型数据存储系统,广泛被开发者用作数据库、缓存、流处理引擎和消息代理。 最初定位为“消息中间件”(消息队列),但目前在生产环境中较少直接使用 Redis 作为消息队列,因为有更专业的替代方案。 Redis

By Ne0inhk
基于java Web 生产设备综合效率管理信息系统设计与实现

基于java Web 生产设备综合效率管理信息系统设计与实现

博主介绍:翰文编程 专注于Java(springboot ssm 等开发框架) vue  .net  php phython node.js    uniapp 微信小程序 等诸多技术领域和课设项目实战、企业信息化系统建设,从业十八余年开发设计教学工作 ☆☆☆ 精彩专栏推荐订阅☆☆☆☆☆不然下次找不到哟 我的博客空间发布了2000+题目解决方法案例  方便大家学习使用 感兴趣的可以先收藏起来,还有大家在毕设选题,项目以及论文编写等相关问题都可以给我留言咨询,希望帮助更多的人 文末下方有源码获取地址 第4章 总体设计 4.1 系统总体模块图 生产设备综合效率管理系统主要设计了用户管理、设备故那里、OEE管理、故障管理、OEE分析等功能,满足用户在网站上面进行设备生产效率的信息浏览与查看,具体功能模块图如4.1所示: 图4.1 系统总体模块图 4.2 数据库层的设计 4.2.1 概念模型设计

By Ne0inhk