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

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