傳統集成平臺面對快速增長的業務需求常常出現性能瓶頸，也使上述常見的問題和抱怨成為了醫院和HIT廠商對于集成平臺性能的“靈魂拷問”。

據統計，三級醫院每天要處理的消息總量都在百萬量級。假設一家大型三甲醫院每天需要處理900萬消息請求，以每天10小時作為集成平臺的核心工作時間，如果全部走平臺的話，可得出中間件(集成引擎)平均每秒處理的數據為:

9,000,000/10/3600=250；

即中間件(集成引擎)平均TPS(每秒事務數)為250能滿足日均900萬量級的消息請求。

但考慮到醫院的運行峰值對性能要求會更高，相對嚴謹一些則基于“二八原則”(二八原則：每天80%的請求數量集中在20%的時間段里，這20%的時間即為醫院峰值)，估算出醫院運行峰值時中間件(集成引擎)的極限TPS為：

(9,000,000×80%)/(10×3600×20%)=1000；

即使刨去消息頭大小限制，醫院消息在復雜場景下需要落盤儲存或異步處理等影響因素，理想情況下日均900萬消息處理數量級的醫院理論上也需要中間件(集成引擎)極限TPS達到1000才能滿足醫院峰值時的穩定運行,這個性能是一般普通的單機架構中間件(集成引擎)難以達到的。因此現在很多醫院只能將部分系統的數據集成通過中間件(集成引擎)處理。

那三級醫院集成平臺該如何面對海量高并發消息的毫秒級延遲需求？本文將從中間件(集成引擎)架構設計的角度，聊一下不同架構下的中間件(集成引擎)性能。

單機架構：單機性能存在瓶頸，垂直擴展提升有限

單機架構一般每秒能同步處理數百條消息，如果數據有順序要求，不能并行處理，需要落盤儲存，則在這部分業務場景中TPS僅有幾十。

醫院通常的解決辦法是提升硬件配置 (如CPU從8核變成16核)。除此之外，中間件(集成引擎)還可以通過其它功能設計更好地提升單機性能：如內置的內存數據庫、添加分布式緩存等設計，減少與外部I/O交互，提高數據獲取速度。

但以上方法并不能解決單機架構的致命缺點—單機性能存在極限。因此，想進一步提升集成平臺性能，就需要改變現有中間件(集成引擎)的單機架構模式。

傳統集群架構：滿足當下醫院需求的方案

這里的傳統集群架構是指在產品設計時根據醫院平臺的業務特點原生實現的集群架構，并非單機系統部署在多臺虛擬機上形成的“集群”(其核心仍是單機架構)。

為什么說傳統集群架構可以滿足當下醫院需求，因為它滿足了實現高性能的兩個重要條件：

通過集群架構實現橫向擴展，并通過負載均衡實現合理的動態任務分配機制后，傳統集群架構的集成平臺TPS能達到數千。 

傳統集群架構的局限性

然而，傳統集群架構只能以服務器為單位進行橫向擴展，很多情況下擴展的服務器中只有個別應用資源會被使用到，因此和下面即將提到的云原生集群方案相比資源利用率低很多。同時隨著服務器的增加，對于集群節點管理和調度的難度也會大幅上升，對性能提升的幅度會越來越少。

云原生集群：著眼未來的前瞻性方案

除了傳統集群，現在也有針對醫聯體和集團化醫療機構的基于K8s等容器化技術實現的云原生集群。云原生是未來醫院業務快速變化背景下的必然技術趨勢，而支撐起云原生集群的就是Kubernetes容器編排和以Docker為代表的容器技術。

任務進程監管粒度更細，突破傳統集群局限

和傳統集群相比，融入最新容器技術的云原生集群進一步深化了傳統集群架構的技術特點。容器作為實現微服務的最佳載體，能對服務器中的運行的任務一一進行更細致的監控和管理，這是傳統集群架構中所不能實現的。這種監控管理粒度上的突破使云原生集群打破了傳統集群架構的性能局限，具體可以體現在以下三點：

醫院集成平臺建設是一個長期持續性的建設過程。醫院選擇集成平臺時，應結合自身當下以及未來的需求，尋找有能力集成更多核心業務，承載更大交易量的高性能集成平臺，為醫院今后持續加強集成的廣度和深度打好堅實基礎。