隨著互聯(lián)網(wǎng)技術(shù)及其應(yīng)用的快速發(fā)展，互聯(lián)網(wǎng)業(yè)務(wù)提供者越來越呈現(xiàn)小團(tuán)隊(duì)、草根化的趨勢(shì)。這些小型的業(yè)務(wù)提供者往往具備新穎的技術(shù)和業(yè)務(wù)理念，但由于規(guī)模不足、資本薄弱，需要面對(duì)應(yīng)用訪問網(wǎng)絡(luò)能力困難和應(yīng)用提供成本高、風(fēng)險(xiǎn)大等挑戰(zhàn)。這些挑戰(zhàn)嚴(yán)重影響了“草根”開發(fā)者業(yè)務(wù)創(chuàng)新能力的發(fā)揮。近年來，高速發(fā)展的云計(jì)算技術(shù)為解決上述困境提供了可能。在云計(jì)算的 3 種應(yīng)用形式中，PaaS 是云計(jì)算技術(shù)與業(yè)務(wù)提供平臺(tái)相結(jié)合的產(chǎn)物，它不但可以為更高可用性、更具擴(kuò)展性的應(yīng)用提供基礎(chǔ)平臺(tái)，還可以提高硬件資源的利用率，降低業(yè)務(wù)運(yùn)營(yíng)成本，被認(rèn)為是解放“草根”開發(fā)者業(yè)務(wù)創(chuàng)新能力行之有效的解決方案。

    筆者首先從對(duì)工業(yè)界有影響的PaaS平臺(tái)的分析和比較入手，深入研究了 PaaS 平臺(tái)的體系結(jié)構(gòu)，抽象出 PaaS 平臺(tái)的通用概念模型; 然后針對(duì)互聯(lián)網(wǎng)應(yīng)用的特殊需求，提出了面向互聯(lián)網(wǎng)應(yīng)用的 PaaS 平臺(tái)體系結(jié)構(gòu); 最后通過對(duì)具體項(xiàng)目中該體系結(jié)構(gòu)的實(shí)現(xiàn)和測(cè)試，進(jìn)一步說明了該體系結(jié)構(gòu)的有效性和高效性。

1 相關(guān)工作

    目前，以 Google、新浪為代表的眾多互聯(lián)網(wǎng)公司都推出了基于云計(jì)算技術(shù)的 PaaS 平臺(tái)，如 GAE( google app engine) 和 SAE ( sina app engine)。

    GAE 是 Google 管理的數(shù)據(jù)中心用于 web 應(yīng)用程序的開發(fā)和托管平臺(tái)，是互聯(lián)網(wǎng)應(yīng)用服務(wù)的一個(gè)引擎，支持 Python 和 Java 開發(fā)。SAE 是由新浪公司開發(fā)運(yùn)營(yíng)的開放云計(jì)算平臺(tái)的核心組成部分，其目標(biāo)是為應(yīng)用開發(fā)者提供穩(wěn)定、快捷、透明、可控的服務(wù)化平臺(tái)，支持 Java 和 PHP5 運(yùn)行環(huán)境。有了 GAE 和 SAE這樣的 PaaS 平臺(tái)，用戶不用再為建設(shè)一個(gè)小型網(wǎng)站而去租用主機(jī)并選擇托管商。用戶只需要利用 PaaS平臺(tái)，就能創(chuàng)建、測(cè)試和部署應(yīng)用與服務(wù)，與傳統(tǒng)的軟件開發(fā)相比，費(fèi)用要低得多。

    通過對(duì)常見 PaaS 平臺(tái)的分析可以看出，PaaS平臺(tái)應(yīng)具備如下功能特性。首先，PaaS 平臺(tái)為應(yīng)用開發(fā)提供了一系列非功能屬性支持，具體包含以下 3 點(diǎn): 第一，平臺(tái)提供了應(yīng)用程序的開發(fā)和運(yùn)行環(huán)境，開發(fā)者不再需要租用和維護(hù)軟硬件設(shè)備，同時(shí)免去了繁瑣復(fù)雜的應(yīng)用部署過程; 第二，平臺(tái)提供了應(yīng)用程序的運(yùn)行維護(hù)能力，開發(fā)者通過平臺(tái)可以得知應(yīng)用的運(yùn)行狀態(tài)和訪問統(tǒng)計(jì)信息，全面掌握用戶對(duì)應(yīng)用的使用情況; 第三，平臺(tái)提供了應(yīng)用的高可用性和高可擴(kuò)展性，開發(fā)者無需關(guān)注底層硬件的規(guī)模和處理能力，平臺(tái)會(huì)根據(jù)應(yīng)用負(fù)載自動(dòng)調(diào)整服務(wù)規(guī)模。其次，PaaS 平臺(tái)提供了大量的網(wǎng)絡(luò)能力，開發(fā)者可以便捷地在其應(yīng)用中調(diào)用這些能力。

    然而，現(xiàn)有的 PaaS 平臺(tái)也存在一些不足。第一，應(yīng)用托管環(huán)境單一化，僅提供特定編程語言或腳本語言的運(yùn)行環(huán)境。由于應(yīng)用往往對(duì)相應(yīng)的運(yùn)行環(huán)境配置有較高的依賴，這種單一化的運(yùn)行環(huán)境將導(dǎo)致應(yīng)用兼容性低，需要引入應(yīng)用遷移成本。第二，能力組件封閉化。雖然 PaaS 平臺(tái)向應(yīng)用提供一系列能力已經(jīng)成為 PaaS 平臺(tái)的標(biāo)準(zhǔn)做法，但是僅依靠平臺(tái)提供商提供能力的做法顯然大大限制了平臺(tái)能力的豐富性，無法滿足應(yīng)用開發(fā)者對(duì)能力多樣化的需求。因此，提出的互聯(lián)網(wǎng)應(yīng)用 PaaS 平臺(tái)將重點(diǎn)關(guān)注和解決如下問題: 第一，為各種應(yīng)用提供運(yùn)行環(huán)境，不僅支持常用編程語言和腳本語言，還可以提供兼容性更強(qiáng)的、更為通用的運(yùn)行環(huán)境，即將虛擬機(jī)也作為一種運(yùn)行環(huán)境提供給應(yīng)用; 第二，提供開放式的能力組件機(jī)制，平臺(tái)本身不但可以向應(yīng)用提供能力，而且允許第三方基于此平臺(tái)提供能力。

2 PaaS 平臺(tái)概念模型

    PaaS 平臺(tái)概念模型如圖 1 所示。PaaS 平臺(tái)概念模型采用分層結(jié)構(gòu)，由用戶平面 ( UP) 、應(yīng)用平面( AP) 、資源平面( RP) 、物理平面( PP) 和管理平面( MP) 組成。UP 反映了 PaaS 平臺(tái)的目標(biāo)使用者，即應(yīng)用開發(fā)者( Dev/Developer) 。應(yīng)用開發(fā)者可以開發(fā)多個(gè)應(yīng)用，并將其部署到平臺(tái)中。

    AP 反映了應(yīng)用開發(fā)者所開發(fā)的大量的不同類型的應(yīng)用( APP/Application) ，每個(gè)應(yīng)用可以包含多個(gè)應(yīng)用實(shí)例( AI) 。這些應(yīng)用具有不同的資源消耗和用戶訪問模型，包括應(yīng)用邏輯、應(yīng)用的計(jì)算和通信資源開銷以及用戶請(qǐng)求的分布情況。這些信息將作為MP 對(duì)應(yīng)用進(jìn)行管理的依據(jù)。

圖 1 PaaS 平臺(tái)概念模型

    RP 反映了 AI 運(yùn)行的邏輯環(huán)境，由一系列不同類型的容器( CT/container) 組成。這些容器將 PP 所提供的以主機(jī)為單位的分散物理資源匯聚在一起，形成資源池。在該平面中，不同類型的 AI 運(yùn)行于相應(yīng)的容器中，使用容器所提供的計(jì)算、存儲(chǔ)和連接等資源。因容器中承載的應(yīng)用類型不同，容器可以分為多種類型，如 Java web 服務(wù)器容器( Java WS-contain-er) 、虛擬機(jī)容器( VM-container) 等。鑒于容器是一個(gè)相對(duì)獨(dú)立的邏輯運(yùn)行環(huán)境，容器中既可以運(yùn)行第三方應(yīng)用，也可以運(yùn)行平臺(tái)的自建應(yīng)用。同時(shí)，第三方應(yīng)用也可以作為平臺(tái)的能力成為其他第三方應(yīng)用可調(diào)用的組件，從而使得 PaaS 平臺(tái)支持能力具有高的可擴(kuò)充性。

    PP 反映了 PaaS 平臺(tái)底層的物理資源，由一系列物理實(shí)體( PE) 組成，包括物理主機(jī)( HS/host) 、存儲(chǔ)器( ST/storage) 和交換機(jī)( SW /switch) 等硬件設(shè)備，為平臺(tái)提供了底層的計(jì)算、存儲(chǔ)和通信能力。

    MP 負(fù)責(zé)完成對(duì)其他各平面的調(diào)度和控制。該平面包含 2 個(gè)組件: 資源調(diào)度組件( RA) 和任務(wù)調(diào)度組件( TS) 。RA 定義了應(yīng)用經(jīng)過多層映射最終分布到物理主機(jī)上的部署關(guān)系，即應(yīng)用與 AI 的對(duì)應(yīng)關(guān)系( APP-AI) 、AI 與容器的對(duì)應(yīng)關(guān)系( AI-CT) 以及容器與主機(jī)的對(duì)應(yīng)關(guān)系( CT-HS) 。TS 定義了應(yīng)用訪問請(qǐng)求( REQ/request) 到達(dá)平臺(tái)后的轉(zhuǎn)發(fā)規(guī)則，即為此請(qǐng)求選擇合適的 AI 規(guī)則( REQ-AI) 。

3 面向互聯(lián)網(wǎng)應(yīng)用 PaaS 平臺(tái)

    3. 1 體系結(jié)構(gòu)

    PaaS 平臺(tái)概念模型提供了面向互聯(lián)網(wǎng)應(yīng)用的PaaS 平臺(tái)的設(shè)計(jì)思路�；�于此 PaaS 平臺(tái)概念模型，面向互聯(lián)網(wǎng)應(yīng)用的 PaaS 平臺(tái)體系結(jié)構(gòu)如圖 2 所示。該體系結(jié)構(gòu)主要包含 3 個(gè)組件，分別是應(yīng)用集群管理( AppMaster) 、智能應(yīng)用路由器( AppRouter) 和應(yīng)用服務(wù)器集群( AppServer) 。

圖 2 面向互聯(lián)網(wǎng)應(yīng)用的 PaaS 平臺(tái)體系結(jié)構(gòu)

    AppMaster 是 PaaS 平臺(tái)的控制核心，它負(fù)責(zé)加載 RA 以完成整個(gè)平臺(tái)的資源調(diào)度工作，包括應(yīng)用的部署和動(dòng)態(tài)伸縮、收集平臺(tái)的運(yùn)行狀態(tài)和統(tǒng)計(jì)信息等。AppMaster 支持開放式的資源調(diào)度算法，即資源調(diào)度算法以組件的形式插入 AppMaster 中。App-Master 根據(jù)平臺(tái)規(guī)模大小等因素動(dòng)態(tài)加載不同的ra，完成資源調(diào)度工作。

    AppRouter 位于應(yīng)用訪問的前端，其內(nèi)部維護(hù)一份全局路由表，負(fù)責(zé)加載 ts，完成對(duì)應(yīng)用訪問請(qǐng)求的路由和轉(zhuǎn)發(fā)，同時(shí)調(diào)整應(yīng)用副本間的負(fù)載均衡。AppRouter 也支持開放式的任務(wù)調(diào)度算法。此外，為了提高應(yīng)用訪問的效率和可靠性，平臺(tái)入口處前置一組反向代理，對(duì)應(yīng)用請(qǐng)求進(jìn)行分發(fā)，即應(yīng)用的訪問請(qǐng)求經(jīng)由網(wǎng)關(guān)，通過反向代理路由至相應(yīng)的處理節(jié)點(diǎn)。AppServer 是包含大量主機(jī)的服務(wù)器集群，用于部署應(yīng)用程序和處理應(yīng)用請(qǐng)求。每臺(tái)主機(jī)上運(yùn)行著一個(gè)節(jié)點(diǎn)代理和若干容器。節(jié)點(diǎn)代理負(fù)責(zé)執(zhí)行來自AppMaster 的指令，并向 AppMaster 報(bào)告主機(jī)和容器的負(fù)載情況以及應(yīng)用運(yùn)行狀態(tài)。容器用于承載部署到平臺(tái)上的應(yīng)用，包含 Java web 服務(wù)器容器和虛擬機(jī)容器 2 類，分別用于運(yùn)行 Java web 應(yīng)用和虛擬機(jī)應(yīng)用。

    3. 2 部署模型

    PaaS 平臺(tái)的部署模型如圖 3 所示。

圖 3 PaaS 平臺(tái)的部署模型

    物理主機(jī)通過交換機(jī)連接，每個(gè)物理主機(jī)承載多個(gè)不同類型的容器，不同類型的容器內(nèi)運(yùn)行相應(yīng)類型的 AI。其中，一部分容器面向應(yīng)用開發(fā)者，運(yùn)行第三方應(yīng)用; 另一部分容器面向平臺(tái)，運(yùn)行平臺(tái)自建應(yīng)用，完成對(duì)平臺(tái)的管理和控制，如資源調(diào)度和任務(wù)調(diào)度等。

    3. 3 關(guān)鍵技術(shù)

    面向互聯(lián)網(wǎng)應(yīng)用 PaaS 平臺(tái)的實(shí)現(xiàn)涉及如下一系列關(guān)鍵技術(shù)。

    3. 3. 1 通用容器

    如圖 4 所示，通用容器( GC) 技術(shù)將包括 Javaweb 服務(wù)器和虛擬機(jī)在內(nèi)的各類應(yīng)用運(yùn)行環(huán)境加以封裝，對(duì)外提供統(tǒng)一的管理和操作接口，以達(dá)到統(tǒng)一承載多種類型應(yīng)用的目的，從而提高 PaaS 平臺(tái)提供應(yīng)用運(yùn)行環(huán)境的靈活性。

圖 4 GC 分層結(jié)構(gòu)

    根據(jù)應(yīng)用種類的不同，GC 可以分為 Java web服務(wù)器容器和虛擬機(jī)容器等，前者用于運(yùn)行 Javaweb 服務(wù)器，部署 Java web 應(yīng)用，其粒度低，針對(duì)性強(qiáng)，但兼容性較低; 后者用于運(yùn)行第三方虛擬機(jī)軟件，向用戶提供虛擬主機(jī)環(huán)境，其通用性強(qiáng)，具備更好的兼容性。根據(jù)應(yīng)用性質(zhì)的不同，GC 還可以分為平臺(tái)自建容器和第三方容器。前者用于運(yùn)行 PaaS 平臺(tái)自身的部分應(yīng)用組件，如能力開放網(wǎng)關(guān)就是作為應(yīng)用運(yùn)行在 GC 當(dāng)中的; 后者用于運(yùn)行應(yīng)用開發(fā)者所開發(fā)的第三方應(yīng)用程序。

    GC 的核心在于對(duì)容器接口的抽象，即不論內(nèi)部包含哪種運(yùn)行環(huán)境，容器總是對(duì)外提供統(tǒng)一的接口。GC 目前支持的管理接口如表 1 所示。

表 1 GC 管理接口列表

    3. 3. 2 資源調(diào)度

    資源調(diào)度技術(shù)是指 PaaS 平臺(tái)能自動(dòng)檢測(cè)應(yīng)用負(fù)載，調(diào)整資源的分配和伸縮，以實(shí)現(xiàn)負(fù)載均衡并提高資源的利用率，從而保障對(duì)應(yīng)用提供透明的高可擴(kuò)展性。具體來說就是主動(dòng)完成 AI 副本的“創(chuàng)建 /激活”和“去激活 /撤銷”，從而保證應(yīng)用處理能力的平滑擴(kuò)展。

    根據(jù)平臺(tái)規(guī)模和應(yīng)用類型等因素的不同，資源調(diào)度算法的側(cè)重點(diǎn)亦有所不同。例如，當(dāng)平臺(tái)規(guī)模較小時(shí)，調(diào)度算法應(yīng)重點(diǎn)關(guān)注資源利用率; 當(dāng)平臺(tái)規(guī)模較大時(shí)，調(diào)度算法則應(yīng)該更加關(guān)注集群的能耗情況等。因此，面向互聯(lián)網(wǎng)應(yīng)用的 PaaS 平臺(tái)支持插件式的開放調(diào)度算法( 見圖 2) ，新的調(diào)度算法可以通過引入新的調(diào)度算法組件來實(shí)現(xiàn)。

    目前，面向互聯(lián)網(wǎng)應(yīng)用的 PaaS 平臺(tái)實(shí)現(xiàn)了一種多粒度的資源調(diào)度方案，即基于主機(jī)粒度判斷集群負(fù)載情況，基于 GC 粒度完成應(yīng)用的動(dòng)態(tài)調(diào)度。該方案劃分為 2 個(gè)階段: 第 1 階段是數(shù)據(jù)準(zhǔn)備階段，完成主機(jī)負(fù)載信息的收集，從而判斷主機(jī)負(fù)載高低; 第 2階段是動(dòng)態(tài)調(diào)度階段，基于負(fù)載信息完成應(yīng)用的動(dòng)態(tài)擴(kuò)容和收縮。具體實(shí)現(xiàn)方案如圖 5 所示。

圖 5 PaaS 平臺(tái)資源調(diào)度

4 結(jié)束語

    基于提出的面向互聯(lián)網(wǎng)應(yīng)用的 PaaS 平臺(tái)體系結(jié)構(gòu)，項(xiàng)目組完成了相應(yīng)的設(shè)計(jì)和實(shí)現(xiàn)工作。PaaS平臺(tái)部署于 4 臺(tái)聯(lián)想 R510 G7 服務(wù)器( CPU: 2 × 4核英特爾�R 至強(qiáng)�R 處理器 E5606; 內(nèi)存: 4 × 4GB R-ECC DDR3-1333) ，AppMaster 等內(nèi)部實(shí)體運(yùn)行在 2臺(tái)服務(wù)器上，同時(shí) 4 臺(tái)服務(wù)器均可作為 AppServer 承載應(yīng)用開發(fā)者的第三方應(yīng)用。PaaS 平臺(tái)的運(yùn)行結(jié)果表明，該平臺(tái)可以成功完成對(duì) Java 應(yīng)用和虛擬機(jī)的托管，切實(shí)提高平臺(tái)的應(yīng)用兼容性。

    此外，項(xiàng)目組還針對(duì) PaaS 平臺(tái)的各項(xiàng)功能做了一系列測(cè)試。這些測(cè)試包括應(yīng)用的高可用性測(cè)試、根據(jù)業(yè)務(wù)量的動(dòng)態(tài)應(yīng)用處理能力進(jìn)行擴(kuò)展測(cè)試等。

    應(yīng)用的高可用性測(cè)試是指當(dāng)應(yīng)用的某個(gè)副本所在服務(wù)器宕機(jī)之后，平臺(tái)是否能正常處理后續(xù)的應(yīng)用訪問請(qǐng)求，并盡快完成應(yīng)用副本的恢復(fù)。測(cè)試結(jié)果表明，由于平臺(tái)支持應(yīng)用的多副本部署，所以當(dāng)某臺(tái)或某些服務(wù)器宕機(jī)之后，平臺(tái)可以繼續(xù)正常處理相關(guān)應(yīng)用的訪問請(qǐng)求，并可以在 30 s( 約 3 個(gè)心跳周期) 內(nèi)完成宕機(jī)服務(wù)器上全部應(yīng)用的副本恢復(fù)。

    應(yīng)用處理能力擴(kuò)展測(cè)試是指平臺(tái)是否能根據(jù)應(yīng)用訪問量動(dòng)態(tài)調(diào)整應(yīng)用副本的數(shù)量，以實(shí)現(xiàn)平臺(tái)資源利用率最大化。測(cè)試結(jié)果表明，應(yīng)用訪問量的持續(xù)激增會(huì)導(dǎo)致服務(wù)器長(zhǎng)時(shí)間負(fù)載過高，平臺(tái)的 RA 可以在 10 s( 約 1 個(gè)心跳周期) 內(nèi)檢測(cè)到訪問量的激增，并在觀察若干心跳周期后完成應(yīng)用副本的擴(kuò)充，擴(kuò)充時(shí)延不超過 15 s( 約 1 個(gè)調(diào)度周期) 。

    通過這一系列測(cè)試可以看出，所提出的 PaaS 平臺(tái)體系結(jié)構(gòu)不但能提供對(duì)應(yīng)用透明的高可用性和高可擴(kuò)展性支持，而且在應(yīng)用兼容性和擴(kuò)充性方面有較大優(yōu)勢(shì)。下一步工作將對(duì)面向互聯(lián)網(wǎng)應(yīng)用的 PaaS平臺(tái)與業(yè)界現(xiàn)有的 PaaS 平臺(tái)進(jìn)行比較，并考察平臺(tái)在不同調(diào)度算法下的性能，以驗(yàn)證和調(diào)整當(dāng)前的互聯(lián)網(wǎng)應(yīng)用 PaaS 平臺(tái)體系結(jié)構(gòu)。

核心關(guān)注：拓步ERP系統(tǒng)平臺(tái)是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。

轉(zhuǎn)載請(qǐng)注明出處：拓步ERP資訊網(wǎng)http://www.oesoe.com/

本文標(biāo)題：互聯(lián)網(wǎng)應(yīng)用PaaS平臺(tái)體系結(jié)構(gòu)

本文網(wǎng)址：http://www.oesoe.com/html/support/1112154268.html