摘要

醫療機構對醫療信息化日益重視，國家合規評測要求不斷提高，集成平臺的集群架構日顯重要。選擇具備什么功能的數據交換集成中間件來實現集成平臺的集群架構，成為日后平臺滿足現有需求并可持續發展的關鍵。

本文重點介紹了集成平臺數據交換集成中間件的新一代集群化特點及技術難點，同時也對未來數據交換技術的架構進行了闡述，并為醫療機構選型提供了參考。

在醫院集成平臺的建設中，其核心組件“集成平臺的數據交換集成中間件”（以下簡稱“數據集成中間件”），常會面臨性能和容災能力不足等痛點，有些醫院采用熱備解決容災問題，但仍存在單點故障和性能瓶頸問題；有些醫院采用了雙活或多活架構緩解了性能問題，但對消息處理順序有要求的場景無法支撐 ，另外也缺乏單點登錄，統一監控和管理功能。

隨著技術革新，兼顧性能、容災和管理的新一代集群架構開始備受關注。

傳統解決方案的缺陷

在醫療行業中，傳統ESB雖可實現集群但無法支持消息順序性，可通過補償方案解決，但缺乏醫療屬性；傳統集成引擎雖然支持消息順序性但缺少集群功能，當然也可通過補償方案解決，但集群的"顆粒度"粗; 隨著日后對平臺要求不斷提高，上述二種方案翻倒重來的風險也日益增大。能克服上述缺陷的數據集成中間件的難點和特點是什么？

數據集成中間件新一代集群架構之技術難點

難點一：集群架構中如何實現集成模式下的項目獨立性

集成模式主要用于處理對消息順序有需求的請求和業務。

在醫療行業中，傳統ESB能雖可實現集群但無法支持消息順序性（即ESB自身不具備集成模式）；而傳統集成引擎有集成模式但缺少集群功能。這兩種中間件均需要通過補償方案（比如引入額外系統或大量技術改造等）解決。

實現數據集成中間件自身集群功能，同時保證消息順序性和項目獨立性，是主要的技術難點之一。

難點二：如何實現出現異常時無感知切換

由于業務性質不同，集成平臺需要處理各種集成場景，有“請求-應答”型（如醫院掛號號源查詢），有“數據抽取”型（如CDR數據同步），有“單一事務”型（如檢驗檢查申請確認），也有“混合”型等。

一旦發生業務異?；虺霈F故障時，如何進行快速切換并保證這些集成業務感知不到切換而且消息不丟包，是數據集成中間件實現集群的又一難題。

難點三：如何做到多服務器下的統一運維監控管理

由于集群由多臺生產服務器構成，運行時，消息、操作數據、日志等都分布在不同服務器上，如何有效整合、實時監控和遠程管理也是一個技術挑戰。

想象一下在進行某條消息的查詢時，如果是傳統負載均衡的多活方式下，由于缺少統一監控，運維人員需逐個對服務器，運氣好一下能找到，運氣不好可能找到最后一臺才發現，另外帶來的就是統計數據的割裂需合并計算，費時費力還不準確。

實現單點登錄、統一監控，可以降低運維難度，提高監控可及能力，這對于新一代集群架構的數據集成中間件至關重要。

數據集成中間件新一代集群架構之主要特點

1.亞秒級切換的容災能力和業務保障力

集群方案中多臺服務器同時運行業務。即使某個業務出現故障，也能由其他服務器無縫進行業務接管，避免了單點故障導致的業務中斷，保證業務的持續運行。

2.統一監控 + 多臺生產節點的可擴展能力

集群范圍內有多臺服務器構成，共同承擔業務。每臺服務器就叫做這個集群的一個“節點”，每個節點承擔集成業務的計算和執行。

集群方案中需要有中央監控服務器，該服務器不參與實際生產，而是負責監控所有集群中的服務器，這樣運維人員能通過一個統一的界面實現對所有服務器消息流轉等狀態的監控，日常的運維管理更加便捷。

3.具備微服務化的API Gateway管理

微服務、業務中臺、互聯網+等新興技術應用逐年提升。CHIMA最新的調查報告顯示，經濟發達地區大部分醫院終端總數在500以上，部分三級醫院對接終端數更是超過1000個。

API Gateway作為這些技術的直接體現和實現組件，API的發布、鑒權、流控等功能將會凸顯其重要性。接收、整合、處理客戶端請求數據中間件服務的API管理工具，可無需二次開發就能夠實現API同集成服務的綁定。

4.具有靈活的部署策略和精細化的資源配置

集成項目發布到生產服務器運行，可根據各集成業務的特點選擇性的部署到指定某個或某類特性的服務器上，能更充分地利用集群各服務器的資源優勢。

例如，某醫院有A、B兩個院區，A院區的服務器性能更好，那么有的集成業務對性能要求高的則可選擇部署在A院區服務器，要求不高的放在B院區運行，以此實現合理的資源分配和管理。

5.開發測試:純WEB界面的多用戶同時編輯

對于有著一定規模的醫院信息化團隊，經常會多人同時上線實現一些集成平臺的功能拓展和二次開發。集群架構的集成平臺性能上輕松支撐多人同時在線開發，同時也需要在功能上分離生產和開發環境，提供純WEB的開發界面和規范的DevOps流程管理，保證項目被審核確認后才會被部署至生產環境，降低生產環境的運行風險。

未來數據集成中間件集群化架構的方向——分布式、云原生

隨著云計算普及和醫療機構數據云化，集群架構需要探索更能發揮云計算特性和優勢的技術路線，分布式云原生集群應運而生，也可能成為數據集成中間件的準終局形態。

分布式云原生集群有如下特點：環境切割、項目原子級隔離、資源定向分配、彈性延展、架構級微服務、灰度更新發布等。

基于最新容器編排技術Kubernetes (K8s)的PaaS層云原生分布式集群架構，通過容器化技術來提供高可用、高并發、高性能、低延遲的云平臺，并進一步實現了自身架構級的微服務化，能充分展現微服務和云原生的特性及優勢，真正發揮數據集成中間件在PaaS云計算環境下的動態調動、彈性延展、精細化資源配置等特性。

分布式云原生架構在面對支撐超大規模集成時將更會游刃有余，而這些能力也都是傳統中間件架構所無法企及的。

醫療機構怎樣選擇合適的架構呢？

需要從業務量、集成場景、測評要求、未來規劃等多方面綜合考量。

集成平臺在下列情況下可考慮采用集群架構的數據集成中間件：

這些場景最好采用集群：集團化醫院、醫共體和醫聯體、區域等的集成。

如果有PaaS運維能力，上規模的集成并且具有很好的云環境，應該考慮采用分布式云原生的架構。

案例一：國內集團化醫院 - 浙江省臺州恩澤醫療中心（集團），日均處理數據在百萬量級，幾百個集成業務，60%以上的核心業務交換，中間件采用1+2+5的集群架構。

案例二：國際上“首個基礎數據醫療平臺”—全部采用FHIR API的ALEX項目，于2021年5月上線，依托Microsoft Azure云環境為IaaS層，項目覆蓋新西蘭 90% 以上基礎醫療數據和機構，采用了分布式云原生的集群架構。

附浙江省臺州醫院集成平臺應用案例相關鏈接：

1.https://www.hit180.com/52393.html

2.https://www.hit180.com/53074.html