電信BS架構(gòu)系統(tǒng)遷移及云化研究

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

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

1 引言

1.1 業(yè)界云計算的發(fā)展背景

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

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

1.2 BS架構(gòu)系統(tǒng)現(xiàn)狀

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

·傳統(tǒng)BS架構(gòu)系統(tǒng)“煙囪式”建設(shè)，各系統(tǒng)之間硬件資源孤立，無法動態(tài)調(diào)配與共享，資源浪費與緊缺現(xiàn)象并存，分配嚴(yán)重不合理。

·部分早期BS架構(gòu)系統(tǒng)Web和應(yīng)用服務(wù)器仍運行在小型機上，硬件資源分配不合理。

·系統(tǒng)硬件資源長期處于高負(fù)載運行狀態(tài)，電力資源浪費嚴(yán)重。

·新系統(tǒng)上線部署周期長，無法快速響應(yīng)需求。

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

2 系統(tǒng)遷移方法和關(guān)鍵問題研究

2.1 技術(shù)可行性

從軟件技術(shù)架構(gòu)角度看，BS架構(gòu)系統(tǒng)的Web和應(yīng)用服務(wù)器基本部署在BEA、WAS等商業(yè)中間件上，少量BS架構(gòu)系統(tǒng)為商業(yè)套件。對于商業(yè)套件的系統(tǒng)，可根據(jù)具體廠商的實際情況，制定專用的PC服務(wù)器遷移方案。對于大量中間件上的BS架構(gòu)系統(tǒng)，由于中間件技術(shù)具有平臺無關(guān)性，即其上運行的業(yè)務(wù)系統(tǒng)與底層運行的操作系統(tǒng)和硬件服務(wù)器無關(guān)，遷移至PC服務(wù)器時尋找合適的中間件版本，并將應(yīng)用部署于新的中間件平臺上即可，應(yīng)用基本不用改動?？偟膩砜?，BS架構(gòu)系統(tǒng)從小型機遷移至PC服務(wù)器在技術(shù)方面是可行的。

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

2.2 遷移實施方法論

BS架構(gòu)系統(tǒng)的Web和應(yīng)用服務(wù)器層從小型機遷移至PC服務(wù)器時，可參照數(shù)據(jù)收集與評估、設(shè)計與測試、實施遷移、運維與優(yōu)化4階段的實施方法論進(jìn)行遷移，各階段的關(guān)系如圖1所示，其中數(shù)據(jù)的收集與評估最為重要，每階段的具體工作描述如下。

（1）數(shù)據(jù)收集與評估

數(shù)據(jù)收集和評估階段是實施過程中最重要的一個階段，依次包括以下幾方面的內(nèi)容：建立業(yè)務(wù)目標(biāo)、收集和分析環(huán)境數(shù)據(jù)、風(fēng)險評估、創(chuàng)建應(yīng)用遷移路線圖、運維規(guī)劃。

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

（2）設(shè)計與測試

在系統(tǒng)遷移前，應(yīng)當(dāng)先搭建Linux開發(fā)和測試環(huán)境，做好遷移設(shè)計和系統(tǒng)測試工作，以確保遷移后的系統(tǒng)能可靠運行。首先對系統(tǒng)代碼進(jìn)行分析，確定是否存在必要的代碼修改等，設(shè)計詳細(xì)的遷移方案，之后再進(jìn)行開發(fā)和測試工作，BS架構(gòu)系統(tǒng)遷移測試工作尤為重要，測試應(yīng)包括功能測試、性能測試、壓力測試和疲勞測試以及高可用性測試。

（3）實施遷移

該階段完成應(yīng)用遷移到生產(chǎn)環(huán)境Linux服務(wù)器，依次包括以下幾方面的工作內(nèi)容：根據(jù)性能測試調(diào)整Linux服務(wù)器配置、遷移應(yīng)用到生產(chǎn)環(huán)境Linux服務(wù)器、完成割接前驗證測試和正式割接上線。

（4）運維與優(yōu)化

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

2.3 遷移相關(guān)問題及解決方案

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

（1）問題描述

遷移后的系統(tǒng)運行在x86平臺上，相比于遷移前的小型機環(huán)境，需要重新估算服務(wù)器CPU、內(nèi)存、存儲和網(wǎng)絡(luò)帶寬等硬件資源，以滿足業(yè)務(wù)系統(tǒng)的需求。但遷移前后服務(wù)器體系結(jié)構(gòu)存在差異，需要尋找合適的估算維度和方法。

（2）解決方案

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

2.3.2 業(yè)務(wù)系統(tǒng)運行失敗

（1）問題描述

遷移前應(yīng)用系統(tǒng)中可能存在JNI調(diào)用、調(diào)用操作系統(tǒng)命令、用到OCI數(shù)據(jù)庫驅(qū)動等，遷移后由于操作系統(tǒng)發(fā)生變化，原先的調(diào)用代碼和調(diào)用命令失效，影響業(yè)務(wù)系統(tǒng)的正常運行。

（2）解決方案

由于調(diào)用的代碼是平臺相關(guān)性的，JNI調(diào)用同調(diào)用操作系統(tǒng)相關(guān)命令一樣，需要針對遷移后的Linux平臺重新進(jìn)行開發(fā)。如果是OCI驅(qū)動，在遷移后的平臺上安裝Oracle客戶端驅(qū)動即可。

2.3.3 部署腳本無法運行

（1）問題描述

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

（2）解決方案

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

2.3.4 系統(tǒng)日志如何追蹤

（1）問題描述

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

（2）解決方案

對于遷移后的日志分散狀況，建議將應(yīng)用程序中日志模塊剝離出來，發(fā)送到一個集中的地方進(jìn)行統(tǒng)一管理，形成統(tǒng)一的日志服務(wù)，以便日后跟蹤和定位日志信息。

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

（1）問題描述

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

（2）解決方案

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

3 云化部署模式研究

3.1 IaaS部署方案

3.1.1 簡單代理模式部署

BS架構(gòu)系統(tǒng)一般都通過負(fù)載均衡設(shè)備分發(fā)用戶請求，因此可以對整體用戶請求數(shù)、每臺服務(wù)器負(fù)載狀況、資源池負(fù)載信息進(jìn)行截取和分析，以判斷需要減少或增加新的應(yīng)用服務(wù)器，實現(xiàn)基礎(chǔ)IaaS彈性方案。

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

3.1.2 云管理平臺部署

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

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

（1）資源管理

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

（2）可視化部署管理

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

（3）配置和流程管理

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

（4）自動化部署引擎

根據(jù)可以發(fā)布的部署架構(gòu)和對應(yīng)的流程，在約定的時間內(nèi)實現(xiàn)對于服務(wù)的自動部署、服務(wù)的調(diào)整、補丁的分發(fā)等流程的自動化和手動執(zhí)行流程，并且根據(jù)執(zhí)行的結(jié)果進(jìn)行流程中各個步驟的檢查和監(jiān)控。因此，這個執(zhí)行模塊應(yīng)當(dāng)具備以下特性：從資源池中根據(jù)部署架構(gòu)找到資源；識別和執(zhí)行有效的流程；執(zhí)行各個步驟的狀態(tài)監(jiān)控；自動執(zhí)行引擎可以是面向多種平臺環(huán)境的集成工具。

（5）服務(wù)監(jiān)控管理

提供對于業(yè)務(wù)的監(jiān)控功能，并且根據(jù)監(jiān)控數(shù)據(jù)和已知的業(yè)務(wù)優(yōu)先級，提供觸發(fā)自動化流程的資源整合或調(diào)整流程，實現(xiàn)從服務(wù)質(zhì)量到資源分配的智能化流程。因此，該模塊應(yīng)當(dāng)具備以下特性：對于應(yīng)用服務(wù)響應(yīng)時延（服務(wù)質(zhì)量）的采集和定義，確定觸發(fā)條件；對于觸發(fā)流程的數(shù)據(jù)導(dǎo)入，確定觸發(fā)流程；對于全系統(tǒng)中響應(yīng)時延的鑒別，確認(rèn)和定位應(yīng)用服務(wù)的服務(wù)質(zhì)量和服務(wù)質(zhì)量關(guān)系；可拓展到CTMBOSS的全業(yè)務(wù)流程，即可以適應(yīng)復(fù)雜環(huán)境而不是目前單一的應(yīng)用服務(wù)環(huán)境。

3.2 PaaS部署方案

BS架構(gòu)系統(tǒng)一般運行在BEA、WAS、TUXEDO等商業(yè)中間件平臺上，因此可采用JavaEE Cloud平臺對中間件平臺能力進(jìn)行統(tǒng)一管理，實現(xiàn)PaaS云計算。JavaEE Cloud平臺包含完整的JavaEE應(yīng)用基礎(chǔ)運行環(huán)境，并基于虛擬化技術(shù)、自動化及自優(yōu)化技術(shù)，為JavaEE應(yīng)用提供了動態(tài)、彈性和智能化的運行環(huán)境，其邏輯架構(gòu)如圖4所示，各組件功能描述如下。

3.2.1 應(yīng)用路由控制組件

應(yīng)用路由控制組件是JavaEE Cloud環(huán)境接收客戶端請求的統(tǒng)一接入點，該組件依據(jù)預(yù)定義的策略及運行時應(yīng)用負(fù)載和JavaEE Cloud的狀態(tài)，動態(tài)地控制應(yīng)用請求的路由和負(fù)載分派，其主要功能包括以下部分。

（1）環(huán)境感知

應(yīng)用路由控制組件可以感知到JavaEE Cloud環(huán)境中的應(yīng)用相關(guān)信息，包括應(yīng)用服務(wù)接口（URL）、起停狀態(tài)、部署狀況、支持應(yīng)用運行的應(yīng)用服務(wù)器實例的運行狀態(tài)以及硬件資源的負(fù)載狀況等，同時，該組件還可以感知應(yīng)用請求的相關(guān)信息，這些信息是應(yīng)用路由控制組件進(jìn)行動態(tài)路由和負(fù)載分派的基礎(chǔ)。

（2）智能路由

應(yīng)用路由控制組件以感知到運行時狀態(tài)信息（應(yīng)用請求及應(yīng)用運行狀況）為基礎(chǔ)，依據(jù)預(yù)定義的路由策略，在運行時動態(tài)決定應(yīng)用請求的路由目標(biāo)。路由策略可以基于應(yīng)用請求及應(yīng)用運行狀況的相關(guān)信息進(jìn)行定義。同時，智能路由還滿足會話親和原則，支持負(fù)載分派策略和流量控制策略。

（3）動態(tài)負(fù)載均衡

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

（4）流量控制

應(yīng)用路由控制組件可以基于預(yù)定義策略和運行時狀況動態(tài)控制分派到JavaEE Cloud環(huán)境的應(yīng)用訪問流量。當(dāng)出現(xiàn)資源競爭或服務(wù)器過載時，應(yīng)用路由控制組件將基于相關(guān)策略，通過流量控制，進(jìn)行有效的調(diào)節(jié)，確保應(yīng)用的服務(wù)質(zhì)量和可用性。

3.2.2 運行時核心組件

JavaEE Cloud運行時核心組件是Java Cloud提供服務(wù)的主體，該組件實現(xiàn)了具備虛擬化和動態(tài)特性的JavaEE應(yīng)用運行環(huán)境，該組件提供的主要服務(wù)包括以下幾種。

（1）JavaEE應(yīng)用服務(wù)器基礎(chǔ)服務(wù)

運行時核心組件提供完整的JavaEE應(yīng)用基礎(chǔ)運行環(huán)境，支持JavaEE 5標(biāo)準(zhǔn)，提供必要的應(yīng)用容器服務(wù)，提供安全控制、管理監(jiān)控等基礎(chǔ)服務(wù)，并支持Web服務(wù)等開放標(biāo)準(zhǔn)，支持主流數(shù)據(jù)庫。該組件應(yīng)廣泛支持主流的操作系統(tǒng)和硬件平臺，并可部署于物理或邏輯服務(wù)器上。

（2）JavaEE應(yīng)用服務(wù)器虛擬化服務(wù)

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

（3）動態(tài)計算資源調(diào)度服務(wù)

運行時核心組件可以基于運行時應(yīng)用的運行狀態(tài)和預(yù)定義的相關(guān)策略，通過動態(tài)控制應(yīng)用服務(wù)器的啟動停止實現(xiàn)動態(tài)調(diào)度計算資源，由此，支持應(yīng)用運行的應(yīng)用服務(wù)器實例數(shù)量，可在運行時動態(tài)決定，并可進(jìn)行靈活調(diào)整，為計算資源共享和應(yīng)用服務(wù)質(zhì)量管理提供了基礎(chǔ)。

（4）應(yīng)用服務(wù)質(zhì)量管理服務(wù)

運行時核心組件支持應(yīng)用服務(wù)級別（包括基于性能指標(biāo)和優(yōu)先級的定義）的定義。運行時核心組件將依托動態(tài)計算資源調(diào)度服務(wù)，保證應(yīng)用的服務(wù)質(zhì)量。當(dāng)運行時核心組件監(jiān)控到應(yīng)用的服務(wù)級別不能得到滿足時，運行時核心組件將自動為該應(yīng)用啟動額外的應(yīng)用服務(wù)器實例，保證服務(wù)質(zhì)量。反之，則可以自動停止空閑應(yīng)用服務(wù)器實例，以釋放計算資源供其他應(yīng)用使用。

（5）自動化智能運維服務(wù)

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

3.2.3 管理組件

管理組件指JavaEE Cloud平臺的管理和監(jiān)控工具，通過該工具可定義和配置運行時核心組件和應(yīng)用路由控制組件，部署并管理應(yīng)用系統(tǒng)，并可監(jiān)控各個組件及應(yīng)用的運行狀態(tài)。

3.3 部署模式比較

BS架構(gòu)系統(tǒng)Web及應(yīng)用層在實施云化時，可結(jié)合系統(tǒng)實際狀況，選擇3種云化方式中的一種進(jìn)行實施，3種部署方案的優(yōu)缺點比較見表1。

表1 3種部署方案的優(yōu)缺點比較

3.3.1相關(guān)研究工作

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

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

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

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

3.3.2 本文解決方案的特點

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

對電信BS架構(gòu)系統(tǒng)從小型機遷移至PC服務(wù)器的關(guān)鍵問題進(jìn)行了深入研究。

以電信BS架構(gòu)系統(tǒng)現(xiàn)狀為出發(fā)點，研究其實現(xiàn)IaaS和PaaS的具體方案。對比相關(guān)研究工作，本文解決方案無需改動應(yīng)用系統(tǒng)代碼，對電信實際生產(chǎn)系統(tǒng)而言具有較好的風(fēng)險控制，此外云化成本投入較少，無需重新開發(fā)代碼等大量工作。

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

云管理平臺IaaS解決方案，給出了采用云管理平臺實現(xiàn)BS架構(gòu)系統(tǒng)IaaS云計算的功能架構(gòu)關(guān)系，對于云計算在IT支撐系統(tǒng)中的大規(guī)模落地，具有較好的參考意義。

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

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

4 演進(jìn)路徑及建議

電信BS架構(gòu)系統(tǒng)遷移及云化演進(jìn)策略建議如下。

（1）BS架構(gòu)系統(tǒng)選取路徑

建議先從電信MBOSS中選擇業(yè)務(wù)邏輯相對簡單的系統(tǒng)，如CRM、網(wǎng)上營業(yè)廳、計費/10000接口等，再逐步滲透至電信MBOSS中的BS架構(gòu)，可以采用負(fù)載均衡設(shè)備水平分擔(dān)的應(yīng)用進(jìn)行遷移，逐步實現(xiàn)整體BS架構(gòu)系統(tǒng)Web及應(yīng)用服務(wù)器層PC化。

（2）部署方案推進(jìn)建議

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

5 遷移風(fēng)險及防范

系統(tǒng)遷移后在系統(tǒng)代碼、系統(tǒng)日志、部署腳本以及系統(tǒng)部署架構(gòu)方面都存在一定的變化，主要的風(fēng)險需要通過遷移前的測試來避免，需主要關(guān)注以下幾方面。

·顆粒度細(xì)化后系統(tǒng)模塊間的交互，通常由遷移前的本地調(diào)用轉(zhuǎn)換成遠(yuǎn)程調(diào)用，需要測試其相關(guān)的服務(wù)調(diào)用是否成功。

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

·系統(tǒng)遷移后EJB調(diào)用也需要進(jìn)行分別測試通過。

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

·建議采用分階段模塊遷移方式進(jìn)行，以降低遷移過程的風(fēng)險。

·系統(tǒng)遷移過程存在一定風(fēng)險，需要準(zhǔn)備回退方案。建議通過4層交換機進(jìn)行手工切換，保證遷移后的系統(tǒng)若在試運行過程中發(fā)現(xiàn)異常，可立即切換到遷移前的生產(chǎn)環(huán)境上。

6 結(jié)束語

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

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

2 涂艷麗.云計算及在IT支撐系統(tǒng)中的應(yīng)用.中國通信學(xué)會第六屆學(xué)術(shù)年會論文集，2009

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

4 陳捷.云計算在電信IT支撐系統(tǒng)應(yīng)用的研究.2011年信息通信網(wǎng)絡(luò)技術(shù)委員會年會征文，2011

5 孫偉龍.基于IaaS云計算的Web應(yīng)用技術(shù)研究.南京理工大學(xué)碩士學(xué)位論文，2011

6 曾述青.基于PaaS平臺電信互聯(lián)網(wǎng)融合業(yè)務(wù)的研究.華南理工大學(xué)碩士學(xué)位論文，2011

7 肖家立.企業(yè)級應(yīng)用架構(gòu)研究：SOA架構(gòu)融合SaaS模式.價值工程，2011（33）

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

9 劉楓.基于Google云計算的Web應(yīng)用與開發(fā).電腦開發(fā)與應(yīng)用，2011（5）