隨著互聯網技術及其應用的快速發展，互聯網業務提供者越來越呈現小團隊、草根化的趨勢。這些小型的業務提供者往往具備新穎的技術和業務理念，但由于規模不足、資本薄弱，需要面對應用訪問網絡能力困難和應用提供成本高、風險大等挑戰。這些挑戰嚴重影響了“草根”開發者業務創新能力的發揮。近年來，高速發展的云計算技術為解決上述困境提供了可能。在云計算的 3 種應用形式中，PaaS 是云計算技術與業務提供平臺相結合的產物，它不但可以為更高可用性、更具擴展性的應用提供基礎平臺，還可以提高硬件資源的利用率，降低業務運營成本，被認為是解放“草根”開發者業務創新能力行之有效的解決方案。
筆者首先從對工業界有影響的PaaS平臺的分析和比較入手，深入研究了 PaaS 平臺的體系結構，抽象出 PaaS 平臺的通用概念模型; 然后針對互聯網應用的特殊需求，提出了面向互聯網應用的 PaaS 平臺體系結構; 最后通過對具體項目中該體系結構的實現和測試，進一步說明了該體系結構的有效性和高效性。
1 相關工作
目前，以 Google、新浪為代表的眾多互聯網公司都推出了基于云計算技術的 PaaS 平臺，如 GAE( google app engine) 和 SAE ( sina app engine)。
GAE 是 Google 管理的數據中心用于 web 應用程序的開發和托管平臺，是互聯網應用服務的一個引擎，支持 Python 和 Java 開發。SAE 是由新浪公司開發運營的開放云計算平臺的核心組成部分，其目標是為應用開發者提供穩定、快捷、透明、可控的服務化平臺，支持 Java 和 PHP5 運行環境。有了 GAE 和 SAE這樣的 PaaS 平臺，用戶不用再為建設一個小型網站而去租用主機并選擇托管商。用戶只需要利用 PaaS平臺，就能創建、測試和部署應用與服務，與傳統的軟件開發相比，費用要低得多。
通過對常見 PaaS 平臺的分析可以看出，PaaS平臺應具備如下功能特性。首先，PaaS 平臺為應用開發提供了一系列非功能屬性支持，具體包含以下 3 點: 第一，平臺提供了應用程序的開發和運行環境，開發者不再需要租用和維護軟硬件設備，同時免去了繁瑣復雜的應用部署過程; 第二，平臺提供了應用程序的運行維護能力，開發者通過平臺可以得知應用的運行狀態和訪問統計信息，全面掌握用戶對應用的使用情況; 第三，平臺提供了應用的高可用性和高可擴展性，開發者無需關注底層硬件的規模和處理能力，平臺會根據應用負載自動調整服務規模。其次，PaaS 平臺提供了大量的網絡能力，開發者可以便捷地在其應用中調用這些能力。
然而，現有的 PaaS 平臺也存在一些不足。第一，應用托管環境單一化，僅提供特定編程語言或腳本語言的運行環境。由于應用往往對相應的運行環境配置有較高的依賴，這種單一化的運行環境將導致應用兼容性低，需要引入應用遷移成本。第二，能力組件封閉化。雖然 PaaS 平臺向應用提供一系列能力已經成為 PaaS 平臺的標準做法，但是僅依靠平臺提供商提供能力的做法顯然大大限制了平臺能力的豐富性，無法滿足應用開發者對能力多樣化的需求。因此，提出的互聯網應用 PaaS 平臺將重點關注和解決如下問題: 第一，為各種應用提供運行環境，不僅支持常用編程語言和腳本語言，還可以提供兼容性更強的、更為通用的運行環境，即將虛擬機也作為一種運行環境提供給應用; 第二，提供開放式的能力組件機制，平臺本身不但可以向應用提供能力，而且允許第三方基于此平臺提供能力。
2 PaaS 平臺概念模型
PaaS 平臺概念模型如圖 1 所示。PaaS 平臺概念模型采用分層結構，由用戶平面 ( UP) 、應用平面( AP) 、資源平面( RP) 、物理平面( PP) 和管理平面( MP) 組成。UP 反映了 PaaS 平臺的目標使用者，即應用開發者( Dev/Developer) 。應用開發者可以開發多個應用，并將其部署到平臺中。
AP 反映了應用開發者所開發的大量的不同類型的應用( APP/Application) ，每個應用可以包含多個應用實例( AI) 。這些應用具有不同的資源消耗和用戶訪問模型，包括應用邏輯、應用的計算和通信資源開銷以及用戶請求的分布情況。這些信息將作為MP 對應用進行管理的依據。
圖 1 PaaS 平臺概念模型
RP 反映了 AI 運行的邏輯環境，由一系列不同類型的容器( CT/container) 組成。這些容器將 PP 所提供的以主機為單位的分散物理資源匯聚在一起，形成資源池。在該平面中，不同類型的 AI 運行于相應的容器中，使用容器所提供的計算、存儲和連接等資源。因容器中承載的應用類型不同，容器可以分為多種類型，如 Java web 服務器容器( Java WS-contain-er) 、虛擬機容器( VM-container) 等。鑒于容器是一個相對獨立的邏輯運行環境，容器中既可以運行第三方應用，也可以運行平臺的自建應用。同時，第三方應用也可以作為平臺的能力成為其他第三方應用可調用的組件，從而使得 PaaS 平臺支持能力具有高的可擴充性。
PP 反映了 PaaS 平臺底層的物理資源，由一系列物理實體( PE) 組成，包括物理主機( HS/host) 、存儲器( ST/storage) 和交換機( SW /switch) 等硬件設備，為平臺提供了底層的計算、存儲和通信能力。
MP 負責完成對其他各平面的調度和控制。該平面包含 2 個組件: 資源調度組件( RA) 和任務調度組件( TS) 。RA 定義了應用經過多層映射最終分布到物理主機上的部署關系，即應用與 AI 的對應關系( APP-AI) 、AI 與容器的對應關系( AI-CT) 以及容器與主機的對應關系( CT-HS) 。TS 定義了應用訪問請求( REQ/request) 到達平臺后的轉發規則，即為此請求選擇合適的 AI 規則( REQ-AI) 。
3 面向互聯網應用 PaaS 平臺
3. 1 體系結構
PaaS 平臺概念模型提供了面向互聯網應用的PaaS 平臺的設計思路。基于此 PaaS 平臺概念模型，面向互聯網應用的 PaaS 平臺體系結構如圖 2 所示。該體系結構主要包含 3 個組件，分別是應用集群管理( AppMaster) 、智能應用路由器( AppRouter) 和應用服務器集群( AppServer) 。
圖 2 面向互聯網應用的 PaaS 平臺體系結構
AppMaster 是 PaaS 平臺的控制核心，它負責加載 RA 以完成整個平臺的資源調度工作，包括應用的部署和動態伸縮、收集平臺的運行狀態和統計信息等。AppMaster 支持開放式的資源調度算法，即資源調度算法以組件的形式插入 AppMaster 中。App-Master 根據平臺規模大小等因素動態加載不同的ra，完成資源調度工作。
AppRouter 位于應用訪問的前端，其內部維護一份全局路由表，負責加載 ts，完成對應用訪問請求的路由和轉發，同時調整應用副本間的負載均衡。AppRouter 也支持開放式的任務調度算法。此外，為了提高應用訪問的效率和可靠性，平臺入口處前置一組反向代理，對應用請求進行分發，即應用的訪問請求經由網關，通過反向代理路由至相應的處理節點。AppServer 是包含大量主機的服務器集群，用于部署應用程序和處理應用請求。每臺主機上運行著一個節點代理和若干容器。節點代理負責執行來自AppMaster 的指令，并向 AppMaster 報告主機和容器的負載情況以及應用運行狀態。容器用于承載部署到平臺上的應用，包含 Java web 服務器容器和虛擬機容器 2 類，分別用于運行 Java web 應用和虛擬機應用。
3. 2 部署模型
PaaS 平臺的部署模型如圖 3 所示。
圖 3 PaaS 平臺的部署模型
物理主機通過交換機連接，每個物理主機承載多個不同類型的容器，不同類型的容器內運行相應類型的 AI。其中，一部分容器面向應用開發者，運行第三方應用; 另一部分容器面向平臺，運行平臺自建應用，完成對平臺的管理和控制，如資源調度和任務調度等。
3. 3 關鍵技術
面向互聯網應用 PaaS 平臺的實現涉及如下一系列關鍵技術。
3. 3. 1 通用容器
如圖 4 所示，通用容器( GC) 技術將包括 Javaweb 服務器和虛擬機在內的各類應用運行環境加以封裝，對外提供統一的管理和操作接口，以達到統一承載多種類型應用的目的，從而提高 PaaS 平臺提供應用運行環境的靈活性。
圖 4 GC 分層結構
根據應用種類的不同，GC 可以分為 Java web服務器容器和虛擬機容器等，前者用于運行 Javaweb 服務器，部署 Java web 應用，其粒度低，針對性強，但兼容性較低; 后者用于運行第三方虛擬機軟件，向用戶提供虛擬主機環境，其通用性強，具備更好的兼容性。根據應用性質的不同，GC 還可以分為平臺自建容器和第三方容器。前者用于運行 PaaS 平臺自身的部分應用組件，如能力開放網關就是作為應用運行在 GC 當中的; 后者用于運行應用開發者所開發的第三方應用程序。
GC 的核心在于對容器接口的抽象，即不論內部包含哪種運行環境，容器總是對外提供統一的接口。GC 目前支持的管理接口如表 1 所示。
表 1 GC 管理接口列表
3. 3. 2 資源調度
資源調度技術是指 PaaS 平臺能自動檢測應用負載，調整資源的分配和伸縮，以實現負載均衡并提高資源的利用率，從而保障對應用提供透明的高可擴展性。具體來說就是主動完成 AI 副本的“創建 /激活”和“去激活 /撤銷”，從而保證應用處理能力的平滑擴展。
根據平臺規模和應用類型等因素的不同，資源調度算法的側重點亦有所不同。例如，當平臺規模較小時，調度算法應重點關注資源利用率; 當平臺規模較大時，調度算法則應該更加關注集群的能耗情況等。因此，面向互聯網應用的 PaaS 平臺支持插件式的開放調度算法( 見圖 2) ，新的調度算法可以通過引入新的調度算法組件來實現。
目前，面向互聯網應用的 PaaS 平臺實現了一種多粒度的資源調度方案，即基于主機粒度判斷集群負載情況，基于 GC 粒度完成應用的動態調度。該方案劃分為 2 個階段: 第 1 階段是數據準備階段，完成主機負載信息的收集，從而判斷主機負載高低; 第 2階段是動態調度階段，基于負載信息完成應用的動態擴容和收縮。具體實現方案如圖 5 所示。
圖 5 PaaS 平臺資源調度
4 結束語
基于提出的面向互聯網應用的 PaaS 平臺體系結構，項目組完成了相應的設計和實現工作。PaaS平臺部署于 4 臺聯想 R510 G7 服務器( CPU: 2 × 4核英特爾 至強 處理器 E5606; 內存: 4 × 4GB R-ECC DDR3-1333) ，AppMaster 等內部實體運行在 2臺服務器上，同時 4 臺服務器均可作為 AppServer 承載應用開發者的第三方應用。PaaS 平臺的運行結果表明，該平臺可以成功完成對 Java 應用和虛擬機的托管，切實提高平臺的應用兼容性。
此外，項目組還針對 PaaS 平臺的各項功能做了一系列測試。這些測試包括應用的高可用性測試、根據業務量的動態應用處理能力進行擴展測試等。
應用的高可用性測試是指當應用的某個副本所在服務器宕機之后，平臺是否能正常處理后續的應用訪問請求，并盡快完成應用副本的恢復。測試結果表明，由于平臺支持應用的多副本部署，所以當某臺或某些服務器宕機之后，平臺可以繼續正常處理相關應用的訪問請求，并可以在 30 s( 約 3 個心跳周期) 內完成宕機服務器上全部應用的副本恢復。
應用處理能力擴展測試是指平臺是否能根據應用訪問量動態調整應用副本的數量，以實現平臺資源利用率最大化。測試結果表明，應用訪問量的持續激增會導致服務器長時間負載過高，平臺的 RA 可以在 10 s( 約 1 個心跳周期) 內檢測到訪問量的激增，并在觀察若干心跳周期后完成應用副本的擴充，擴充時延不超過 15 s( 約 1 個調度周期) 。
通過這一系列測試可以看出，所提出的 PaaS 平臺體系結構不但能提供對應用透明的高可用性和高可擴展性支持，而且在應用兼容性和擴充性方面有較大優勢。下一步工作將對面向互聯網應用的 PaaS平臺與業界現有的 PaaS 平臺進行比較，并考察平臺在不同調度算法下的性能，以驗證和調整當前的互聯網應用 PaaS 平臺體系結構。
核心關注：拓步ERP系統平臺是覆蓋了眾多的業務領域、行業應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業務領域的管理，全面涵蓋了企業關注ERP管理系統的核心領域，是眾多中小企業信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.guhuozai8.cn/
本文標題：互聯網應用PaaS平臺體系結構
相關文章
