醫院內部應用的云遷移研究

楊雪寒 焦瑋 張倩 孟潔

摘 要：針對將醫院內部部署的面向患者和社會公眾的應用程序遷移上云所面臨的系統架構重組和目標云服務選擇的問題，提出了一種醫院內部應用云遷移方法。該方法從識別應用程序的體系結構和配置文件開始，通過BPM生命周期確定云計算服務的需求，然后通過識別和選擇能夠滿足應用需求的云服務類型，并最終將應用程序部署到選定的云中。文中將該方法應用于醫院患者支持系統的云遷移實踐，以示該方法的具體操作。

關鍵詞：醫院內部應用;云應用;遷移方法

中圖分類號：TP 399

文獻標志碼：A

文章編號：1007-757X（2020）11-0009-04

Abstract：This paper proposes a hospital internal application cloud migration method for the problem of system architecture reorganization and target cloud service selection for the migration of applications for patients and the public in the hospital. The method begins by identifying the application's architecture and configuration files， then determines the requirements of the cloud computing service through the BPM lifecycle， and identifies and selects the type of cloud service that can meet the application's needs， and ultimately deploys the application to the selection in the cloud. In order to illustrate the specific operation of the method， the method is applied to the cloud migration practice of the hospital patient support system.

Key words：hospital internal application;cloud application;migration method

0?引言

醫療行業的云計算技術應用問題已經在實踐和學術領域得到了廣泛的討論。云計算技術從數據安全性、感知技術能力、信息技術成本和降低信息系統復雜性等方面給醫療行業信息技術的發展帶來巨大改變，使得云計算技術在醫療行業得到充分重視[1-3]。對醫院業務系統而言，相對于傳統信息技術基礎設施，具有按需服務、廣泛的網絡訪問、資源池按需分配、快速彈性和可測量的業務服務等特點的云計算服務具有巨大的成本優勢和技術優勢，因此基于云的WEB應用已經成為醫院業務系統發展的主流趨勢[4]。就醫療領域現有應用程序的體系結構而言，客戶端-服務器（B/S）模式在過去幾十年中使用得最多，幾乎所有現有的應用程序都是使用這種樣式構建的[5]。為此將基于傳統技術架構應用遷移到云端已成為醫院IT從業者不可回避的挑戰。已有一些學者針對這個問題開展研究，然而研究結果普遍存在一些不足之處[6-8]：（1）很少考慮Web應用程序和云的體系結構;（2）對遷移后的云應用程序的分布式風格的云需求很少有說明。這些缺陷不可忽視，因為經過深思熟慮的遷移流程對于以系統和管理的方式指導許多應用程序的遷移至關重要。為此，本研究提出六步驟應用程序遷移方法。該方法從識別應用程序的體系結構和配置文件開始，然后通過BPM生命周期[9]確定云計算服務的需求，然后通過識別和選擇能夠滿足應用需求的云服務類型，并最終將應用程序部署到選定的云中。為了說明該方法的有效性，本研究將該方法應用于將面向醫院宣傳的患者支持系統的遷移實踐中。其中該醫院患者支持系統主要功能是為正向為企業收集患者信息和反向為患者提供醫療服務。

1?遷移方法

1.1?步驟1基線架構標識

該方法從識別內部應用程序的體系結構和概要文件（即基線架構），如圖1所示。

圖1顯示了一個客戶支持系統的體系結構，該體系結構具有4層的協作組件，患者通過社區、知識代理和任務服務組件三個系統模塊與企業交互。社區幫助患者共享關于他們想要了解的醫療信息。知識代理收集患者的信息，幫助醫院捕捉患者存在的醫療服務需求。醫院提供當前醫療服務的具體信息，如科室就診排隊情況，幫助患者進行識別和比較。

完成對應用程序體系結構的識別后是捕獲其配置文件以調整應用程序的大小。通常，應收集應用程序配置文件至少10到14天，以便計算出每日或每周使用模式的所有差異。有兩種關于應用程序的配置文件數據：1） 有關應用程序運行環境的數據，例如CPU、內存、存儲、I/O和網絡使用情況;2） 有關患者的操作數據，例如活躍用戶數、訪問連接數、連接等待時間等。

1.2?步驟2目標架構識別

獲取應用程序基線架構和概要文件之后，是確定滿足其部署目標云的需求。這通常可以通過實施BPM生命周期來實現，通過其策略、設計、執行和控制生命周期階段來確定目標基線。已確定的云計算的需求包括：1） 能夠支持應用程序目標基線功能的在選定云中的配置元素上的部署的架構組件;2） 支持應用程序的非功能性目的的選定云中執行的概要文件，如定制的用戶界面和訪問模式、應用性能、應用可靠性、數據安全性和系統可擴展性等。

對于所研究的患者支持系統的五個組件可能需要在不同的云環境上分別部署，以支持其體系結構和概要文件需求。此外，為了從患者那里收集信息并向客戶傳遞當前醫院的具體服務信息，需要在云計算服務中部署QoS策略，以保證定制的用戶界面訪問的及時性和和服務信息的可靠性。

1.3?步驟3候選云服務類型確定

在確定對云服務的性能要求之后，該方法繼續識別其服務模型（SaaS、PaaS或IaaS）滿足這些要求的候選云服務[10-11]。為此考慮提供以下任一云服務模型的所有可用環境：

1. 在SaaS模型中，云服務可以替換應用程序中需要特定QoS特性以確保其替換的服務，如服務級別協議（SLA）、服務的兼容性和數據/訪問控制的可移植性[12]。

2. 在PaaS模型中，云服務提供了平臺服務，應用程序可以在這些平臺服務上部署，這些服務具有SLA、應用程序部署、服務的兼容性和數據/訪問控制的可移植性等QoS特性。

3.在IaaS模型中，云服務提供了服務器、存儲和網絡等基礎設施服務，在這些基礎設施服務中，應用程序及其剩余平臺可以在SLA、應用程序部署、服務兼容性和數據/訪問控制的可移植性等QoS特性下使用。

基于滿足應用程序需求的考慮，從上述云服務類型選擇醫療應用遷移的候選云，如圖2所示。

圖2顯示了醫療患者支持應用的可能候選云，其中IaaS云服務被識別為社區實例的候選者，因為其服務預期由一些基礎設施提供，這些基礎設施很好地在患者中間支持信息共享的存儲和操作。

1.4?步驟4云服務提供商的選擇

確定了候選云模型之后，下一步就是基于候選云模型中選擇公有云服務提供商。一般來說，可以通過一些評估標準（如上文所述的QoS特性）來進行選擇，以切實滿足遷移目標對云服務的計算需求和存儲需求。

1.5?步驟5云遷移計劃的制定

在確定具體云服務提供商后，本研究所設計的遷移方法將指定關于應用程序遷移到上述目標云所涉及的詳細執行計劃。一般來說，這些活動包括以下方面。

1. 將應用程序組件部署到各自云中的配置元素上。

2. 將應用程序組件之間的交互機制部署在各自云上的云間/云內交互解決方案上。

3.重構任何已部署的組件，以滿足使用和用戶操作需求，例如定制的用戶界面和訪問模式、性能、可靠性、安全性和可擴展性。

2?遷移實踐

2.1?患者支持系統的基線架構

本研究將所提議的遷移方法應用于醫院患者支持系統，驗證該方法的有效性。遷移的第一步是從識別內部應用程序的體系結構和基線架構開始。患者支持系統的體系架構如圖1所示。該體系結構具有4層的協作組件，患者通過社區、知識代理和任務服務組件三個模塊與醫院交互。社區幫助患者共享關于醫院的具體醫療信息。知識代理收集患者的信息，幫助醫院捕捉患者存在的醫療服務需求。醫院提供當前醫療服務的具體信息，如科室就診排隊情況，幫助患者進行識別和比較。然后對每個模塊功能進行明確。例如，組織社區是為了讓患者共享關于其想要了解的醫院服務的具體信息，例如門診人數、專家門診排班信息等。此外社區組件還負責將收集的信息轉發給醫院。知識代理重新組織成特定的知識風格。然后將知識發送給任務服務組件，以便轉發給企業以滿足其需求（例如，提供滿足其所需任務的服務）。最后，它還與任務服務組件合作接收服務信息。對這些要求進行相關客戶的認可和比較。

綜上所述，對社區組件的功能需求總結如下：1） 共享有助于客戶之間信息共享的客戶信息;2） 處理轉發共享信息;3） 通過知識代理將收集的信息重新構造為知識，然后將知識發送到任務服務組件;4） 處理任務請求，該請求從所有的客戶端接收任務請求，并將經過評估的關于任務的相關醫療服務信息返回給對應客戶端;5） 與接收與任務相關的服務的評估信息的任務服務組件合作;6） 為患者提供帶有豐富用戶界面控件的客戶端以便提供便捷的醫療信息服務信息和用于可視化來自任務服務組件的與任務相關的醫療服務信息。

基于上面對社區的需求，如圖3所示。

圖3顯示了實現這些需求的五個組成部分。特別地，為了實現客戶端的用戶界面的自定義和個性化需求，采用了一個“接口管理器”的組件，其中使用客戶概要文件來確定他們更喜歡哪些接口組件;此外，使用這種自定義的用戶界面，“接口管理器”可能會保留其包含的界面小部件，以便共享或關于任務相關服務的可視化信息，從而形成自定義的用戶界面，并根據患者的交互需求將其所需的信息顯示出來。此外，信息/知識管理器訪問社區成員信息和患者所共享的個人信息，協助患者將其病患信息分享給醫生。信息/知識管理器還可以通過知識代理組件檢索到經過整理重組的與患者相關的數據。任務請求管理器將任務請求從患者轉發到與任務服務組件協作的“協作管理器”，以接收關于這些醫療信息請求的評估信息。經過評估被認為能夠共享的醫療信息將被可視化處理，并通過接口管理器返回給患者。最后，Web服務管理器負責通過Web服務客戶端的應用程序編程接口（API）與這兩個外部體系結構組件進行互操作，以訪問這兩個組件提供的遠程服務。

2.2?確定遷移后的目標系統架構

根據患者支持系統的體系結構和配置文件確定其云需求。首先，考慮到該系統的五個分布式組件，不同的云環境可能需要各自部署在這些云中的預期配置元素上，以支持其功能或非功能目的。此外，為了為醫院收集患者信息并交付醫療服務信息以造福患者，該系統可能需要部署的云資源使用和用戶操作的服務質量（QoS）控制策略，QoS包括定制的用戶界面和訪問模式、計算性能、存儲可靠性、數據安全性和系統可擴展性。

2.3?確定患者支持系統的候選云服務模型

第三步是確定云服務配置和模型，即從SaaS、PaaS和IaaS三種云服務模型中為患者支持系統中各個模塊選擇最合適的候選云服務模型。通常不止一個云服務模型能夠滿足系統組件的遷移和部署需求，因此需要系統模塊的業務需求的選擇候選的云服務模型。圖2顯示了為患者支持系統各個模塊所選擇的候選云服務模型。

1） 對于患者知識代理和醫院模塊，由于SaaS云服務模型能夠提供代理模型和醫院模塊所必須的軟件資源，因此被選擇為這兩個模塊的候選云服務模塊。

2） 對于任務服務組件，PaaS被認為是最優的候選云服務模型，因為PaaS云服務器平臺支持與多個醫院模塊進行協作以轉發患者信息或接收社區信息，并能夠提供充分的云間數據分析能力以便將收到的醫療服務信息評估成比較模型供患者進行比較和選擇。

3） 對于社區模塊，IaaS被選擇為候選云服務模型，因為IaaS云基礎設施能夠提供對患者之間所共享的大量信息的數據存儲和處理能力，以及在多個知識代理模塊之間進行數據協作以重組患者共享信息形成更為具體的患者個體知識風格的能力。

2.4?患者支持系統云服務供應商的選擇

確定了候選云服務模型之后，就是選擇要遷移的云服務供應商。對于患者支持系統，所選的云服務供應商確定如下。1）作為國內諸多醫療云服務供應商中，騰訊云提供了較為全面的醫院業務流程解決方案，且能夠針對各個醫院特殊的業務需求進行定制化開發，因此被選定為協作代理模塊和醫院托管模塊SaaS云供應商。2）在諸如百度BBC和微軟Azure這樣的可用PaaS云中，本研究選擇了Azure云作為遷移任務服務組件的載體，因為Azure云具有眾所周知的較強的云間協作和數據分析能力，可以充分滿足任務服務組件之間的計算資源協作和數據的高效處理的要求。3）在可用的眾多的阿里云、華為云等IaaS云中，本研究選擇阿里云作為社區模塊的上云首選，這是因為阿里云具有良好的數據處理、云間共享和與其他組件交互的性能，同時兼具良好的計算和存儲穩定性。社區模塊上云后的系統架構，如圖4所示。

2.5?患者支持系統遷移計劃的制定

在確定了云的選擇之后，就可以指定關于應用程序遷移到這些云所涉及的具體遷移計劃。這些遷移計劃包括：1） 將系統組件部署到各自云中的配置元素上;2） 將系統組件之間的交互機制部署在各自云服務器或云存儲系統的交互解決方案上，重構所有已部署的組件，以滿足系統運行需要和用戶操作需求，如圖5所示。

圖5顯示了患者支持系統五個組件的部署在阿里云的虛擬機（VM）和云存儲服務上的概況，其中云存儲系統包括S3存儲、分布式塊存儲系統和關系數據庫。

3?總結

本文提出了一種將本地面向醫院的應用程序遷移到云中的方法。該方法采用BPM生命周期方法對應用程序地架構、業務邏輯和功能需求進行解構，選擇最優地云服務模型以實現應用程序的有效遷移。醫院患者支持系統的遷移實踐表明，該方法能夠有效支撐醫院內部部署的應用程序的遷移。下一步，本研究將繼續探索利用最流行的云計算服務（如新浪SAE和阿里云）將用作部署平臺，將醫院內部部署的面向患者和公眾宣傳的應用遷移到云中，以充分提高這些應用程序的運行質量和性價比。同時本研究還將對應用程序的預期遷移質量的量化評估進行研究，充分利用量化指標管控目標云選擇、遷移操作等關鍵項目的質量。

參考文獻

[1] 楊凱琪，姚培，趙玉龍，等.面向異構容器云的應用遷移方法[J].計算機工程，2019，45（8）：42-47.

[2]?楊凱琪，趙玉龍，陳林.異構容器云間應用遷移模型研究[J/OL].計算機應用研究：1-7[2019-09-21].https：//doi.org/10.19734/j.issn.1001-3695.2018.09.0762.

[3]?王雁華.醫療信息云服務建設的關鍵技術研究[J].科技創新導報，2019，16（3）：158-159.

[4]?劉靜靜.電子就業云遷移框架研究與實現[J].浙江樹人大學學報（自然科學版），2018，18（04）：8-12.

[5]?顧東曉，李童童，梁昌勇，等.基于云計算的管理信息系統遷移模式與策略研究[J].情報科學，2018，36（12）：71-76.

[6]?朱連章，李博，張衛山，等.基于深度學習的普適云服務遷移方法研究[J].太原理工大學學報，2018，49（5）：736-744.

[7]?杜昊.云計算技術在醫院信息化建設工作中的應用[J].計算機產品與流通，2018（8）：259.

[8]?朱廣超，史紀強.企業應用系統云環境遷移方案研究[J].油氣地球物理，2018，16（3）：58-62.

[9]?王偉杰，黃建隆，林耀，等.PACS/RIS系統云遷移若干問題及對策[J].中國數字醫學，2016，11（11）：101-103.

[10]?應嘉煒.云計算區域數字衛生關鍵技術信息共享協同平臺研究[J].信息與電腦（理論版），2016（2）：7-9.

[11]?馬海峰，意合巴力，王燁，等.基于清華云監控平臺的云遷移性能[J].計算機應用，2015，35（11）：3026-3030.

[12]?姜海鷗，宋美娜，鄂海紅，等.運營支撐系統混合云遷移策略制定方法[J].北京郵電大學學報，2014，37（5）：1-5.

（收稿日期：2020.03.14）