2.3　平臺即服務（PaaS）

2.3.1　PaaS概述

所謂PaaS，實際上是指將軟件研發的平臺（或業務基礎平臺）作為一種服務，以SaaS的模式提交給用戶。因此，PaaS也是SaaS模式的一種應用。但是，PaaS的出現可以加快SaaS的發展，尤其是加快SaaS應用的開發速度。在2007年國內外SaaS廠商先后推出自己的PaaS平臺。

PaaS之所以能夠推進SaaS的發展，主要在于它能夠提供企業進行定制化研發的中間件平臺，同時涵蓋數據庫和應用服務器等。PaaS可以提高在Web平臺上利用的資源數量。例如，可通過遠程Web服務使用數據即服務（Data as a Service），還可以使用可視化的API，甚至像800APP（八百名CRM專家）的PaaS平臺還允許混合并匹配適合應用的其他平臺。用戶或者廠商基于PaaS平臺可以快速開發自己所需要的應用和產品。同時，PaaS平臺開發的應用能更好地搭建基于SOA架構的企業應用。

此外，PaaS可以幫助SaaS運營商進行產品多元化和產品定制化。例如，Salesforce的PaaS平臺讓更多的ISV成為其平臺的客戶，從而開發出基于他們平臺的多種SaaS應用，使其成為多元化軟件服務供應商，而不再只是一家CRM隨選服務提供商。而國內的SaaS廠商800app通過PaaS平臺，改變了僅是CRM供應商的市場定位，實現了BTO（Built To Order：按訂單生產）和在線交付流程。使用800app的PaaS開發平臺，用戶不再需要任何編程即可開發包括CRM、OA、HR、SCM、進銷存管理等任何企業管理軟件，而且不需要使用其他軟件開發工具并立即在線運行。

面向個人的EC站點的巨頭公司Amazon，把最初為了自己公司運營用的系統平臺進行出租，用戶可以自由選擇操作系統和中間軟件，以這樣的方式提供硬件以及軟件平臺作為服務。從2006年開始Amazon EC與Amazon S3開始作為服務推向市場。

作為現代軟件業霸主和新時代計算先驅的Google，以搜索引擎與新型廣告模式而聞名，他們使用便宜的計算機，強有力的中間件及其先進技術裝備出了世界上最強大的數據中心和超高性能的并行計算群。2008年4月發表的PaaS服務（Google App Engine）和Amazon的EC2、S3、SimpleDB等服務擁有相似的功能。這些穩定的平臺上搜索引擎、GMail等服務同樣也在運行。類似地，以ASP-SaaS成功的Salesforce，2007年開始用于提供SaaS的系統基盤對外公開，用Force這個名稱開始進入PaaS業務。其所提供的PaaS服務里采用Java類似的語言Apex以及Eclipse開發平臺，整合的開發環境也作為服務進行提供（Development as a Service）。

上述的Google/Amazon/Salesforce三個軟件巨頭非常重視PaaS這種新的商業模式，Amazon的PaaS服務為了用戶可以自由地組合服務提供了更多的自由度，Google為了提供更多的服務使用戶能夠方便使用，去掉了一些煩瑣的作業。Google/Salesforce的PaaS不僅是提供基礎硬件和開發環境，同樣把真正的平臺作為一種服務（PaaS）來提供。

2.3.2　PaaS的核心功能

云計算平臺層與傳統的應用平臺在所提供的服務方面有很多相似之處。傳統的應用平臺，如本地Java環境或Net環境都定義了平臺的各項服務標準、元數據標準、應用模型標準等規范，并為遵循這些規范的應用提供了部署、運行和卸載等一系列流程的生命周期管理。云計算平臺層是對傳統應用平臺在理論與實踐上的一次升級，這種升級給應用的開發、運行和運營各個方面都帶來了變革。平臺層需要具備一系列特定的基本功能，才能滿足這些變革的需求。

2.3.2.1　開發測試環境

平臺層對于在其上運行的應用來說，首先扮演的是開發平臺的角色。一個開發平臺需要清晰地定義應用模型，具備一套API代碼庫，提供必要的開發測試環境。

一個完備的應用模型包括開發應用的編程語言、應用的元數據模型，以及應用的打包發布格式。一般情況下，平臺層基于對傳統應用平臺的擴展而構建，因此應用可以使用流行的編程語言進行開發，如Google APP Engine目前只支持hon和Java這兩種編程語言。即使平臺層具有特殊的實現架構，開發語言也應該在語法上與現有編程語言盡量相似，從而縮短開發人員的學習時間，如Salesforce.com使用的是自有編程語言Apex，該語言在語法和符號表示上與Java類似。元數據在應用與平臺層之間起著重要的接口作用，比如平臺層在部署應用的時候需要根據應用的元數據對其進行配置，在應用運行時也會根據元數據中的記錄為應用綁定平臺層服務。應用的打包格式需要指定應用的源代碼、可執行文件和其他不同格式的資源文件應該以何種方式進行組織，以及這些組織好的文件如何整合成一個文件包，從而以統一的方式發布到平臺層。

平臺層所提供的代碼庫（SDK）及其API對于應用的開發至關重要。

代碼庫是平臺層為在其上開發應用而提供的統一服務，如界面繪制、消息機制等。定義清晰、功能豐富的代碼庫能夠有效地減少重復工作，縮短開發周期。傳統的應用平臺通常提供自有的代碼庫，使用了這些代碼庫的應用只能在此唯一的平臺上運行。在云計算平臺中，某一個云提供商的平臺層代碼庫可以包含由其他云提供商開發的第三方服務，這樣的組合模式對用戶的應用開發過程是透明的。如圖2-4所示，假設某云平臺提供了自有服務A與B，同時該平臺也整合了來自第三方的服務D。那么，對于用戶來說，看到的是該云平臺提供的A、B和D三種服務程序接口，可以無差異地使用它們?？梢?，平臺層作為一個開發平臺應具有更好的開放性，為開發者提供更豐富的代碼庫和API。

平臺層需要為用戶提供應用的開發和測試環境。通常，這樣的環境有兩種實現方式：一是通過網絡向軟件開發者提供一個在線的應用開發和測試環境，即一切的開發測試任務都在服務器端完成。這樣做的一個好處是開發人員不需要安裝和配置開發軟件，但需要平臺層提供良好的開發體驗，而且要求開發人員所在的網絡穩定且有足夠的帶寬。二是提供離線的集成開發環境，為開發人員提供與真實運行環境非常類似的本地測試環境，支持開發人員在本地進行開發與調試。這種離線開發的模式更符合大多數開發人員的經驗，也更容易獲得良好的開發體驗。在開發測試結束以后，開發人員需要將應用上傳到云中，讓它運行在平臺層上。

2.3.2.2　運行時環境

完成開發測試工作以后，開發人員需要做的就是對應用進行部署上線。應用上線首先要將打包好的應用上傳到遠程的云平臺上。然后，云平臺通過解析元數據信息對應用進行配置，使應用能夠正常訪問其所依賴的平臺服務。平臺層的不同用戶之間是完全獨立的，不同的開發人員在創建應用的時候不可能對彼此應用的配置及其如何使用平臺層進行提前約定，配置沖突可能導致應用不能正確運行。因此，在配置過程中需要加入必要的驗證步驟，以避免沖突的發生。配置完成之后，將應用激活即可使應用進入運行狀態。

以上云應用的部署激活是平臺層的基本功能。此外，該層還需要具備更多的高級功能來充分利用基礎設施層提供的資源，通過網絡交付給客戶高性能、安全可靠的應用。為此，平臺層與傳統的應用運行環境相比，必須具備三個重要的特性：隔離性、可伸縮性和資源的可復用性。

①隔離性具有兩個方面的含義，即應用間隔離和用戶間隔離。應用間隔離指的是不同應用之間在運行時不會相互干擾，包括對業務和數據的處理等各個方面。應用間隔離保證應用都運行在一個隔離的工作區內，平臺層需要提供安全的管理機制對隔離的工作區進行訪問控制。用戶間隔離是指同一解決方案不同用戶之間的相互隔離，比如對不同用戶的業務數據相互隔離，或者每個用戶都可以對解決方案進行自定義配置而不影響其他用戶的配置。

②可伸縮性是指平臺層分配給應用的處理、存儲和帶寬能夠根據工作負載或業務規模的變化而變化，即工作負載或業務規模增大時，平臺層分配給應用的處理能力能夠增強；當工作負載或者業務規模下降時，平臺層分配給應用的處理能力可以相應減弱。比如，當應用需要處理和保存的數據量不斷增大時，平臺層能夠按需增強數據庫的存儲能力，從而滿足應用對數據存儲的需求?？缮炜s性對于保障應用性能、避免資源浪費都是十分重要的。

③資源的可復用性是指平臺層能夠容納數量眾多的不同應用的通用平臺，滿足應用的擴展性。當用戶應用業務量提高、需要更多的資源時，可以向平臺層提出請求，讓平臺層為其分配更多的資源。當然，這并不是說平臺層所擁有的資源是無限的，而是通過統計復用的辦法使得資源足夠充裕，能夠保證應用在不同負載下可靠運行，使其感覺平臺層擁有的資源仿佛是無限的，用戶可以隨時按需索取。這就需要平臺層所能使用的資源數量本身是充足的，并要求平臺層能夠高效利用各種資源，對不同應用所占有的資源根據其工作負載變化來進行實時動態的調整和整合。

2.3.2.3　運營環境

隨著業務和客戶需求的變化，開發人員往往需要改變現有系統從而產生新的應用版本。云計算環境簡化了開發人員對應用的升級任務，因為平臺層提供了升級流程自動化向導。為了提供這一功能，云平臺要定義出應用的升級補丁模型及一套內部的應用自動化升級流程。當應用需要更新時，開發人員需要按照平臺層定義的升級補丁模型制作應用升級補丁，使用平臺層提供的應用升級腳本上傳升級補丁、提交升級請求。平臺層在接收到升級請求后，解析升級補丁并執行自動化的升級過程。應用的升級過程需要考慮兩個重要問題：一是升級操作的類型對應用可用性的影響，即在升級過程中客戶是否還可以使用老版本的應用處理業務；二是升級失敗時如何恢復，即如何回應升級操作對現有版本應用的影響。

在應用運行過程中，平臺層需要對應用進行監控。一方面，用戶通常需要實時了解應用的運行狀態，比如應用當前的工作負載及是否發生了錯誤或出現異常狀態等；另一方面，平臺層需要監控解決方案在某段時間內所消耗的系統資源。不同目的的監控所依賴的技術是不同的。對于應用運行狀態的監控，平臺層可以直接檢測到響應時間、吞吐量和工作負載等實時信息，從而判斷應用的運行狀態。比如，可以通過網絡監控來跟蹤不同時間段內應用所處理的請求量，并由此來繪制工作負載變化曲線，并根據相應的請求響應時間來評估應用的性能。

對于資源消耗的監控，可以通過調用基礎設施層就服務來查詢應用的資源消耗狀態，這是因為平臺層為應用分配的資源都是通過基礎設施層獲得的。比如通過使用基礎設施層服務為某應用進行初次存儲分配。在運行時，該應用同樣通過調用基礎設施層服務來存儲數據。這樣，基礎設施層就記錄了所有與該應用存儲相關的細節，以供平臺層查詢。

用戶所需的應用不可能是一成不變的，市場會隨著時間推移不斷改變，總會有一些新的應用出現，也會有老的應用被淘汰。平臺層需要提供卸載功能幫助用戶淘汰過時的應用。平臺層除了需要在卸載過程中刪除應用程序，還需要合理地處理該應用所產生的業務數據。通常，平臺層可以按照用戶的需求選擇不同的處理策略，如直接刪除或備份后刪除等。平臺層需要明確應用卸載操作對用戶業務和數據的影響，在必要的情況下與客戶簽署書面協議，對卸載操作的功能范圍和工作方式做出清楚說明，避免造成業務上的損失和不必要的糾紛。

平臺層運營環境還應該具備統計計費功能。這個計費功能包括了兩個方面：一是根據應用的資源使用情況，對使用了云平臺資源的ISV計費，這一點前面在基礎設施層的資源監控功能中有所提及；二是根據應用的訪問情況，幫助ISV對最終用戶進行計費。通常，平臺層會提供諸如用戶注冊登錄、ID管理等平臺層服務，通過整合這些服務，ISV可以便捷地獲取最終用戶對應用的使用情況，并在這些信息的基礎上，加入自己的業務邏輯，對最終用戶進行細粒度的計費管理。