集成平台发展“四部曲”：直面高可用、高性能的业务挑战

来源：HIT专家网      作者：龚晨

集成平台的建设是医疗信息化领域近年来的热点话题。HIT专家网近期通过访谈多位医疗机构信息主管了解到，关于集成平台的建设、应用问题，医院信息中心的顾虑与担忧主要表现为以下几个方面：

一是关切平台自身的可靠性问题。“最担心集成平台‘崩’，原因是业务系统与集成平台的数据交互越来越紧密，一旦平台发生故障，影响面实在太大。”

二是顾虑平台接入的第三方服务生态质量问题。“担心集成平台的性能不足，平台需要对接众多质量不可控的第三方服务，高峰期业务量过大时，如果第三方业务出现卡顿，就会出现数据传输延迟或者消息积压，严重时可能拖累整个平台并造成停摆。”

三是担心集成平台的易用性与后续运维问题。“产品的成熟度与标准化程度如何，易用性如何？后续医院信息中心能否自主使用、自主运维？”

四是关心集成平台的使用成本和明确成熟的升级路线图问题。“不仅仅是平台的购买成本，还包括实施、运维、升级、数据存储等成本，以及后续升级迭代的成本和频繁打补丁的困局。”

CHIMA副主任委员薛万国近期公开撰文《小议“平台”》，强调平台即服务，平台建设需要关注的点包括：平台的目标与定位、平台的标准与共识、平台的长久稳定。

整体而言，医院信息中心对于集成平台选型建设的关注点一方面“立足现在”，也即满足现阶段医疗机构的实际集成业务需求，其中平台的稳定性与性能是他们最为关注的问题；另一方面是“放眼未来”，由于集成平台属于“基建投资”，除满足一时、一地的需求外，还需要具有技术上的前瞻性与包容性，以满足未来新系统、新业务的对接与融入需求。

作为一家平台提供商，Odin Health公司深刻理解医疗机构在信息化建设不同发展阶段对集成平台产品的能力需求，Odin集成引擎系列产品历经发展演进的“四部曲”，帮助医疗机构建好、用好集成平台，直面高可用、高性能的集成业务挑战。

【1】首创“三合一”概念，提升平台易用性

Odin公司通过对于行业的研究发现，借助传统、单一的技术性集成方式，如ETL、MQ、文件IO、点对点等方式实现的数据交换，覆盖的集成场景有限，大约仅为40%-70%，因此在2014年首次提出集成平台“三合一”、面向场景的架构理念，并将此理念贯穿产品始终。

“三合一”是Odin针对复杂的医疗信息集成需求，为帮助医疗机构更好地使用集成平台而进行的重要创新。医疗机构用户无须购买其他产品，即可在一个系统中通过统一的Web界面实现集成、ESB服务协调、数据抽取转换上报（ETL）三大能力，覆盖医疗机构90%以上的集成场景，大大降低了医疗机构二次开发或采购其他系统进行补充带来的额外成本和开销。

为进一步提升集成引擎的易用性，Odin进行了大量本土化开发与细节优化工作。用户能通过纯Web界面方式在一个界面完成设计、开发、测试、监控、运维等集成业务全流程；在1分钟内完成所有组件的一键快速安装，即开即用；还能够利用引擎提供的丰富的数据处理组件和灵活的服务编排能力，通过Web图形化拖拽式操作方式，快速上手、实现业务。

【2】适合二、三级医院的Odin引擎 AlwaysOn企业版：大幅提升稳定性，实现“持续在线”

基于“三合一”、面向场景的架构理念，以及用户对容灾的切实需求，Odin通过技术优化与功能提升，推出新一代面向场景型的AlwaysOn企业版新产品。AO意为：Always On（持续在线），这是Odin针对医疗机构最为关心的平台稳定性问题给出的解决方案。

传统的冷备方式需要人工接入，恢复时间需要十几分钟甚至数小时；HA热备方式虽然可实现自动化，切换效率仍然不够高，恢复速度需要数分钟，与医疗机构在实时业务上的无感知要求相比还有一定距离。

从架构上看，Odin AO版产品内置主备容灾环境，无需依托任何外部高可用技术，即可实现主备服务的同时在线与无感知切换，切换时间可控制在亚秒级别。

从功能上看，Odin AO版产品引入“服务熔断与降级”和内存保护技术等。其中，“服务熔断与降级”能避免因单个第三方服务的效率问题“拖累”整个平台的可用性，内存保护技术则能避免因单次读取量太大导致内存暴增，影响其他业务的正常运行。此外，产品中还包括重置机制、日志跟踪和分析功能等全过程管理机制，确保集成平台的“持续在线”。

【3】适合大三甲和集团化医院的Odin引擎集群版：承载百万量级消息吞吐，支持多院区一体化建设

当前，大型医疗机构普遍处于多院区、集团化的发展阶段，面向更大规模、更广范围的业务进行一体化管理成为“刚需”。从互联互通新版测评方案来看，从“四甲”到“五乙”，医疗机构对内接入系统数量要求从31个增至54个，对外数据交互种类与数量也有更高要求。这对医疗机构的互联互通能力提出了新的挑战。从业界实践的情况来看，许多大型医疗机构集成平台的日消息吞吐量已达百万级甚至千万级。

在大规模集成业务的实际应用中，集成平台的高可用性与容灾策略问题被放在重要位置上，传统“双活”或“多活”方式受限于架构本身，一般采用部署多套单机通过负载均衡方式实现。这种方式虽然可以在一定程度上获得性能优势，但在开发和运维管理上增加了许多难度和运行风险：一是由于数据分散在不同系统，无法进行全局统一管理，需要人工对多台系统配置进行同步，万一有遗漏会引发业务错误；二是缺乏统一的监控机制，当有异常发生时无法及时恢复和修正，造成业务运行的不稳定。

为此，Odin推出一体化集群式架构（界面/监管/运维等一体化），对于大型医疗机构在可用性、并发性、稳定性、鲁棒性等诸多需求的应对上，提供了更具前瞻性和领先性的解决方案。

在浙江省台州医院，Odin集群版帮助平台冲破日消息量300万次的性能瓶颈，其平稳不间断的性能输出能力、可靠坚实的容灾保障能力确保了全院信息化“主动脉”的畅通。由于Odin集群版具有统一配置的监控管理界面，当出现异常时，集群架构能自动侦测并在其他服务器自动启动该任务的模块进行处理，实现业务服务的精细化转移，从架构上避免了单点故障的风险；还能进行统一的API网关管理，帮助IT管理者清晰看到各接口之间的调用关系，实现对系统间调用的服务鉴权、访问管控。

在资源利用方面，热备、双/多活灾备方案的硬件资源利用率平均在40%-50%，而Odin一体化集群按需负载、应需扩展的特点可为医院大幅度提升IT资源的利用效率，整体可达80%以上。

【4】Odin NeXT云原生平台：面向未来云环境的集成技术“准终局形态”

医疗健康行业的信息化建设正逐步向大规模区域协同、云计算、大数据智能化等特点发展。无论是各级区域全民健康信息平台，还是正在火热建设中的医联体、医共体等，以及“健康城市”等，未来都可能面对每天数以千万甚至上亿级别的数据处理和调用请求，这要求集成平台必须提供更强大的横向扩展能力，以满足海量数据的处理需求。

在对业务系统稳定性有着极致要求的金融、互联网等行业，云原生架构早已不是新鲜事物。谷歌、亚马逊、阿里、腾讯等IT巨头公司都已使用云原生架构。而在医疗健康领域，Odin开创性地将云原生融入中间件架构，开发基于微服务的分布式容器化引擎——分布式云原生数据服务平台Odin NeXT（New generation eXchange Technology）。

Odin NeXT不是简单地在K8S上进行产品部署和使用，而是和K8S在底层进行接口对接交互，与K8S形成融合。在业务集成过程中，通过Odin的Web图形化配置界面即可直接获得云原生能力，满足未来云环境下的API微服务化、动态性能延展、灰度发布、单集成业务强隔离等需求。

Odin NeXT的使命是帮助区域平台、医联/共体、健康城市等大型跨机构医疗组织形态应对云计算环境下医疗健康服务和应用的新挑战。

Odin NeXT已于2021年5月在新西兰ALEX（Application Layer EXchange）平台项目中落地使用，涵盖新西兰全国90%以上的初级医疗数据，此项目被誉为“全球首个基础医疗数据互操作平台”。Odin NeXT云原生平台作为其核心数据交换中间件，采用FHIR API技术实现了各类医疗数据和记录在多个应用程序、全科医生、患者、保险公司之间的实时、安全的共享和互操作，具有极高的快速响应下的并发能力、极强的业务稳定性以及实时动态扩展能力。

纵观Odin集成引擎系列产品的发展路线图，始终围绕着“场景化、高可用、高性能”等医疗机构最为关注的核心问题，在技术创新引领应用创新这条主线上超前布局，使得其平台产品能够在大规模集成应用实践中不断突破。

同时，Odin各级产品之间是继承与发展的关系，可满足不同业务规模、不同发展阶段的医疗机构需求。比如，随着集成业务的纵深发展，当医疗机构原有的Odin引擎AO版无法满足现有需求时，可升级至Odin引擎集群版乃至Odin NeXT，从而有效保护IT基础投资，避免“补丁”问题。

【责任编辑：秦勉】