大型医院、区域级集成平台的首选——新一代集群架构中间件

摘要： 

医疗机构对医疗信息化日益重视，国家合规评测要求不断提高，集成平台的集群架构日显重要。 选择具备什么功能的数据交换集成中间件来实现集成平台的集群架构，成为日后平台满足现有需求并可持续发展的关键。 

本文重点介绍了集成平台数据交换集成中间件的新一代集群化特点及技术难点，同时也对未来数据交换技术的架构进行了阐述，并为医疗机构选型提供了参考。 

在医院集成平台的建设中，其核心组件“集成平台的数据交换集成中间件”（以下简称“数据集成中间件”），常会面临性能和容灾能力不足等痛点，有些医院采用热备解决容灾问题，但仍存在单点故障和性能瓶颈问题； 有些医院采用了双活或多活架构缓解了性能问题，但对消息处理顺序有要求的场景无法支撑 ，另外也缺乏单点登录，统一监控和管理功能。 

随着技术革新，兼顾性能、容灾和管理的新一代集群架构开始备受关注。 

1. 传统解决方案的缺陷 

在医疗行业中，传统ESB虽可实现集群但无法支持消息顺序性，可通过补偿方案解决，但缺乏医疗属性； 传统集成引擎虽然支持消息顺序性但缺少集群功能，当然也可通过补偿方案解决，但集群的"颗粒度"粗; 随着日后对平台要求不断提高，上述二种方案翻倒重来的风险也日益增大。 能克服上述缺陷的数据集成中间件的难点和特点是什么？ 

2. 数据集成中间件新一代集群架构之技术难点 

难点一： 集群架构中如何实现集成模式下的项目独立性 

集成模式主要用于处理对消息顺序有需求的请求和业务。 

在医疗行业中，传统ESB能虽可实现集群但无法支持消息顺序性（即ESB自身不具备集成模式）； 而传统集成引擎有集成模式但缺少集群功能。 这两种中间件均需要通过补偿方案（比如引入额外系统或大量技术改造等）解决。 

实现数据集成中间件自身集群功能，同时保证消息顺序性和项目独立性，是主要的技术难点之一。 

难点二： 如何实现出现异常时无感知切换 

由于业务性质不同，集成平台需要处理各种集成场景，有“请求-应答”型（如医院挂号号源查询），有“数据抽取”型（如CDR数据同步），有“单一事务”型（如检验检查申请确认），也有“混合”型等。 

一旦发生业务异常或出现故障时，如何进行快速切换并保证这些集成业务感知不到切换而且消息不丢包，是数据集成中间件实现集群的又一难题。 

难点三： 如何做到多服务器下的统一运维监控管理 

由于集群由多台生产服务器构成，运行时，消息、操作数据、日志等都分布在不同服务器上，如何有效整合、实时监控和远程管理也是一个技术挑战。 

想象一下在进行某条消息的查询时，如果是传统负载均衡的多活方式下，由于缺少统一监控，运维人员需逐个对服务器，运气好一下能找到，运气不好可能找到最后一台才发现，另外带来的就是统计数据的割裂需合并计算，费时费力还不准确。 

实现单点登录、统一监控，可以降低运维难度，提高监控可及能力，这对于新一代集群架构的数据集成中间件至关重要。 

3. 数据集成中间件新一代集群架构之主要特点 

3.1 亚秒级切换的容灾能力和业务保障力  

集群方案中多台服务器同时运行业务。 即使某个业务出现故障，也能由其他服务器无缝进行业务接管，避免了单点故障导致的业务中断，保证业务的持续运行。 

3.2 统一监控 + 多台生产节点的可扩展能力 

集群范围内有多台服务器构成，共同承担业务。 每台服务器就叫做这个集群的一个“节点”，每个节点承担集成业务的计算和执行。 

集群方案中需要有中央监控服务器，该服务器不参与实际生产，而是负责监控所有集群中的服务器，这样运维人员能通过一个统一的界面实现对所有服务器消息流转等状态的监控，日常的运维管理更加便捷。 

3.3 具备微服务化的API Gateway管理 

微服务、业务中台、互联网+等新兴技术应用逐年提升。 CHIMA最新的调查报告显示，经济发达地区大部分医院终端总数在500以上，部分三级医院对接终端数更是超过1000个。 

API Gateway 作为这些技术的直接体现和实现组件，API的发布、鉴权、流控等功能将会凸显其重要性。 接收、整合、处理客户端请求数据中间件服务的API管理工具，可无需二次开发就能够实现API同集成服务的绑定。 

3.4 具有灵活的部署策略和精细化的资源配置 

集成项目发布到生产服务器运行，可根据各集成业务的特点选择性的部署到指定某个或某类特性的服务器上，能更充分地利用集群各服务器的资源优势。 

例如，某医院有A、B两个院区，A院区的服务器性能更好，那么有的集成业务对性能要求高的则可选择部署在A院区服务器，要求不高的放在B院区运行，以此实现合理的资源分配和管理。 

3.5 开发测试:纯WEB界面的多用户同时编辑 

对于有着一定规模的医院信息化团队，经常会多人同时上线实现一些集成平台的功能拓展和二次开发。 集群架构的集成平台性能上轻松支撑多人同时在线开发，同时也需要在功能上分离生产和开发环境，提供纯WEB的开发界面和规范的DevOps流程管理，保证项目被审核确认后才会被部署至生产环境，降低生产环境的运行风险。 

4. 未来数据集成中间件集群化架构的方向 —— 分布式、云原生  

随着云计算普及和医疗机构数据云化，集群架构需要探索更能发挥云计算特性和优势的技术路线，分布式云原生集群应运而生，也可能成为数据集成中间件的准终局形态。 

分布式云原生集群有如下特点： 环境切割、项目原子级隔离、资源定向分配、弹性延展、架构级微服务、灰度更新发布等。 

基于最新容器编排技术Kubernetes (K8s)的PaaS层云原生分布式集群架构，通过容器化技术来提供高可用、高并发、高性能、低延迟的云平台，并进一步实现了自身架构级的微服务化，能充分展现微服务和云原生的特性及优势，真正发挥数据集成中间件在PaaS云计算环境下的动态调动、弹性延展、精细化资源配置等特性。 

分布式云原生架构在面对支撑超大规模集成时将更会游刃有余，而这些能力也都是传统中间件架构所无法企及的。 

5. 医疗机构怎样选择合适的架构呢？ 

需要从业务量、集成场景、测评要求、未来规划等多方面综合考量。 

集成平台在下列情况下 可考虑采用集群架构的数据集成中间件： 

• 支撑核心业务交换 
• 日业务量超过百万级 
• 高容灾诉求 

这些场景最好采用集群： 集团化医院、医共体和医联体、区域等的集成。 

如果有PaaS运维能力，上规模的集成并且具有很好的云环境， 应该考虑采用分布式云原生的架构。 

案例一： 国内集团化医院 -  浙江省台州恩泽医疗中心（集团），日均处理数据在百万量级，几百个集成业务，60%以上的核心业务交换，中间件采用1+2+5的集群架构。 

案例二： 国际上“首个基础数据医疗平台” -  全部采用FHIR API的ALEX项目，于2021年5月上线，依托Microsoft Azure云环境为IaaS层，项目覆盖新西兰 90% 以上基础医疗数据和机构，采用了分布式云原生的集群架构。