2025醫(yī)院集成平臺 IT 基礎架構(gòu)需求分析與方案選型VIP

IT基礎架構(gòu)本?檔將圍繞醫(yī)院集成平臺的資源需求及其對IT基礎架構(gòu)的要求展開討論，并給出基于超融隨著醫(yī)院信息化建設的不斷完善，醫(yī)院逐步上線了HIS、EMR、PACS、LIS等多個業(yè)務系統(tǒng)。務系統(tǒng)之間需求調(diào)?復雜、接?數(shù)量多且?統(tǒng)?標準、數(shù)據(jù)交互效率低下、維護困難低，后期逐漸轉(zhuǎn)向ESB（企業(yè)服務總線）為主要框架。ESB優(yōu)勢ESB劣勢?法保證消息或服務請求的順序，?醫(yī)院業(yè)務之間調(diào)??多有嚴格處理順序要求。ESB引?消息隊列軟件處理服務請求順序的問題、改造ESB?持醫(yī)療標準協(xié)議等?案，雖然在?定程度上實現(xiàn)了ESB的優(yōu)化，但存在?案極其復雜、開發(fā)難度過?、成本過?等問題?？?在集成平臺建設中，單憑ESB軟件?法完全滿?業(yè)務的需求。經(jīng)過多年的發(fā)展與試錯，醫(yī)院集成平臺逐步形成了以ESB（企業(yè)服務總線）、IE（集成引擎）、如圖所示，集成平臺的集成?作主要包括兩個部分：應?集成和數(shù)據(jù)應?集成主要實現(xiàn)各個業(yè)務系統(tǒng)之間的請求和調(diào)?，由ESB（企業(yè)服務總線）和IE（集成引擎）兩部分組成。其中ESB負責同步數(shù)據(jù)處理操作，IE集成引擎負責異步數(shù)據(jù)處理。ESBIBMIBMIntegrationBus/MQ（ESB+消息隊列InterSystemsOrionHealthRhapsodyMicrosoftBiztalkIBMIntegrationBusIBMIntegrationBus國內(nèi)集成平臺常?的集成引擎?案如表所示?？梢钥闯?，國內(nèi)的集成平臺?商?多采?國外成熟的ESB企業(yè)服務總線+IE集成引擎產(chǎn)品。常?ESBEBS產(chǎn)品AIX,HP-Itanium,Solaris,Windows,Redhat,SUSE,UbuntuAIX,HP-Itanium,Linux,Solaris,Windows,z/OSIBMSQLWindows,Linux,AIX,HPUX,I/O式?件存儲（直接讀寫?件OdinOdinWindowsLinuxAIXHPUX,Solaris,UOS,麒麟Elasticsearch分布式數(shù)據(jù)庫（開ETL?具ETL是extract-transform-load三個數(shù)據(jù)處理過程的縮寫：（Extract）數(shù)據(jù)抽取：理論上，ETL?具可從?產(chǎn)業(yè)務系統(tǒng)的數(shù)據(jù)庫直接抽取數(shù)據(jù)并轉(zhuǎn)換數(shù)據(jù)，但這種?式會對?產(chǎn)數(shù)據(jù)庫帶來較?壓?，直接影響業(yè)務系統(tǒng)響應速度。為了解決這個問題，ETL過程會先將數(shù)據(jù)完封不動地抽取到中間通常情況下，建設集成平臺?約涉及40-80以ESB軟件為例，它包含應?和數(shù)據(jù)庫兩種??。部分?型三甲醫(yī)院甚?將集成平臺ESB可能會涉及4-10個服務器??。ETL相對更加復雜，包含ETL?具服務器，中間數(shù)據(jù)庫服務器（通常運?MySQL數(shù)據(jù)庫）ETL6-12同時，集成平臺?產(chǎn)環(huán)境的各個??必須考慮冗余?可?設計，?且需要有對應的開發(fā)和測試環(huán)境。?旦發(fā)?宕機，所有業(yè)務都有可能受到影響，?險極?，因此集成平臺對于基礎架構(gòu)的可靠性要求?常?。?型三甲醫(yī)院集成平臺平均每天需要處理9000萬條消息，要求峰值處理能?需達到1000TPS，存儲性能不?容易導致整個業(yè)務系統(tǒng)卡頓，嚴重情況下甚?會宕機，因此??？简灮A架構(gòu)I/O吞吐能?。80臺服務器采購成本需要數(shù)百萬??幣，同時硬件維保的費?也相應提?，但每臺服務器資源的實際利?率很多醫(yī)院機房空間?常有限，新增?量的物理服務器，可能會使得機房變得擁擠不堪，制冷和UPS有可能?集中式SAN部分醫(yī)院采?服務器虛擬化+集中式SAN存儲的架構(gòu)運?集成平臺，雖然可以解決物理服務器的?些問題，但共享SAN存儲的問題則愈發(fā)凸顯。很多?型醫(yī)院選擇全閃SAN存儲作為主存儲，并為了保證存儲?可?，配置了雙活存儲功能，其使?成本超過10萬元/TB；?集成平臺對于存儲資源需求較?，完全依賴SAN存儲

超融合架構(gòu)將服務虛擬化、服務器、存儲多種設備和元素融為?體，以軟件為核?，使?標準商?硬件替代昂貴的專?硬件，解決了傳統(tǒng)架構(gòu)管理復雜、推薦閱讀：推薦閱讀：對?超融合與“VMware+FCSAN”傳統(tǒng)架構(gòu)：4?差異與5?優(yōu)勢（更新版）續(xù)獲得資源拓展和性能提升（圖為SmartX超融合基礎設施）。SmartXSmartX理論上超融合平臺可承載集成平臺所有??，但由于部分醫(yī)院?戶仍希望將核?系統(tǒng)的數(shù)據(jù)庫（如集成平臺的CDR數(shù)據(jù)庫）部署在傳統(tǒng)架構(gòu)上，為了滿??戶的需求，SmartX提供兩種架構(gòu)綜合部署的解決?案。超融合軟件基于SmartX分布式塊存儲ZBS，并與?型醫(yī)院客戶熟悉的VMware虛擬化融合部署。以兩臺物理服務器和SAN存儲組建OracleRAC數(shù)據(jù)庫集群，運?CDR數(shù)據(jù)庫。SmartX超融合平臺運?集成平臺其他所有??，包括ESB、ETL、IE、SmartX超融合平臺同時可承載多個核?業(yè)務系統(tǒng)數(shù)據(jù)庫的備機（OracleDG備庫/MSSQLServerSMTXHalo7100S)：10-2024?萬兆交換機：2臺虛擬化平臺：VMwarevSphere（推薦150-300可提供100TB-400TBSmartXSANSMTXHalo超融合?體機40-80臺10-20臺4-8個機柜1-2HA備機與主庫配置需100%?致超融合架構(gòu)極?提?部署密度，只需不到傳統(tǒng)?案1/10的物理服務器數(shù)量即可滿?部署要求，?幅減SMTXHalo超融合?體機?持基于NVMe全閃超融合集群，性能卓越，單節(jié)點處理能?