基于微服务架构及两地双活“二重奏”的HIS系统设计与实战

来源：HIT专家网  作者：奋斗的黄瓜片、丫妹、杨波等

笔者所在医院此前使用的HIS系统是2008-2020年期间逐步上线的。近年来，医院业务范围不断扩展，门诊、住院就诊人次急剧增加，系统压力也与日俱增，加之系统维护人员编写存储过程出现的脚本质量问题，使得医院核心数据库一度出现高频率死锁问题；另一方面，由于系统后期维保合同无法签订，集成平台的消息分发组件出现单点故障后无人维护，消息发送频繁出现故障。

种种问题叠加，老旧HIS系统无法满足临床业务需求，后续相关业务功能开发、相关评级工作无法开展，更换HIS系统势在必行。此时，互联网技术不断涌入传统医疗行业，为医院更换新一代HIS提供了有力支撑。

基于Spring Cloud微服务架构和Docker容器等技术，医院提出了新一代HIS系统架构设计理论，并将设计理论应用于实际，建设了新一代智慧医院综合管理平台（HIS）。同时，医院实施两地双中心计划，从IT基础设施保障角度为医院核心业务的稳定运行奠定基础。

此项工作于2020年12月开始推动。2021年5月1日，新HIS正式上线。现将该项目的建设情况与实战心得整理成文，与业界同仁分享、交流。

原有HIS系统存在的问题

医院此前使用的HIS系统，涉及门诊收费、挂号、临床医生站、护士站、集成平台等60多个软件系统，架构为传统的C/S和B/S混用架构，核心数据库采用SQL Server 2005，C/S程序采用客户端、中间层和数据库三层模式，B/S程序采用浏览器、应用中间层和数据库三层模式。

系统架构如图1所示，采用单机房部署，数据流从客户端通过F5实现负载均衡，将流量分发给对应的JBOSS应用服务、WebService服务和COM+服务，然后到底层数据库。

2014年，医院上线集成平台和临床数据中心。当时系统架构虚拟化应用服务器支持横向扩展，具备一定的业务承载能力，但集成平台采用单机运行节点，该节点一旦宕机，HIS系统和第三方交互业务将出现整体瘫痪情况，影响院内主体业务流程。后期，集成平台“脱保”无人维护，各子系统的数据漏发情况严重，数据源的缺失直接导致数据治理工作无法正常开展，集成平台和数据中心成了“摆设”。

《电子病历系统应用水平分级评价管理办法（试行）及评价标准（试行）》要求，三级医院要达到分级评价4级以上。而医院原有的电子病历系统采用的是普通文本非结构化存储模式，存在统计数据难、无法编辑留痕记录、无法实现病历标准化书写等问题，电子病历系统的更换也迫在眉睫。

综上，老HIS系统问题凸显：日常普通需求无法满足、医保新政策带来的程序改造无法实施、系统单点故障频繁出现，系统的连续性、易用性都出现了很大问题，亟需升级换代。

HIS升级与两地双活同步推进

2020年12月30日，医院开始新一代智慧医院综合管理平台（HIS）项目与两地双中心建设，建设周期为期五年。

第一阶段为2021年1-6月，主要目标是完成新一代智慧医院综合管理平台（新HIS）建设，替换老HIS系统，完成常德云计算中心机房与院内本地机房网络链路打通，实现两地机房双活。HIS服务实现全云化部署，通过集成平台完成所有第三方系统接入，优化业务流程，满足临床业务正常运转，满足电子病历评级五级、互联互通四甲基础要求。

第二阶段为2021年7-12月，主要目标是论证切换两地双活理论的可行性，本地机房虚拟化网络环境及硬件环境测试，验证本地机房与常德云中心网络链路打通方案的可行性。

第三阶段为2022-2026年，主要目标是完成新HIS系统全业务的两地双活负载，实现稳定的跨机房双活架构，实施机房“拉闸”断电测试，要求主业务无中断使用，建设目标达到电子病历6级、互联互通五级乙等测评水平，系统功能向自动化、智能化迈进，系统架构向“双中台”架构方向建设。

其中，新一代智慧医院综合管理平台的总体建设方向如图2所示，以主HIS为基础，按业务划分，实施业务模块化建设，如：以订单模式为核心的结算中心，统一全院结算业务，包含医疗业务结算、非医疗业务结算、合同结算等；以资源池模式管理全院可预约资源，构建预约中心，实现医技预约、床位预约、护工预约等功能，达到调整科室职能、提升工作专业性、节省人力成本、减少重复功能建设的目的，逐步浇筑医院业务中台；搭建以集成平台为交互核心的数据中心，建设患者矩阵、疾病矩阵、科研数据库、医疗专题数据库、管理数据库等数据分中心，雕琢院内数据中心。

新一代智慧医院综合管理平台的系统架构如图3所示，采用当前互联网应用普遍使用的微服务架构，融入阿里巴巴Dubbo框架，同时应用部署采用Docker容器部署，如图4所示。微服务架构有独立开发代码易理解、灵活部署、故障隔离、独立测试等优点，Docker有部署方便、隔离性好、快速回滚等优点。

重点建设模块

1.结算中心

结算中心的建设目标是统一所有窗口、财务合同相关结算业务，在窗口去掉门诊结算、住院结算、医保结算、体检结算、非医疗业务结算等子模块，将所有结算业务统一到一个结算模块，进行统一订单模式管理，交互图如图5所示，业务交互UI如图6所示。结算中心的优点是：全院统一业务结算、统一对账，避免人力资源浪费和结算系统数据报表交叉导致的数据管理混乱问题。

2.预约中心

预约中心的建设目标是将所有可预约资源号源池化，包含床位、疫苗接种、挂号、治疗、检查等所有资源预约。预约中心和门诊候诊、检查排队系统通过集成平台接口对接，通过预约中心配置可以预约到具体检查室，直接指定某块屏呼叫，与HIS系统实现高度集成，形成一套完备的预约、候诊、叫号体系。

3.机房双活

两地机房双活建设是医院IT基础设施建设的重中之重，其网络拓扑图如图7所示。

（1）网络层面：主备数据中心各部署2套核心交换机。云中心的主数据中心内网的2台核心交换机采用虚拟化技术，虚拟成1台交换机；医院本地数据中心2台核心交换机同样虚拟成1台交换机。两地之间采用VRRP网关热备协议实现网络双活。

（2）存储层面：主备数据中心集中存储，采用同步复制技术实现对称双活。

（3）平台层面：主数据中心运行一套虚拟化平台，备数据中心运行一套虚拟化平台，上层通过一套云管平台进行统一管理。当主数据中心虚拟化平台创建业务虚拟机，云管平台自动在备数据中心创建同样的虚拟机挂载双活存储的备虚拟机文件，备虚拟机不开机运行；当云管平台检测到主数据中心发生灾难性故障之时，自动调用备虚拟机在备虚拟化平台上开机，主数据中心恢复之后可回切业务系统。

项目建设的创新点

总体而言，笔者所在医院新一代智慧医院综合管理平台（HIS）建设的创新点主要有以下几点：

（1）引入微服务等新型软件技术架构、中间件，实现快速迭代开发、软件部署、软件故障回滚、故障隔离、熔断、流控、高性能、动态路由、热替换、无感知发布等。

（2）去同质化功能。通过模块化组件封装，使用单模块管理专一业务，避免重复造轮子，节省软件项目成本和人力成本。如：结算中心、预约中心、报告中心、统一门户等，将同质化的功能统一由某一个模块开发设计。

（3）采用服务器虚拟化技术，支撑纵向扩展能力。在硬件性能允许范围内，具有节点横向扩展能力。

（4）通过网络机房基础设施的改造，支持“拉闸式”容灾，实现两地机房双活。

系统架构的设计思路

1.HIS主业务系统架构设计

HIS系统的总体架构如图8所示。

智慧医院综合管理平台入口网关摒弃了硬件F5负载，采用Nginx + Keepalived软负载模式，通过Linux内核调优后，16G内存、8核CPU可支持10万并发量。集群原理是通过Keepalived实现虚拟IP漂移，实例如图9所示。此模式可能出现的故障点，后文将做详细阐述。

在微服务架构中，ZooKeeper充当着非常重要的角色。由于ZooKeeper的节点选举机制，采用奇数节点部署方式可以节省服务器资源，同时保证了死亡容忍度。但用双机房分摊ZooKeeper的奇数节点，势必会导致一个机房多、一个机房少。如果节点多的机房整体拉闸，将会导致整套服务不可用，如图10所示。

出于这方面的考虑，我们提出了新的思路，将负载均衡再提高一个层面，把每个机房当作集群节点，HIS程序将同套代码分别部署到两个机房，两机房之间的微服务互不通信，每个机房部署3个ZooKeeper节点，解决了此类问题，如图11所示。

针对双机房引发的应用登陆会话问题，可以通过双机房的Redis缓存集群实现共享，此交互方式与Nginx集群类似。在此种架构方式中，为应对单机房程序发布中出现重大故障无法回滚的问题，可以使用网关切除流量方式，将流量分发到未发布的机房，从而保证业务的正常运转，类似于灰度发布。

2.集成平台架构设计

作为院内系统的交互核心，集成平台高可用的必要性不再赘述。集成平台架构如图12所示，除日志服务器外，其他业务节点全部实现双活，因此集成平台的所有节点均可拆分到两个机房实现双机房双活。值得一提的是，我院的集成平台网关应用支持路由配置、流量控制、消息重推等功能，在日常工作中可以很方便地切换流量到具体集群，当前已经承载日均700万次调用的业务量。

3.数据库双机房容灾的建设思考

在容灾建设中，我们首先考虑“基于存储网关的实时数据复制”。传统的数据库服务器集群如图13所示。单机房内部存储网关实现存储双活，考虑到双机房，可以将计算、存储、网络资源分别划分到两个机房，也即图14所示架构情况。

该架构的优点包括：（1）灾难恢复时间短，可实现系统平滑切换；（2）能够实现数据实时同步，做到数据0丢失；（3）冗余架构主要由硬件实现，部署简单；（4）管理维护简单。该架构的缺点主要为：（1）对于软件故障的防护能力弱；（2）对于人为误操作基本无防护能力；（3）对跨机房数据传输速度有极高要求。

其次，我们考虑“基于CDP实时数据复制”。CDP数据保护解决方案是通过两台服务器以集群方式提供业务服务：服务器、光纤交换机、生产/容灾存储组成存储局域网；CDP设备将生产存储的数据实时复制到容灾存储；服务器可访问生产存储和容灾存储，从而实现服务器、数据链路、存储的冗余。在这个架构中不存在硬件单点故障，但当发生生产存储故障时，需要挂载容灾存储并进行手动的系统切换。主要架构图15所示。

该架构的优点包括：（1）CDP能实现任一时间点恢复；（2）具备链路压缩功能，易用于支持容灾远程复制；（3）数据实时复制，基本做到数据0丢失；（4）对于物理和逻辑故障有较强的防护能力。缺点主要是：（1）冗余架构需要软硬件支持，部署较为复杂；（2）容灾恢复需要软硬件配合，恢复时间相对较长，无法平滑切换；（3）管理维护复杂。

最终，我们设计了一种比较综合的处理方案，并朝这个方向努力建设，如图16所示。该架构能满足两地双机房双活需求，同时弥补了之前两套方案的缺点，最大难点在于两个机房的链路畅通问题。

4.线上支付业务的双机房双活实现原理

在两地机房主业务工作正常情况下，如何保证外网业务的正常工作？线上业务无疑也是高可用方案中必须考虑的关键点。线上支付业务检验逻辑如图17所示。一般情况，医院会让运营商提供外网专线，再通过类似防火墙等设备实现端口转发数据，但在这种架构下，应如何实现线上业务的双活呢？

我们首先考虑通过最低级别的DNS手动切换IP方式来“保底”，然后考虑双机房、双运营商链路冗余方案，加上运营商内部的多机房负载均衡设备，实现入口流量的高可用，在外部流量高可用的情况下实现两地双机房支付业务的双活，如图18所示。在最差的情况下，如运营商1出现重大故障，需要手动切换DNS到运营商2的备用链路，实现业务正常运转。

技术难点及解决方法

在推动上述架构设计思路落地建设过程中，我们遇到了一些技术难点；新HIS上线后，也曾出现一些故障。现将部分典型故障及解决方法分析如下。

1.链路故障导致的脑裂现象

在微服务架构中，ZooKeeper集群对节点之间的网络通畅度要求较高，一旦出现节点间的通信问题，即可能导致“脑裂”现象：在HA集群系统中，同一个整体的A、B节点之间通过心跳来确认对方存活状态，正常情况下如A节点无法检测到B节点，则将接管B节点的业务；当出现网络故障时，A节点和B节点都认为对方已经宕机，然后开始争抢主导权，如图19所示。

新HIS上线后，我院出现过Keepalived的脑裂问题，原因是机房链路故障，虚拟IP漂移出现故障，导致部分机器访问网关不通。确定问题后，重启Keepalived，业务完全恢复。后续针对此类问题，我们通过仲裁方式解决。

2.高并发随机读写引发的IO等待问题

磁盘阵列采用RAID 6，平台总线服务器使用Windows Server 标准版，平台交互消息体采用HL7 V3格式，平台服务器会临时存储消息体到磁盘，均为小文件存储。曾发生一例故障现象：平台服务卡死，磁盘文件出现损坏；单机节点宕机后，在该节点还没完全修复情况下，集群中另一个节点出现宕机，引发“雪崩”。

我们首先排查虚拟机底层，没有发现异常；操作系统层面日志显示“磁盘I/O故障”，通过磁盘速度测试，发现随机读写测试只有几百KB/S；后续通过移除磁盘双写，横向扩展Linux节点，问题解决；后续我们将逐步全部替换为Linux。

3.全链路故障追踪难题

微服务架构使得高可用性问题迎刃而解，但对于普通运维来说，如果没有一个完备的链路追踪系统，将会极大地降低排查故障效率。因此，我们引入了“探针”技术，实现主应用链路追踪。不过，在消息中间件（非开源）内部，“探针”工具无法正常工作，我们采取的方式是在业务网关入口节点上部署“探针”实现追踪。

系统上线效果

从2021年5月1日新HIS系统上线至今，医院共接入第三方系统62个，开放服务401个，服务调用次数日均700万，调用成功率为99.89%（包含第三方业务系统自身故障原因）。集成平台承受过2万次/秒的异常流量攻击测试。系统运行日趋平稳，轻松支撑当前高峰期门诊量（7000人次/日），通过架构设计的优化和服务器的横向扩展，未来预计可支撑更大量的请求并发，并且稳定运行。

从运维层面来看，可通过专门的虚拟化平台管理硬件设备，通过网络监控系统实时监测，实现邮件、短信、企业微信的实时消息推送预警；对于虚拟化服务器的管理，也可以通过虚拟化平台统一管理，对计算、存储、网络资源进行动态调整，具有较高的可维护性；对于软件系统，由于引入了“探针”技术和完备的日志系统、系统故障上报模块，在日常工作中遇到故障能快速定位，快速响应解决。

从用户层面来讲，通过为期四个月的全院级培训使用，针对用户部门提出的新需求进行高速迭代，已可初步满足临床的使用，系统响应速度和操作便捷性整体反馈较好。全结构化的数据存储对于后续系统改造、数据统计分析都起到了积极作用。

从评级角度来说，当前医院已经通过互联互通四级甲等测评，并申报电子病历系统应用水平5级。在对标改造过程中，由于系统架构设计的合理性和项目总体规划的预见性，在系统整体协调、对接建设方面相对顺畅，使得医院对于评级评审拥有更强信心。

总结

系统架构方案是系统平稳运行的理论基础，医疗业务7×24小时无中断平稳运行是患者、临床、管理的必然需求。虽然医疗业务的并发量没有达到互联网访问级别的水准，但作为技术人员对于系统架构设计的高远追求，永远不可摒弃。

努力维持系统稳定，专心投入临床需求，是医院信息部门工作的重中之重。虽然好的软件并非局限于系统架构的先进性，而在于是否能够不断满足患者、临床、管理的需求，不停地迭代演进。但正是有了优秀的架构，我们的业务拓展才会得心应手，才会“到中流击水，浪遏飞舟”！

【参考文献】

[1] MartinFowler. 企业应用架构模式[M]. 机械工业出版社, 2004.

[2] ThomasKyte, DarlKuhn, 凯特,等. Oracle编程艺术：深入理解数据库体系结构[M]. 人民邮电出版社, 2016.

[3] 蔡皖东. 基于SAN的高可用性网络存储解决方案[J]. 小型微型计算机系统, 2001, 22(3):4.

【作者简介】

奋斗的黄瓜片，男，35岁，很帅！2010年毕业于淮北师范大学网络工程专业，由于兴趣原因自学软件开发后前往杭州工作，从事软件开发工作，有5年大型互联网公司软件开发工作经验，对商品秒杀、普通网站破解略有研究。后因某种神秘原因回到老家某医疗单位继续从事软件方面工作。

性格倔强、开朗；时而严肃认真、时而幽默风骚！做人有原则，高度自律！

希望通过不断学习，提升自我，突破自我，升华自我。

【责任编辑：秦勉】