在一個普通的早高峰時段，一個急促的電話打破了醫(yī)院信息中心的平靜：“自助機卡住了，很多患者在抱怨，怎么辦?”

接到電話后，負責HIS、集成平臺、自助機等項目的技術人員馬上開始排查問題。

“自助機響應超時，偶有鏈接斷開。”“HIS接口響應較慢，但未看到有錯誤?！薄凹善脚_信息處理速度慢，導致隊列擠壓超時?！?/span>

20分鐘后，三方技術人員匯總并確定了問題：集成平臺由于某個項目的請求量突發(fā)增高，后續(xù)系統(tǒng)處理跟不上，導致其他調(diào)用無法請求。

處理方法：關停此集成業(yè)務，業(yè)務恢復。

事情解決了，但背后的問題卻值得深思。智慧醫(yī)院建設不斷向前，越來越多的應用和場景已打破了原有點對點的數(shù)據(jù)交換方式，轉(zhuǎn)而通過醫(yī)療信息集成平臺來實現(xiàn)消息的流轉(zhuǎn)和分發(fā)，獲取更加靈活、標化和可控的互操作能力。同時，醫(yī)院在業(yè)務層面也更加重視通過自助機和各類線上應用等手段，為患者提供更加優(yōu)質(zhì)便捷的服務。

當集成平臺的技術無法適應快速增長的信息化應用對集成和互操作的需求時，那么就會引發(fā)一次又一次這樣的信息“災難”。應該怎樣有效避免類似情況的發(fā)生呢？

浙江省臺州醫(yī)院信息中心 劉祉呈

就像有人買車更多看重外觀動力和內(nèi)飾，并不在意發(fā)動機一樣，醫(yī)療信息集成平臺的使用者們往往沉浸于應用和系統(tǒng)功能帶來的直接價值和“前衛(wèi)”效果，而容易忽略這些場景應用下的底層技術支撐。

實際上，在醫(yī)院的生產(chǎn)環(huán)境中，作為提供這些應用效果所需數(shù)據(jù)和信息交互的核心中間件，集成平臺實際上已成為全院信息化的“大動脈”，其重要性已經(jīng)上升到與HIS、電子病歷等核心系統(tǒng)的同等高度。一個優(yōu)秀的集成平臺，必須體現(xiàn)出對各種集成業(yè)務的解決能力、平穩(wěn)不間斷的性能輸出能力、可靠堅實的容災保障能力等。

這些對于集成平臺的能力需求，都使得底層中間件架構(gòu)面臨嚴峻挑戰(zhàn)。對集成平臺進行底層架構(gòu)的重新定義，就成為了“破局”方式之一。對于那些每日業(yè)務量超過百萬級的集成平臺而言，采用單/雙機作為底層架構(gòu)是否還合適？筆者的看法是：不合適了！

如圖1所示，目前筆者所在醫(yī)院集成平臺每日消息量已超過300萬次，采用的架構(gòu)方式是利用多臺服務器構(gòu)成集群，共同處理所有醫(yī)院內(nèi)的業(yè)務項目，任務分布到多臺服務器上同時運行，集成引擎能實現(xiàn)對各類任務需求特征的自動區(qū)分，并進行不同的預處理，再由負載均衡功能進行工作任務的動態(tài)遷移。

該方案能實現(xiàn)管理配置、生產(chǎn)作業(yè)、數(shù)據(jù)存儲的分離，利用合理的技術架構(gòu)實現(xiàn)一處配置、多點生產(chǎn)、數(shù)據(jù)一致的效果，同時具有統(tǒng)一配置的監(jiān)控管理界面。當出現(xiàn)異常時，集群架構(gòu)能自動偵測并在其他服務器（節(jié)點）自動啟動該任務的模塊來進行處理，實現(xiàn)業(yè)務服務的自動故障轉(zhuǎn)移，從架構(gòu)上避免了單點故障的風險。集群還能進行動態(tài)擴展，更好地保證集成平臺的高可用性。

圖1

1.可擴展的負載均衡能力，滿足高并發(fā)需求

集群架構(gòu)可以提升集成平臺整體的處理能力，包括更高的TPS（事務數(shù)/秒）、更大的吞吐量、更多的并發(fā)數(shù)、更快的響應時間等，再經(jīng)由負載均衡提供高效合理的動態(tài)任務分配機制，進一步提升了集成平臺的總體運行效率。即使面對多院區(qū)、集團化、區(qū)域化等大規(guī)模醫(yī)療數(shù)據(jù)應用場景，也能保證系統(tǒng)的高性能。

2.服務熔斷、降級等保護機制，讓系統(tǒng)更穩(wěn)定

集群架構(gòu)還需具備服務熔斷和降級能力，當下游服務因訪問壓力過大而響應變慢或失敗時，上游服務為了保護系統(tǒng)整體的可用性，可以暫時切斷對下游服務的調(diào)用。由于醫(yī)院內(nèi)部各信息系統(tǒng)的性能參差不齊，集成平臺承擔了大量業(yè)務日常運行壓力，如果一次查詢的數(shù)據(jù)比較大，內(nèi)存使用已在高位的情況下，在某一時刻很可能會出現(xiàn)內(nèi)存過載導致響應超時甚至服務器宕機的狀況。通過集群架構(gòu)的服務熔斷和降級能力，可有效提升集成平臺的抗壓性，保護集成平臺的穩(wěn)定可靠。

3.自定義部署策略及智能資源分配，使管理更精細

對于不同場景下多樣化的數(shù)據(jù)需求，在進行充分細致的梳理后，能分別由集群內(nèi)的不同服務器節(jié)點進行處理，系統(tǒng)會根據(jù)各類任務需求的特征進行動態(tài)任務分配和管理。

例如，集群架構(gòu)中的系統(tǒng)能根據(jù)醫(yī)院自助機的不同請求智能分配資源：對于需要快速響應的查詢類服務（如號源信息查詢、醫(yī)生排班查詢等），將會自動分配給能同步并行處理數(shù)據(jù)的服務器節(jié)點，進行快速反饋；而對于自助機中的操作類服務（如預約確認、預約取消、自助繳費等），更注重消息順序和保證傳輸，則會分配給能進行異步處理的集群服務器節(jié)點。通過自動區(qū)分需求特征并匹配給對應的集群服務器節(jié)點，可以提升資源利用率，使業(yè)務運行更加平滑。

4.生產(chǎn)開發(fā)環(huán)境隔離，多人并行開發(fā)和規(guī)范的DevOps

目前，筆者所在醫(yī)院信息中心有40余位開發(fā)人員，在處理各類功能開發(fā)和日常運維等任務時，會采用多人同時上線的方式，以保證工作效率。采用集群架構(gòu)的集成平臺在性能上能輕松支撐多人同時在線開發(fā)，在功能上分離了生產(chǎn)和開發(fā)環(huán)境，并提供了規(guī)范的DevOps流程管理，項目需要被審核確認后才會被部署至生產(chǎn)環(huán)境。眾人各司其職，做到“忙而不亂”。

5.統(tǒng)一API網(wǎng)關管理，做好服務鑒權和訪問管控

隨著集團下屬各醫(yī)院陸續(xù)上線互聯(lián)網(wǎng)醫(yī)院等功能，外部對數(shù)據(jù)的調(diào)用和查詢需要通過開放API實現(xiàn)。為了確保系統(tǒng)和數(shù)據(jù)的安全，需要控制賬號的訪問權限以及訪問次數(shù)。集群架構(gòu)需要能實現(xiàn)統(tǒng)一的API網(wǎng)關管理，提供服務鑒權、訪問管控等功能，幫助IT管理者更清晰地看到各接口之間的調(diào)用關系，并實現(xiàn)對系統(tǒng)間調(diào)用的監(jiān)控。

隨著各醫(yī)院集成平臺重要性的提升，其底層的技術架構(gòu)也逐漸得到重視。采用集群架構(gòu)，不僅能夠讓醫(yī)院更好體驗到集成平臺的價值，還能提升集成平臺的穩(wěn)定性、擴展性，更可以為醫(yī)院持續(xù)推進互聯(lián)互通、智慧醫(yī)院建設打下了扎實的信息化底層架構(gòu)基礎。

（作者任職于浙江省臺州醫(yī)院信息中心 ）