负载均衡技术在大型公立医院中的应用

施识帆，张昕，曹凯迪，王忠民

南京医科大学第一附属医院 信息处，江苏 南京 210029

引言

随着信息化技术的不断发展，医院对信息化的依赖程度与日俱增。因此，鉴于医院服务模式的特殊性，医院中的各个业务信息系统需保持高度的稳定性与安全性。另外，随着新医改的不断深入，医院的规模不断扩大，医院集团化的发展趋势日益显著。如何在满足稳定性、安全性的同时，应用有限的资源建设满足高并发需求、方便横向扩展的信息系统，成为每一个医院信息管理者的难题。幸运的是在金融、国电等领域已有一些先行经验可供借鉴，那就是采用负载均衡技术。本文将主要介绍该技术的背景及其在我院的实际应用情况。

1 负载均衡技术介绍

负载均衡技术建立在现有网络结构之上，提供了一种廉价、有效、透明的方法，来扩展网络设备和服务器的带宽、增加吞吐量、加强网络数据处理能力、提高网络的灵活性和可用性。简单的讲，就是将工作负载进行平衡、分摊到多个服务器主机或网络设备上进行协同工作，共同完成工作任务[1-3]。它主要用于避免出现单点故障，提高服务器资源利用率，提高服务器响应速度，解决网络拥塞问题，为用户提供更加稳定可靠的访问质量。

负载均衡技术在实现上有两种方案可供考虑：软件负载均衡和硬件负载均衡。通常来说，软件负载均衡通过在服务器上安装软件来实现[4-6]，成本低廉，使用灵活，一般情况下，适用于访问量小且不要求全天候运行的系统；硬件负载均衡是独立于服务器操作系统和外部网络的硬件设备，在功能和性能上要优于前者，适用于负载量大且要求全天候不间断运行的系统[7]。

负载均衡器在网络中的部署方式很多，主要的有串联模式和并联模式[7-8]两种。串联模式负载均衡器位于上下层网络设备之间，网络拓扑结构和应用业务的实现对负载均衡设备依赖性较强；并联模式负载均衡器以旁路的方式部署在现行的网络环境中，可以方便、快速地部署到网络环境中实现其负载均衡功能，但接口的流量压力较大，要避免成为网络瓶颈[9]。

另外，负载均衡器可以通过设定算法策略，合理地将前端请求调度给后端的服务器，尽量将负载做到均衡[10]。算法策略大致可以分为以下几类：静态算法[11-15]、动态算法和自适应算法[16-18]。针对不同的应用场景使用不同的算法策略，也是一项值得深入的研究。我院在实施负载均衡项目时，综合考虑了以上不同选择的优劣，针对实际情况选择了最适合我院的方案，完成了项目的部署和应用。

2 我院负载均衡方案应用实践

2.1 项目实施目的

我院实施负载均衡项目的初衷是为了解决住院电子病历系统实施过程中出现的一些问题。在我院住院电子病历系统的上线初期，应用服务器只使用了一台。到了系统上线完成时，服务器已扩展为四台，分别对应了本部内科、本部外科、本部其他科室和集团分院。这里存在几个问题：① 某台服务器停机维护或宕机时，对应部门或院区的电子病历系统服务就不得不停止；② 客户端维护困难，需要针对不同部门设定其对应的服务器IP地址；③ 会有某台服务器CPU压力极高，而其他几台空闲的情况出现。

随着上线科室和使用部门越来越多，服务器规模越来越大，上述问题特别是第③点服务器负载不均衡的问题日益突出，维护人员经常需要将连接到繁忙服务器上的客户端迁到空闲服务器上，来保证其服务可用。在迁来迁去的过程中，客户端和服务器的对应关系就更加混乱了。为了充分利用服务器资源，从根本上解决上述问题，同时为日后其他业务系统服务器架构设计提供经验，负载均衡项目的实施正式开始。

2.2 项目方案选择

软、硬件负载均衡各有优劣，经过前期调研，该项目最终还是选择了硬件负载均衡方案。这个选择主要基于以下几点考虑：① 我院的规模较大，系统数和用户数较多，相应的负载量较大，硬件负载均衡有比较好的性能和稳定性；② 硬件负载均衡的策略算法较多，功能较丰富，比如高级服务器健康检查和防火墙功能。这些算法和功能，有些软件方案无法满足；③ 虽然部分软件负载均衡开源而且免费，但是学习、管理和迁移成本较高；④ 功能强大的软件负载均衡消耗系统资源较多，而且操作系统本身的漏洞也会带来新的安全问题[2]。所以，尽管硬件负载均衡前期投入的成本很高，但从长远来看，从维护的角度来看，依然是非常划算的。

2.3 整体架构设计

我院目前的负载均衡架构如图1所示。总体架构使用了两组负载均衡，每组负载均衡由两台设备组成双机热备，备机自动同步主机配置，当主机故障时，自动主备切换，保证不在负载均衡设备上出现单点故障。对于业务系统也按功能和重要程度进行了分组，部分系统如集成平台相关的系统划为A组，与负载均衡A对接；其余系统如电子病历系统划为B组，与负载均衡B对接。在极端情况下，如负载均衡A两台设备均故障，那么可以将A组系统临时接入负载均衡B，保证应用不中断。为达到该目的，在设计时，我院采用的负载均衡设备保留了极高的冗余性能。

图1 我院负载均衡项目总体架构图

事实证明，即使是小概率的极端情况也有发生的时候。在某个周末，A组设备主机故障，主备切换过程中发生设备宕机，重启设备后发现两台设备均无法正常使用。幸运的是A组设备的配置文件有备份，于是我们在B组中重建了所有任务，中断的业务得到恢复。正是由于使用了两组负载均衡设备的设计，故障又恰巧发生在周末，重要业务才没有中断太长时间。

这也给信息系统相关维护人员一个警示，使用负载均衡设备本意是为解决单点故障、保障系统可用性，千万不要让其成为整个系统中的弱点和死穴。

在部署方式上，我院采用了并联模式来部署负载均衡设备。综合来说，这种模式增加了网络的灵活性，提高了网络整体的可靠性，是对现有网络结构、应用业务及服务器配置更改最少的一种部署方式。

在部署完成之后，住院电子病历系统曾遇到一个小问题，那就是服务器端无法接收客户端的真实源地址，在日志中记录的IP全部来自负载均衡设备。我们的解决的办法也很简单，就是通过改造住院电子病历系统，把客户端地址放在HTTP头信息里传过来，服务器端解析后提取即可。

2.4 负载均衡策略的使用

我院根据实际情况和不同系统的特点，使用了不同的负载均衡策略。

对于影像数据中心平台、Web Service接口服务等，由于每次访问都是独立的，对于客户端来说访问A服务器或者B服务器并没有什么区别，而且每次访问的连接时间很短，因此可以采用加权轮询调度算法，根据每台服务器性能的高低，配置对应的权重；或者采用最快响应算法，把负载调度给相对空闲的服务器。

对于电子病历等业务系统，因为连接时间较长，同时服务器上会保存会话信息和一些缓存信息。如果在不同服务器上切换，会导致系统登出和数据保存失败，因此采用最小连接调度算法，同时采取会话保持机制，以确保在会话期间不会被调度到其他应用服务器上。在实施门诊电子病历的过程中，偶尔会出现用户自动登出的问题，适当增加会话保持的时间就可以有效减少此类问题。但如果会话保持的时间太长的话，负载均衡本身又会失去意义，所以配置优化工作也是在实践摸索中不断前行的。

另外，配置服务器数量时要考虑宕机时的冗余，尽量保证每台服务器的负载在中低水平。在某台服务器故障时，剩余服务器能接手额外增加的负载，避免发生“A机宕机→负载均衡→B机过载→B机宕机”这样的连锁反应。

2.5 应用成效

我院硬件负载均衡经过5年多的使用，除了上线时部署的住院电子病历系统以外，还增加了门急诊电子病历系统、各类接口服务器等。目前设备上部署的资源池27个，对应的资源池成员64个，对应的节点46个。

平时工作期间的每秒数据吞吐量在100～200 M Bits之间，有时数据峰值可达400 M Bits/s（图2），活动连接数也在500到1000左右，最大连接数超过2000（图3）。从图中也可以看出，医院的工作负荷在周一最重，周六较轻，周日最轻，其余工作日持平。

图2 数据吞吐量

图3 活动连接数

从设备上部署的服务器数量来看，和Web Service接口服务相关的服务器大约占60%，其余40%用于各个业务系统，如临床数据中心、影像数据中心、MQ平台、门急诊电子病历系统、住院电子病历系统等。

从数据吞吐量的角度（图4），影像数据中心占绝对主力，超过总数据量的五分之四；如果从活动连接数的角度看（图5），则住院电子病历系统和门急诊电子病历系统合计接近总连接数的四分之三。

在这样的负载压力下，硬件负载均衡的CPU占用率始终在20%左右波动且波动幅度较小（图6），同时内存的是使用率也保持在极低的程度，这表明实际负载相对于设备的可负载能力还保持在较低水平，硬件性能还有极大的冗余，即使访问量出现可预期或者不可预期的突然增加，也可以保证系统稳定运行的瓶颈不会出现在硬件负载均衡设备上。

图4 各业务系统数据吞吐量饼图

图5 各业务系统活动连接数饼图

图6 CPU占用率

3 结语

负载均衡技术随着信息化的发展而产生，它的出现提高了信息系统的横向可扩展性，使得系统在高并发时的可用性和安全性得到保障。我院通过实施负载均衡项目，满足了业务的冗余要求，为医院365天×24小时持续服务奠定了基础。随着云计算技术和大数据时代的到来，安全性和可靠性的要求也越来越高，在这种背景下，用对用好负载均衡，把技术转化为生产力，也将变得非常重要。