关键字
冷备、热备、集群、负载均衡、故障转移、可用性、高性能
导读
2020年，由于疫情催生出如互联网诊疗等信息化集成需求以及最新的互联互通标准化成熟度测评方案等政策的出台，对三级医院集成平台在高可用和高性能等方面提出了更高的要求。
冷备、热备、集群是医院实现集成平台高可用的主流选择。 然而，由于冷备和热备方案难以实现高性能，使医院一方面不敢冒着集成平台卡顿甚至宕机的风险接入核心业务，另一方面又面对着政策和患者需求的步步紧逼，陷入了进退两难的境地。
因此，集群方案就成了医院实现集成平台高可用和高性能的首选方案之一，那集群方案有哪些实现方式，它们之间又有哪些区别呢？
方式一： 集成平台中间件不具备集群架构，通过单机系统部署在多台虚拟机上实现的"集群方案"
有些集成平台的中间件基于单机架构设计，自身不具备集群架构。 但由于医疗信息化发展迅速，而许多数据集成产品的架构无法适应这种发展，许多厂商不得不勉强用单机系统部署多台虚拟机的方式实现“集群”，辅以第三方硬件或软件来应对三级医院集成平台需要兼顾高可用和高性能的诉求，常见选择如下：
利用Windows故障转移功能实现高可用
这种实现方式中，其中一种应用模式就是两台服务器同时运行并共用一个SAN（即存储区域网络）上的数据文件（包括配置文件，消息数据等），在主服务器发生异常状况时，存储在SAN盘上的数据文件理论上不受影响，启动备用服务器后，备用服务器能从共用的SAN里对数据进行读写操作，接管业务，恢复工作，但会造成短暂的服务中断。 这种模式下， 备用服务器在主服务器正常运行中处于停工状态，只有当主服务器出现异常关闭后才会启动运行。
这种实现方式的优缺点如下：
优点：
- 配置简单
- 能自动切换
- 由于两台服务器共用SAN，不需要手动同步服务器的 数据
缺点：
两台服务器不能同时读写
同时读写会导致存储资源里的共享数据文件出错，共享数 据文件出错后即使服务器即使进行了故障转移备机服务也 无法启动。
切换时间慢
由于不能同时读写，因此需要保证在切换时一个Windows 服务完全关闭，另一台Windows服务才能开始启动，切换 时间在分钟级。
需要做好对SAN的冗余和灾备工作
由于该方案中服务器共用一个SAN,一旦负责存储的区域 出现物理损伤或逻辑出错，服务器之间的故障转移功能就 不能发挥作用。
只能在部分情况实现“高可用”，颗粒度不够细
当服务器自身出故障时或Windows服务（集成引擎）停止 时才可以进行故障转移，但是如果应用程序（集成引擎） 的Windows服务仍在运行，而应用程序（集成引擎）其中 的某些模块或业务服务出现故障时，该方案就很难做到故 障转移。
因此这类通过Windows故障转移功能实现的高可用本质上是一种颗粒度很粗的“热备”方案，并非真正意义上的集群。
通过负载均衡功能构建“集群”体系
在这种方式中，多台服务器同时工作提供相同的服务，且服务器之间没有主备之分，通过负载均衡器进行消息的分发，一旦某台服务器出现故障则负载均衡器会停止对该故障服务器发送消息，工作量将会被其它服务器平均分担，等故障被排除服务器重新加入集群处理业务，恢复正常运作(如下图）。
这种实现方式的优缺点如下：
优点：
- 高可用： 多台服务器同步并行处理，集群中某 个服务器中的服务出现故障时，能通过负载均衡 器分担相应业务，由其它服务器中正常运行的服 务来承担。
- 避免切换服务器： 不用切换故障服务器也能保 证业务的持续运行，避免了切换时出错的风险和 切换速度慢等弊端。
- 能实现高性能： 多台服务器同步并行处理消 息，整体性能高
缺点：
只能应用于服务型的场景
通过负载均衡实现的集群确实能同时实现高可用 和高性能，然而该方案也存在着一些缺陷，因为 是由多台服务器同步并行处理消息，所以不能保 证消息处理顺序，(譬如消息按1、2、3的顺序从 外部传入，但处理时可能会按3、1、2的顺序完 成)，因此这样的方案只能适用于对消息处理顺序 没有要求的服务型场景，即外部主动访问请求类 的场景。
然而医院集成平台除了服务型场景外，还需要处 理对于消息处理顺序有严格要求的场景（如基于 HL7进行数据交换的场景）以及数据抽取型的场景 （ 如ETL），在ETL场景中，如果多处同时抽取数 据库数据可能会造成数据混乱或数据库死锁的问 题，上述两个场景都不能通过多台服务器同步并 行处理。
服务器配置管理繁琐
配置内容增删改后，必须实时手动对所有服务 进行配置同步，否则会出现不同服务器配置不 一 致的问题，导致处理数据出错，影响医院业务。
监控管理困难
由于多台服务器同时处理业务，无统一监控界 面，对于业务的追踪监控，数据的搜索也往往需 要对多个服务器分别搜索查找。
这种“集群”从本质上来说是物理上N台，逻辑上也是N台的“多机多活”实现方式，并非真正意义上的集群。
针对“只能应用于服务型场景”的缺点， 也有厂商提出了如下解决方案：
多台服务器构成集群共同处理所有业务场景，但会根据场景的特征手动进行分发，不同服务器分别处理不同业务，对消息处理顺序有严格要求的工作或ETL仅安排单台服务器运行，使集成平台能满足医院大部分业务场景需求，并借由负载均衡器实现了部分高性能的功能。
这种实现方式也存在如下问题：
存在单点故障：
由于场景的特征限制，只能由单个服务器处理的 场景仍存在单点故障问题。 出现故障时也不能自 动切换，需要手动处理由其他服务器接管。
任务运行管理不便：
需根据不同任务类型手动启动或关闭任务，容易 出现错漏。
传统的ESB集群方案：
另外还有一种是传统的ESB集群方案，但这种集群一般适用于服务型场景的高可用和高性能需求，对于非服务型场景（如异步数据交换和数据库抽取数据）仍然难以处理。
如何解决上述方案的缺点，更好达到医院高可用和高性能的需求，提供符合医院多种业务需求的集群方案？
方式二： 集成平台中间件在设计时就根据医院平台的业务特点原生实现的集群架构
不同于上述方案中由单机系统部署在多台虚拟机上形成的集群(其核心仍是单机架构)，Odin引擎集群版在设计时根据医院平台的业务特点原生实现集群架构，这种集群可以概括为物理上 N 台，逻辑上 1 台，在产品架构上有本质的不同。
在Odin引擎集群版的运行过程中，多台服务器构成集群共同处理所有医院内的业务项目，任务能分布到多台服务器上同时运行，引擎能实现对各类任务需求特征的自动区分（服务型/数据抽取型/对消息处理顺序有要求的场景）并做不同的预处理，再由负载均衡功能进行工作任务的动态迁移。 该方案能将管理配置、生产作业、数据存储的分离，利用合理的技术架构实现 一处配置、多点生产、数据一致的效果，具有 统一配置监控管理界面。
Odin的集群方案有如下优点：
具有高可用性，且颗粒度细
多台服务器同步并行处理服务型任务。 数据抽取型（ETL）和对消息处理顺序有要求的任务在单个服务器中运行，当模块出现异常时，集群能自动侦测到异常并在其它服务器(节点)自动启动该任务的模块来进行处理，实现业务服务的自动故障转移。 集群并可进行动态扩展，更好地保证高可用性。
高性能
在设计时自带的集群架构能提升系统整体的处理能力(包括更高的TPS、更大的吞吐量、更多的并发数、更快的响应时间等)，再经由负载均衡提供高效合理的动态任务分配机制进一步提升了系统的总体运行效率，能在医疗数据应用场景中保证系统的高性能。
满足了医院几乎所有业务场景需求
对不同场景，如服务型/数据抽取型/对消息处理顺序有要求的场景，进行不同设计处理。 系统会根据各类任务需求的特征进行动态任务分配和管理。
易用性高
该集群方案还能将处理不同项目的服务器整合至一个逻辑接口，实现了 一处配置、多点运行、数据一致的效果，统一配置监控管理界面，在一个页面中实现项目追踪、项目监控以及日常消息检索等功能，操作更加便捷，易用性高。
【结语】
随着信息化程度的提升，集成平台的高可用日益重要，一旦出现服务器宕机或集成引擎应用服务中断，会大面积影响医院业务的正常运作。 Odin引擎的原生集群架构，在满足医院各种复杂业务场景需求的前提下还兼具高可用、高性能和易用性，为医院信息平台安全和稳定运行保驾护航。
Odin文章评论：