電信BS架構系統遷移及云化研究

李書生，段 勇，石屹嶸，葉宇航

（中國電信股份有限公司上海研究院 上海200122）

1 引言

1.1 業界云計算的發展背景

云計算是近年來IT領域最為熱門的話題，被認為是繼微型計算機、互聯網后的第3次IT革命。云計算的本質是通過虛擬化、分布式處理、在線軟件等技術將數據中心的計算、存儲、網絡等基礎資源以及其上的開發平臺、軟件等形成可運營、可管理的服務，通過網絡的形式提供給用戶，實現按需使用和按使用量付費。云計算可分為IaaS(infrastructure as a service，基礎設施即服務)、PaaS(platform as a service，平臺即服務)、SaaS(software as a service，軟件即服務)3種服務模式。簡而言之，IaaS是將計算、存儲、網絡等基礎IT資源通過虛擬化技術以服務的形式提供給用戶；PaaS提供的是滿足特定需求的平臺能力，屏蔽了底層復雜的操作，使得開發人員可以快速開發出基于平臺的應用；類似的，SaaS通過在線軟件技術將應用軟件以服務的形式提供給用戶[1]。

企業通過實施云計算，可以提高其IT系統服務質量和減少企業IT運營成本，云計算技術蘊含巨大的商機。國內外各大IT廠商都大力投入云計算，包括VMware、Microsoft、Amazon、Cisco、Citrix以及國內的華為、世紀互聯、騰訊、盛大等。國內各大運營商也大力投入云計算，用其改進內部IT系統的服務質量和成本以及對外提供IDC、云存儲等多項服務。

1.2 BS架構系統現狀

隨著移動通信技術和移動互聯網的快速發展，移動用戶數量也隨之快速增長。為了給用戶提供更好的服務保障，各大電信運營商都建設了大量的BS架構支撐系統，這些系統為提升公司的經營和管理水平發揮了巨大的作用。但由于這些系統都是“煙囪式”獨立建設的，甚至部分系統是應急建設的，隨著業務的發展和技術的進步，存在的諸多問題日益明顯。

·傳統BS架構系統“煙囪式”建設，各系統之間硬件資源孤立，無法動態調配與共享，資源浪費與緊缺現象并存，分配嚴重不合理。

·部分早期BS架構系統Web和應用服務器仍運行在小型機上，硬件資源分配不合理。

·系統硬件資源長期處于高負載運行狀態，電力資源浪費嚴重。

·新系統上線部署周期長，無法快速響應需求。

·系統運維成本不斷提升，對運維人員要求越來越高。

2 系統遷移方法和關鍵問題研究

2.1 技術可行性

從軟件技術架構角度看，BS架構系統的Web和應用服務器基本部署在BEA、WAS等商業中間件上，少量BS架構系統為商業套件。對于商業套件的系統，可根據具體廠商的實際情況，制定專用的PC服務器遷移方案。對于大量中間件上的BS架構系統，由于中間件技術具有平臺無關性，即其上運行的業務系統與底層運行的操作系統和硬件服務器無關，遷移至PC服務器時尋找合適的中間件版本，并將應用部署于新的中間件平臺上即可，應用基本不用改動。總的來看，BS架構系統從小型機遷移至PC服務器在技術方面是可行的。

云計算技術分為IaaS、PaaS、SaaS 3個層次，針對BS架構系統的具體特性，研究發現IaaS和PaaS技術在電信BS架構系統中已具備實施條件，SaaS技術的具體實施有待進一步的探索。IaaS可以通過服務器端代理模式或者云管理平臺模式實現，PaaS可以通過JavaEE Cloud實現對中間件平臺能力的統一管理。

2.2 遷移實施方法論

BS架構系統的Web和應用服務器層從小型機遷移至PC服務器時，可參照數據收集與評估、設計與測試、實施遷移、運維與優化4階段的實施方法論進行遷移，各階段的關系如圖1所示，其中數據的收集與評估最為重要，每階段的具體工作描述如下。

（1）數據收集與評估

數據收集和評估階段是實施過程中最重要的一個階段，依次包括以下幾方面的內容：建立業務目標、收集和分析環境數據、風險評估、創建應用遷移路線圖、運維規劃。

其中，收集和分析環境數據主要包括收集Unix機器的CPU、內存、磁盤和網絡的使用情況。風險評估時，主要從技術和組織兩方面進行評估，包括可能引起的功能變化、重新編碼以及建立應用遷移過程中的實驗站點等，將影響/風險控制在可接受范圍內。制定應用遷移線路圖，需要將潛在遷移目標分類并劃分優先級來制定，包括評估遷移帶來的商業價值和開銷、評估資源利用率、評估潛在風險（運維轉型、技術轉型）、應用依賴關系、評估遷移影響（應用可承受什么級別的離線窗口）。運維規劃主要包括現有管理流程（變更、問題、事件、生命期）、現有管理系統（監控、自動化創建、安全、身份）、現有身份和訪問控制以及安全事件響應流程、部門內溝通和問題升級流程。

（2）設計與測試

在系統遷移前，應當先搭建Linux開發和測試環境，做好遷移設計和系統測試工作，以確保遷移后的系統能可靠運行。首先對系統代碼進行分析，確定是否存在必要的代碼修改等，設計詳細的遷移方案，之后再進行開發和測試工作，BS架構系統遷移測試工作尤為重要，測試應包括功能測試、性能測試、壓力測試和疲勞測試以及高可用性測試。

（3）實施遷移

該階段完成應用遷移到生產環境Linux服務器，依次包括以下幾方面的工作內容：根據性能測試調整Linux服務器配置、遷移應用到生產環境Linux服務器、完成割接前驗證測試和正式割接上線。

（4）運維與優化

該階段依次包括以下幾方面的工作內容：與現有管理流程集成（變更、問題、事件、生命期）、與現有管理系統集成（監控、自動化創建、安全、身份）、收集資源利用率數據、檢查服務級別遵從性、建立新基準（調整監控工具告警閾值）、培訓運維人員、更新運維文檔。

2.3 遷移相關問題及解決方案

2.3.1 如何確定硬件資源需求量

（1）問題描述

遷移后的系統運行在x86平臺上，相比于遷移前的小型機環境，需要重新估算服務器CPU、內存、存儲和網絡帶寬等硬件資源，以滿足業務系統的需求。但遷移前后服務器體系結構存在差異，需要尋找合適的估算維度和方法。

（2）解決方案

遷移后CPU處理能力的需求按照TPMC值進行估算，即根據系統高峰時刻用戶數、單位時間每用戶處理業務數、每筆業務平均處理事務數以及每個事務應用服務器性能消耗TPMC值進行估算。需要注意的是，不同的系統，每個事務的TPMC值消耗也不一樣。內存主要依據每秒并發事務數、每個應用服務器可承載的并發事務數以及每個應用服務器按照經驗應該配置的內存大小進行估算。存儲估算時，一般包括應用程序文件、業務服務應用程序文件、接口服務應用程序文件、日志文件等。網絡帶寬按照業務高峰用戶數以及每個業務流程的數據量大小、每個業務流程的權重占比進行計算，若遷移時服務器機房位置未變化，則無需重新估算網絡帶寬。需要注意的是，對于上述計算出的硬件資源量，在實際采購時需要考慮一定的系統冗余量。

2.3.2 業務系統運行失敗

（1）問題描述

遷移前應用系統中可能存在JNI調用、調用操作系統命令、用到OCI數據庫驅動等，遷移后由于操作系統發生變化，原先的調用代碼和調用命令失效，影響業務系統的正常運行。

（2）解決方案

由于調用的代碼是平臺相關性的，JNI調用同調用操作系統相關命令一樣，需要針對遷移后的Linux平臺重新進行開發。如果是OCI驅動，在遷移后的平臺上安裝Oracle客戶端驅動即可。

2.3.3 部署腳本無法運行

（1）問題描述

系統遷移前，主機上一般存在自動執行的部署腳本，用于日常的應用更新和維護。遷移后，由于主機操作系統從Unix更換至Linux，部署腳本中的命令將失效，部署腳本無法運行。

（2）解決方案

由于部署腳本是依賴具體操作系統的，因此需根據遷移后的Windows或Linux系統，對比之前小型機上的腳本，重新編寫同等功能的新平臺腳本，并進行相應的測試。

2.3.4 系統日志如何追蹤

（1）問題描述

應用系統遷移后由集中處理變成分散處理，系統日志也將分布于多臺x86服務器上。需要跟蹤和定位日志信息時，日志信息的搜索便變得很復雜，且部分x86服務器可能出現短暫故障，導致部分日志信息缺失，將給日志的定位帶來更大的難度。需要尋找合適的辦法，以管理這些分布式的日志信息，便于日后跟蹤和定位。

（2）解決方案

對于遷移后的日志分散狀況，建議將應用程序中日志模塊剝離出來，發送到一個集中的地方進行統一管理，形成統一的日志服務，以便日后跟蹤和定位日志信息。

2.3.5 配置文件如何保持一致性

（1）問題描述

應用系統中都存在一定量的配置文件，以便將一些系統變量配置在其中。遷移后，若按照之前的配置信息加載方式，由于PC服務器數量較多，在更新配置文件時，多個PC服務器之上的配置文件容易不一致，從而影響系統的運行。同時，針對多個PC進行更新，也容易出現手工操作失誤，影響一致性。

（2）解決方案

對于遷移后配置文件多且分散分布的問題，建議將配置文件信息獲取模塊獨立剝離出來進行集中存放，通過服務調用的方式來進行配置信息的獲取。這種改造的好處是：更新配置文件只需要一次發布不需要分別針對不同的PC進行更新，同時也避免了操作上的疏忽帶來的配置信息不一致。

3 云化部署模式研究

3.1 IaaS部署方案

3.1.1 簡單代理模式部署

BS架構系統一般都通過負載均衡設備分發用戶請求，因此可以對整體用戶請求數、每臺服務器負載狀況、資源池負載信息進行截取和分析，以判斷需要減少或增加新的應用服務器，實現基礎IaaS彈性方案。

對于在x86物理機和虛擬化軟件上部署的應用服務器，其IaaS彈性方案實現方式略有不同。物理機上部署的系統，一般通過在物理機上安裝代理腳本，以實現遠程服務器性能監控、負載狀況感知、待機、喚醒等基礎功能，再通過信息截取和控制端進行決策，以決定是否執行待機和喚醒功能。對于虛擬化軟件部署的系統，由于虛擬化軟件有統一的管理控制中心，因此無需在每個具體的應用服務器上安裝代理，可以由控制端直接與虛擬化軟件中心交互，進行遠程服務器性能監控、開啟和關閉虛擬機，從而實現IaaS彈性擴展方案。代理模式IaaS邏輯架構如圖2所示。

3.1.2 云管理平臺部署

區別于提前部署配置好應用服務器的代理模式方案，云管理平臺方案則是將手工新增或減少服務器的各個步驟，固化到流程模板中，實現實時部署彈性擴展，進一步提高基礎資源利用率。云管理平臺解決方案一般包括資源管理、可視化部署管理、配置和流程管理、自動化部署引擎、服務監控管理5個模板。這些模塊之間的關系如圖3所示。

其中，各個模塊包含的主要功能如下。

（1）資源管理

管理在應用服務部署中需要的所有基本單元，并且將這些基本單元之間的硬連接轉換為動態連接。資源管理模塊具備了以下的特性：管理所有的物理設備資源；管理和維護不同的平臺和應用軟件；實現物理設備資源的動態連接；管理資源的劃分，包括存儲空間、服務器、軟件平臺選擇分類、網絡端口和帶寬等資源管理；對于可視化部署管理提供統一封裝接口，實現可視化部署中資源有效性的檢查。

（2）可視化部署管理

從資源管理中獲取的資源可以利用可視化工具搭建需要的應用體系架構，并且該體系架構中包含了一定的部署流程和配置，部署引擎從可視化的體系架構中實現自動部署能力。因此，該模塊具備了以下的特點：可以區分全省不同業務或者不同地區的特性；實現管理應用服務中各個資源模塊的邏輯部署關系，并且需要從配置和流程管理模塊中讀取相應應用服務流程組合；提供審核部署關系、系統框架、資源使用等流程流轉關系；提供對于應用軟件進入資源管理模塊的審核，包括可發布軟件的版本管理、可發布服務的架構定義、應用服務上線的預約服務等；審核資源使用均衡性，并且可以提供服務調整的評估。

（3）配置和流程管理

提供在服務中需要涉及的流程和步驟以及對于不同業務或全省各個地區的區分配置，從而可以針對不同的配置定制出相關的部署流程；同時還可以從服務監控管理平臺獲得觸發條件，從而定義相應的處理流程。該模塊具備了以下的特點：定制不同的部署流程，并且對于流程中的各個步驟和步驟的異常提供下一個步驟的處理過程（相當于一個自動機）；可以將流程導出，提供給自動部署引擎使用，也可以提供給可視化部署管理使用，作為部署的應用邏輯；提供流程中的稽核點，并且提供稽核流程從而驗證系統部署的應用邏輯；在流程可以定義部署或執行過程的并行、串行、分支和嵌套等基本流程流轉功能，滿足業務邏輯和部署需求；支持自動執行流程和手動流程管理的互換（類似單步跟蹤能力）；支持針對不同版本的配置文件區分以及針對不同配置文件的流程對應關系管理；支持無差異化的擴展能力。

（4）自動化部署引擎

根據可以發布的部署架構和對應的流程，在約定的時間內實現對于服務的自動部署、服務的調整、補丁的分發等流程的自動化和手動執行流程，并且根據執行的結果進行流程中各個步驟的檢查和監控。因此，這個執行模塊應當具備以下特性：從資源池中根據部署架構找到資源；識別和執行有效的流程；執行各個步驟的狀態監控；自動執行引擎可以是面向多種平臺環境的集成工具。

（5）服務監控管理

提供對于業務的監控功能，并且根據監控數據和已知的業務優先級，提供觸發自動化流程的資源整合或調整流程，實現從服務質量到資源分配的智能化流程。因此，該模塊應當具備以下特性：對于應用服務響應時延（服務質量）的采集和定義，確定觸發條件；對于觸發流程的數據導入，確定觸發流程；對于全系統中響應時延的鑒別，確認和定位應用服務的服務質量和服務質量關系；可拓展到CTMBOSS的全業務流程，即可以適應復雜環境而不是目前單一的應用服務環境。

3.2 PaaS部署方案

BS架構系統一般運行在BEA、WAS、TUXEDO等商業中間件平臺上，因此可采用JavaEE Cloud平臺對中間件平臺能力進行統一管理，實現PaaS云計算。JavaEE Cloud平臺包含完整的JavaEE應用基礎運行環境，并基于虛擬化技術、自動化及自優化技術，為JavaEE應用提供了動態、彈性和智能化的運行環境，其邏輯架構如圖4所示，各組件功能描述如下。

3.2.1 應用路由控制組件

應用路由控制組件是JavaEE Cloud環境接收客戶端請求的統一接入點，該組件依據預定義的策略及運行時應用負載和JavaEE Cloud的狀態，動態地控制應用請求的路由和負載分派，其主要功能包括以下部分。

（1）環境感知

應用路由控制組件可以感知到JavaEE Cloud環境中的應用相關信息，包括應用服務接口（URL）、起停狀態、部署狀況、支持應用運行的應用服務器實例的運行狀態以及硬件資源的負載狀況等，同時，該組件還可以感知應用請求的相關信息，這些信息是應用路由控制組件進行動態路由和負載分派的基礎。

（2）智能路由

應用路由控制組件以感知到運行時狀態信息（應用請求及應用運行狀況）為基礎，依據預定義的路由策略，在運行時動態決定應用請求的路由目標。路由策略可以基于應用請求及應用運行狀況的相關信息進行定義。同時，智能路由還滿足會話親和原則，支持負載分派策略和流量控制策略。

（3）動態負載均衡

應用路由控制組件基于感知到JavaEE Cloud環境中應用服務器運行狀況（包括CPU和內存的利用率，請求的平均響應時間等），動態計算每個應用服務器分派負載的權重，同時基于請求對應的URL，并結合會話親和原則，路由策略和流量控制策略實現動態負載均衡。

（4）流量控制

應用路由控制組件可以基于預定義策略和運行時狀況動態控制分派到JavaEE Cloud環境的應用訪問流量。當出現資源競爭或服務器過載時，應用路由控制組件將基于相關策略，通過流量控制，進行有效的調節，確保應用的服務質量和可用性。

3.2.2 運行時核心組件

JavaEE Cloud運行時核心組件是Java Cloud提供服務的主體，該組件實現了具備虛擬化和動態特性的JavaEE應用運行環境，該組件提供的主要服務包括以下幾種。

（1）JavaEE應用服務器基礎服務

運行時核心組件提供完整的JavaEE應用基礎運行環境，支持JavaEE 5標準，提供必要的應用容器服務，提供安全控制、管理監控等基礎服務，并支持Web服務等開放標準，支持主流數據庫。該組件應廣泛支持主流的操作系統和硬件平臺，并可部署于物理或邏輯服務器上。

（2）JavaEE應用服務器虛擬化服務

基于運行時核心組件構建的JavaEE Clould環境提供虛擬化的應用運行環境，用戶在配置JavaEE Cloud環境時，僅需指定該環境包含的物理或邏輯服務器，而無需定義具體應用服務器實例及其固定的負載均衡權重。應用部署于該環境時，不再對應固定的物理或邏輯服務器。在運行時，JavaEE Cloud環境將依據預設策略及運行時的狀態動態地決定支持應用運行的應用服務器實例數等，從而實現彈性、虛擬的運行環境，實現應用與運行環境之間的松耦合。

（3）動態計算資源調度服務

運行時核心組件可以基于運行時應用的運行狀態和預定義的相關策略，通過動態控制應用服務器的啟動停止實現動態調度計算資源，由此，支持應用運行的應用服務器實例數量，可在運行時動態決定，并可進行靈活調整，為計算資源共享和應用服務質量管理提供了基礎。

（4）應用服務質量管理服務

運行時核心組件支持應用服務級別（包括基于性能指標和優先級的定義）的定義。運行時核心組件將依托動態計算資源調度服務，保證應用的服務質量。當運行時核心組件監控到應用的服務級別不能得到滿足時，運行時核心組件將自動為該應用啟動額外的應用服務器實例，保證服務質量。反之，則可以自動停止空閑應用服務器實例，以釋放計算資源供其他應用使用。

（5）自動化智能運維服務

運行時核心組件支持對應用服務器實例運行狀態的自動監控，并可配置系統異常狀態條件以及處理策略。運行時核心組件將會基于預設條件，監控應用服務器實例的運行狀態，當應用服務器實例出現異常狀況時，運行時核心組件可以基于預訂處理策略自動處理系統異常。自動化智能運維服務還支持不中斷服務的系統運維，包括在線的應用程序版本間的無縫切換，不中斷服務的中間件、操作系統和硬件的維護等。

3.2.3 管理組件

管理組件指JavaEE Cloud平臺的管理和監控工具，通過該工具可定義和配置運行時核心組件和應用路由控制組件，部署并管理應用系統，并可監控各個組件及應用的運行狀態。

3.3 部署模式比較

BS架構系統Web及應用層在實施云化時，可結合系統實際狀況，選擇3種云化方式中的一種進行實施，3種部署方案的優缺點比較見表1。

表1 3種部署方案的優缺點比較

3.3.1相關研究工作

云計算概念自提出以來，各大電信運營商和諸多高校研究機構以及IT廠商等都紛紛投入該領域，研究IaaS、PaaS和SaaS的具體實現方案和方式，包括電信運營商如何推進云計算的研究探索、云計算相關技術研究以及研究公有云能力開放平臺的實現方案，具有代表性的研究工作主要有以下內容。

電信運營商主要集中于內外部的云化方案和推進方式研究，內部主要針對電信IT支撐系統和業務系統，外部主要有IDC云計算，IT支撐系統包含的系統較多。中國移動通信集團（以下簡稱中國移動）的涂艷麗重點對云計算核心技術（分布式并行計算）的原理進行了研究[2]，并結合移動IT支撐系統現狀，提出了云計算技術在IT支撐系統中的應用思路和建設方案的方向性建議，但沒有對各階段的實現方式進行研究。中國移動的詹義通過分析IT支撐系統的現狀[3]，重點研究了服務器虛擬化和存儲虛擬化技術現狀，探討了在電信IT支撐系統中引入云計算的途徑及帶來的挑戰和相應的策略。中國電信股份有限公司（以下簡稱中國電信）的陳捷分析了IT支撐系統引入云計算的驅動力[4]，給出了電信企業級云計算的參考技術架構及與IT支撐系統云的關系，重點闡述了基于IaaS服務的IT支撐系統應用、基于PaaS服務的IT支撐系統應用、相應的網絡和終端情況，并提出了從IaaS入手，循序漸進和先實施后評估的實施原則。

國內高校一些學者的研究多數在開源軟件如Hadoop、Eucalyptus等平臺的基礎上進行研究，與本文比較相關的工作主要有：南京理工大學的孫偉龍[5]利用開源軟件Eucalyptus搭建了IaaS云計算平臺，在此基礎上實現了不確定度計算的Web系統，該系統使用Hadoop平臺實現了不確定度的分布式計算，并通過性能測試驗證了Hadoop在處理大數據集時的優勢，主要面向數據處理類應用。華南理工大學的曾述青將PaaS技術應用到電信的業務交付平臺(SDP)[6]，采用Web Service技術將底層服務封裝，對外以接口形式發布。開發者在該Web平臺上可以調用電信及非電信的業務，方便快速地滿足開發人員的需求，極大地提高了業務開發的效率和靈活性。北京理工大學的肖家立[7]分析了SOA和SaaS的區別及聯系，并對SOA和SaaS未來的結合發展做出了展望。

一些IT廠商研究機構和開發者，圍繞如何實現共有云計算平臺做了一定的研究。新浪資深架構師叢磊介紹了Sina App Engine（SAE）[8]，國內首個共有云 計算平臺，SAE選擇PHP作為首選的支持語言，Web開發者可以在Linux/Mac/Windows上通過SDK或者Web版在線SDK進行開發、部署、調試，團隊開發時還可以進行成員協作，不同的角色將對代碼、項目擁有不同的權限。南京工程學院的劉楓[9]討論了Google云計算服務體系架構、實現機制和算法流程，給出了如何利用集成環境設計部署一個Web應用服務，并通過一個Web應用服務實例,提出了Google App Engine for Java應用程序的基本開發流程，為今后實現信息化建設的云計算應用系統提供了參考。

3.3.2 本文解決方案的特點

本文提到的2種IaaS部署方案和1種PaaS部署方案，主要針對電信運營商內部IT支撐系統中的BS架構系統，其一般運行在WAS、BEA等J2EE中間件平臺上。對比上述相關研究工作，文中提到的解決方案對運營商而言，可推廣性較強、風險較低、成本投入較少、實用性較強，具體包括以下幾點。

對電信BS架構系統從小型機遷移至PC服務器的關鍵問題進行了深入研究。

以電信BS架構系統現狀為出發點，研究其實現IaaS和PaaS的具體方案。對比相關研究工作，本文解決方案無需改動應用系統代碼，對電信實際生產系統而言具有較好的風險控制，此外云化成本投入較少，無需重新開發代碼等大量工作。

簡單代理模式IaaS解決方案，不僅可以用于BS架構系統，還可用于流媒體等其他電信系統，該解決方案可以作為電信推進IaaS云計算的初級階段，方案成本投入少且易實現，對現有系統部署無需進行任何改動，只需部署代理客戶端即可。

云管理平臺IaaS解決方案，給出了采用云管理平臺實現BS架構系統IaaS云計算的功能架構關系，對于云計算在IT支撐系統中的大規模落地，具有較好的參考意義。

JavaEE Cloud實現的PaaS方案，特點主要在于不再以基礎資源利用率等作為彈性，而以應用響應時間等作為平臺資源彈性伸縮KPI指標，在更高的層次實現了PaaS方案，同時無需改動任何應用服務器代碼，具有較好的可推廣性，方案的成本和風險較小，對電信運營商意義較大。

本文解決方案不是以宏觀層面作為切入點，而是以運營商中大量BS架構系統為著手點，研究IaaS和PaaS實際落地的具體解決方案，研究工作較細致深入。

4 演進路徑及建議

電信BS架構系統遷移及云化演進策略建議如下。

（1）BS架構系統選取路徑

建議先從電信MBOSS中選擇業務邏輯相對簡單的系統，如CRM、網上營業廳、計費/10000接口等，再逐步滲透至電信MBOSS中的BS架構，可以采用負載均衡設備水平分擔的應用進行遷移，逐步實現整體BS架構系統Web及應用服務器層PC化。

（2）部署方案推進建議

應用系統從Unix機器遷移部署至PC服務器以及PC服務器部署系統實施云化時，在選擇部署方式上，可以根據自身情況采用物理機或者虛擬機部署。云化方案可以直接采用JavaEE Cloud實現PaaS云，也可以先采用代理模式IaaS方案，再進一步升級至云管理平臺模式。BS架構系統遷移及云化分階段推進演進路徑如圖5所示。

5 遷移風險及防范

系統遷移后在系統代碼、系統日志、部署腳本以及系統部署架構方面都存在一定的變化，主要的風險需要通過遷移前的測試來避免，需主要關注以下幾方面。

·顆粒度細化后系統模塊間的交互，通常由遷移前的本地調用轉換成遠程調用，需要測試其相關的服務調用是否成功。

·遷移后系統由原來統一的Web根目錄分散成不同的Web根目錄，因此類似JSP、JS、CSS、圖片等資源調用是否正常也需要進行測試。

·系統遷移后EJB調用也需要進行分別測試通過。

·還需要考慮不同的一級域名間相互訪問是否存在問題的測試。

·建議采用分階段模塊遷移方式進行，以降低遷移過程的風險。

·系統遷移過程存在一定風險，需要準備回退方案。建議通過4層交換機進行手工切換，保證遷移后的系統若在試運行過程中發現異常，可立即切換到遷移前的生產環境上。

6 結束語

通過實施BS架構系統Web和應用層遷移及云化，可以降低電信IT系統服務器擁有成本和運營成本，錯峰利用服務器資源，提高服務器利用率，提升電信IT系統服務質量，增強系統可靠性，同時也是電信內部推進云計算的先行實踐。BS架構系統一般包含Web層、應用層和數據庫層，目前的云化方案主要針對Web和應用層，可以進一步探索數據庫層的云化方案，進一步降低電信IT系統成本。從云計算層面來說，目前的方案主要是IaaS和PaaS層面的，可以進一步探索SaaS層面的實現方案，進一步提高電信云計算技術能力水平。

1 石屹嶸，段勇.云計算在電信IT領域應用初探.電信科學，2009，25(8)

2 涂艷麗.云計算及在IT支撐系統中的應用.中國通信學會第六屆學術年會論文集，2009

3 詹義，段偉希，胡曉彥.云計算在電信IT支撐系統中的應用.電信科學，2011，27(10A)

4 陳捷.云計算在電信IT支撐系統應用的研究.2011年信息通信網絡技術委員會年會征文，2011

5 孫偉龍.基于IaaS云計算的Web應用技術研究.南京理工大學碩士學位論文，2011

6 曾述青.基于PaaS平臺電信互聯網融合業務的研究.華南理工大學碩士學位論文，2011

7 肖家立.企業級應用架構研究：SOA架構融合SaaS模式.價值工程，2011（33）

8 叢磊.Sina App Engine架構—云計算時代的分布式Web服務解決方案.程序員，2010（11）

9 劉楓.基于Google云計算的Web應用與開發.電腦開發與應用，2011（5）