导读：如集成平台每日业务量超过百万级，建议考虑采用集群架构。

在一个普通的早高峰时段，一个急促的电话打破了医院信息中心的平静：“自助机卡住了，很多患者在抱怨，怎么办?”

接到电话后，负责HIS、集成平台、自助机等项目的技术人员马上开始排查问题。

“自助机响应超时，偶有链接断开。”“HIS接口响应较慢，但未看到有错误。”“集成平台信息处理速度慢，导致队列挤压超时。”

20分钟后，三方技术人员汇总并确定了问题：集成平台由于某个项目的请求量突发增高，后续系统处理跟不上，导致其他调用无法请求。

处理方法：关停此集成业务，业务恢复。

事情解决了，但背后的问题却值得深思。智慧医院建设不断向前，越来越多的应用和场景已打破了原有点对点的数据交换方式，转而通过医疗信息集成平台来实现消息的流转和分发，获取更加灵活、标化和可控的互操作能力。同时，医院在业务层面也更加重视通过自助机和各类线上应用等手段，为患者提供更加优质便捷的服务。

当集成平台的技术无法适应快速增长的信息化应用对集成和互操作的需求时，那么就会引发一次又一次这样的信息“灾难”。应该怎样有效避免类似情况的发生呢？

浙江省台州医院信息中心 刘祉呈

就像有人买车更多看重外观动力和内饰，并不在意发动机一样，医疗信息集成平台的使用者们往往沉浸于应用和系统功能带来的直接价值和“前卫”效果，而容易忽略这些场景应用下的底层技术支撑。

实际上，在医院的生产环境中，作为提供这些应用效果所需数据和信息交互的核心中间件，集成平台实际上已成为全院信息化的“大动脉”，其重要性已经上升到与HIS、电子病历等核心系统的同等高度。一个优秀的集成平台，必须体现出对各种集成业务的解决能力、平稳不间断的性能输出能力、可靠坚实的容灾保障能力等。

这些对于集成平台的能力需求，都使得底层中间件架构面临严峻挑战。对集成平台进行底层架构的重新定义，就成为了“破局”方式之一。对于那些每日业务量超过百万级的集成平台而言，采用单/双机作为底层架构是否还合适？笔者的看法是：不合适了！

如图1所示，目前笔者所在医院集成平台每日消息量已超过300万次，采用的架构方式是利用多台服务器构成集群，共同处理所有医院内的业务项目，任务分布到多台服务器上同时运行，集成引擎能实现对各类任务需求特征的自动区分，并进行不同的预处理，再由负载均衡功能进行工作任务的动态迁移。

该方案能实现管理配置、生产作业、数据存储的分离，利用合理的技术架构实现一处配置、多点生产、数据一致的效果，同时具有统一配置的监控管理界面。当出现异常时，集群架构能自动侦测并在其他服务器（节点）自动启动该任务的模块来进行处理，实现业务服务的自动故障转移，从架构上避免了单点故障的风险。集群还能进行动态扩展，更好地保证集成平台的高可用性。