基于医院信息系统的ESB高可用架构建设探索与应用

【作 者】黄宗浩 ，王奕 ，王正源 ，蔡云飞，于镆铘

1 复旦大学附属肿瘤医院，上海市，200032

2 上海肿瘤疾病人工智能工程技术研究中心，上海市，200032

0 引言

我院信息化起步较早，于1999年开始大力发展医院信息化建设，先后建立了检验科系统（laboratory information system，LIS）、医院管理信息系统（hospital management information system，HIS）、电子病历系统（electronic medical record，EMR）、放射信息管理系统（radioiogy information system，RIS）、影像归档和通信系统（picture archiving and communication systems，PACS）等20多个主要业务系统。因系统在不同时期由不同厂家承建，致使系统间的信息交互非常困难，大多采用点对点的对接方式，没有标准接口规范和运行监控，信息中心维护工作量巨大。随着医院信息化的发展，实现医院业务系统间的互联互通标准化成了医院信息化建设过程中亟须解决的问题[1-3]。

医院建设企业服务总线（enterprise service bus，ESB）起步于2011年。参考借鉴国内外医疗信息交互标准和规范[4]，并结合自身情况制定了一套符合本院信息化发展的规范和标准[5]，从而实现了业务间的松耦合，提高了接口服务的复用度[6]，提升了业务接入的敏捷性。同时，对接口运行进行集中管控，实现管理的信息化、规范化和精细化[7]。ESB是医院信息系统运行的核心，一旦出现问题，就会影响全院信息系统。因此，ESB的稳定性、高可用性和高效性变得尤其重要，基于我院信息化建设，设计出一套ESB高可用架构解决方案，极大地满足了医院信息系统未来的发展需求。

1 现状

ESB总线自上线以来提供的服务量剧增，2011年、2018年和2021年的基础数据，如表1所示。2018年，接入厂家由最初的3家增加到了48家，发布服务由8个增加到了391个，订阅量达到1282次，日均调用量也由最初的3000增加到了80万，然而接口服务调用的均次消耗从450 ms攀升到了600 ms。

表1 ESB总线2011年、2018年和2021年基础数据Tab.1 Basic data of ESB in 2011,2018 and 2021

ESB总线之前的架构由一套数据库服务器、一套应用服务器和一套BizTalk引擎组成，采用的是传统的Cluster方式进行容灾。该架构虽消除了单点故障，但是存在几点不足：

（1）Cluster故障。Cluster故障会导致双机无法访问，应用服务器将无法获取配置信息或无法访问BizTalk引擎，致使无法正常工作[8]。

（2）数据库文件损坏。Cluster模式下数据库文件采用共享磁盘存放，只有一个备份，若文件损坏，将导致数据库无法访问。

（3）资源浪费。Cluster容灾采用一冷一热的模式进行容灾，冷备节点平时处于非工况，不能均衡ESB总线压力，浪费了医院的服务器资源。

（4）扩展有限。Cluster模式下提升ESB总线性能只能通过提升主机配置，但一台机器的提升是有限的，且会出现性能瓶颈。表1中2018年因达到当时配置性能瓶颈，均次调用需消耗650 ms。

（5）随着互联网业务的开展，服务调用的数量呈爆发式增长，我们亟须一个安全、高可用、可扩展的ESB总线架构。

2 建设方案

ESB总线主要由ESB应用服务器、ESB数据库服务器和BizTalk引擎等组成，如图1所示，传统方案中每组服务器通过Cluster进行双机灾备，可以避免单点故障引起的系统瘫痪，但无法阻止同一组服务器主备机同时故障引起的系统宕机。我们需要设计一套符合ESB总线特色的高可用方案。

图1 ESB总线传统容灾架构Fig.1 Traditional disaster recovery architecture of ESB

2.1 相关技术

2.1.1 AlwaysOn

微软最早于SQL Server 2012(11.x) 中引入了AlwaysOn、可用性组功能，可最大限度地提高一组用户数据库对企业的可用性，是替代数据库镜像的企业级高可用和灾难恢复解决方案[9-10]。AlwaysOn支持的单位是可用性组，发生切换时，可用性组中的所有数据组会作为一个整体进行切换。可用性组中的数据库文件不再存放于共享存储上，而作为独立副本存放在本地存储。因此，在主副本数据库文件受损的情况下，依然支持高可用和灾难恢复。

2.1.2 负载均衡

负载均衡（load balance），指将负载（工作任务）进行平衡、分摊到多个计算节点上进行运行，它提供了一种透明且廉价有效的方法扩展服务器、加强应用服务处理能力、增加吞吐量、提高服务的可用性和灵活性[11-13]。硬件负载均衡在服务器和外部网络间安装，独立于操作系统，整体性能得到最大提升，结合多样化的均衡策略、智能化的流量管理，可达到最佳的负载均衡需求，目前架构中采用的就是硬件负载均衡（F5）[14]。

2.2 高可用方案

医院业务系统间的接口服务调用可分为3个部分：服务提供方，ESB总线层，服务消费方。服务提供方根据ESB总线制定的接口服务规范建立Web Service服务并发布到ESB总线上。ESB总线层作为接口服务调用的中间层，提供了标准化的接口服务平台。服务消费方可按需订阅ESB总线上的服务。因此，我们需要保障ESB总线层的高可用才能保证医院业务系统的稳定运行。

2.2.1 ESB总线主体引擎容灾

如图2所示，将原ESB总线传统容灾架构拆散，入口服务、配置SQL和BizTalk引擎整合放置在一台服务器上，3个模块形成一个运行节点，可独立完成ESB总线任务。同时，我们可以根据实际业务和并发能力的需求横向扩展这些节点。负载均衡容灾方案采用2台F5搭建，当一台F5宕机时，另一台会自动接管负载均衡任务[15-16]。F5可以根据进入的请求流量和各个运行节点的实际负载进行动态的任务分配。

2.2.2 ESB总线其他模块容灾

ESB的日志作为业务系统间信息交换的详细记录，对问题跟踪、事件处理、异常捕获等有重要作用，但它不是ESB总线运行的必要条件。如图2所示，我们把日志数据库和配置数据库放在一组服务器上，利用MSSQL的AlwaysOn技术进行数据库的灾备[17-18]。ESB日志的完整性要求较传统业务系统要低，且ESB日志写入量巨大，因此采用异步方式进行备份，该模式下不会影响主数据库的读写效率，同时也保障了数据的实时备份。

图2 ESB总线高可用架构Fig.2 High availability architecture of ESB

2.3 故障模拟

该高可用架构的故障按发生设备可分为应用节点故障、日志服务器故障及F5负载均衡故障3种情形，其模拟结果如表2所示。

表2 ESB高可用架构故障模拟结果Tab.2 Fault simulation results of ESB high availability architecture

2.3.1 应用节点故障

ESB应用节点的主要功能是消息接收、处理和转发，是ESB总线的主体。其故障可分为服务器异常和IIS服务异常两种情况。服务器异常，消息通过F5的负载均衡功能自动分发到其他应用节点，不影响ESB总线的正常运行；IIS服务异常，F5会继续往异常节点发包，需要登录F5手动关闭故障节点的负载均衡，恢复时间预计为5 min。ESB应用节点只需一台工况良好，就可保障ESB总线服务不间断，通常根据医院业务量和规模可以设置3～5台。

2.3.2 日志服务器故障

ESB日志服务器的主要功能是记录日志、管理网站和配置设置，是ESB总线的辅助。其故障可分为单机故障和双机故障。单机故障，可通过AlwaysOn自动切换到辅助副本。双机故障或群集服务故障，短时间内无法恢复，无法使用管理网站、无法进行日志记录。由于日志服务器上的配置设置是实时同步到应用节点上的，故应用节点本地存有支持ESB总线运行的所有配置，日志服务器故障对ESB总线主体工作没有影响。

2.3.3 F5故障

F5主要功能是把请求消息均衡分配到应用节点上，是ESB总线横向扩展的保障。故障可分为单机故障和双机故障。单机故障，可通过自动切换备机的方式恢复。双机故障，导致负载均衡失效，请求方无法访问负载均衡的入口地址，会发生所有服务都无法调用的情况，造成全院系统瘫痪。通常可在5 min内判定故障原因，对F5断网或者关机，然后把其中一台应用节点的IP地址改成F5的入口地址，原访问F5的请求就自动转接到这台应用节点上，可暂时缓解故障。虽性能上较多节点有明显下降，但这种快速应急的处理方式为系统整体恢复争取到足够的时间。

3 结果

我院浦东院区于2019年开始运行，两院区间通过光纤直连，使用一套信息系统，再次对ESB总线高可用架构进行了跨院区部署，徐汇2个节点，浦东2个节点。截至2021年，接入厂家90家，发布服务695个，订阅服务2691次，日均调用量达到了150万，但平均响应时间缩减至400 ms。在日常运行过程中发生过多个应用节点宕机、数据库服务器磁盘爆满、F5宕机等多种类型的故障事件，但均没有对ESB总线造成影响或者可以在短时间内解决问题。这种新型ESB总线高可用架构很好地满足了医院信息化发展的需求。

4 讨论

本研究探索出一套ESB高可用架构解决方案，并总结了ESB总线高可用架构建设项目中出现的各种问题。传统意义上的容灾方案有时不适合某些系统，我们根据系统的特性消除单点及多点故障，增加可用节点，提高故障恢复速度，提高性能，保证业务系统持续在线。方案中采用单机模式取代原多机协同模式，把最核心模块建在一台服务器上，然后通过负载均衡的方式横向扩展节点。运行节点互不影响，节点间都有保障ESB总线运行的最简模块：独立的应用服务、独立的配置数据库、独立的BizTalk引擎。其他模块部署根据其特性采用了不同的容灾方案部署，以使整个架构更加科学。未来，在区域医疗和多院区模式的大环境下，信息系统的交互变得更加频繁、重要，这种高可用性、可扩展性和高效性的架构特别适合跨院区部署，具有重要的指导意义。