淺析App Engine

摘要：

在國內外，雲計算正在大步的走向商業化的道路，也得到了越來越多公司的重視。其中平臺即服務(Platform-as-a-Service PaaS)已經稱爲業界探討雲計算的熱點方式之一，採用PaaS模式來構建應用運行平臺App Engine是一種重要的實現方式。本文主要是對App Engine的背景、特點、需求等進行分析整理，並據此對業界主要的App Engine進行了調研分析。最後對一個完善的App Engine進行了需求的細化分解、架構設計，並針對App Engine的部分核心技術問題提出瞭解決方案。

關鍵字：App Engine、PaaS、SAE、Nginx、scribe、Hadoop、Storm、Ptail、Scribe

1綜述

1.1背景

在國內外，雲計算正在大步的走向商業化的道路，也得到了越來越多公司的重視。其中平臺即服務(Platform-as-a-Service PaaS)已經稱爲業界探討雲計算的熱點方式之一，採用PaaS模式來構建應用運行平臺App Engine是一種重要的實現方式，比如說國外的Google App Engine、國內的Baidu App Engine/Sina App Engine/Tencent App Engine。

雲計算(Cloud Computing)是當前IT領域的熱點，是繼1980年大型計算機到客戶端-服務器的大轉變之後的又一種鉅變。雲計算的一個重要目標是“通過互聯網，使用戶更加方便、快捷、靈活地使用各種有質量保障的 IT 資源，這些資源以服務形式提供，終極的雲計算環境將使得消費這些服務就像今天使用水、電和煤氣等公共基礎設施一樣便捷”。通常來說雲計算可以認爲包含以下三個層次的服務：

SaaS(Software-as-a-Service)：軟件即服務。它是一種通過Internet提供軟件的模式，用戶無需購買軟件，而是向提供商租用基於Web的軟件，來管理企業經營活動。
PaaS(Platform-as-a-Service)：平臺即服務。PaaS實際上是指將軟件研發的平臺作爲一種服務，以SaaS的模式提交給用戶。因此，PaaS也是SaaS模式的一種應用。但是，PaaS的出現可以加快SaaS的發展，尤其是加快SaaS應用的開發速度。
Iaas(Infrastructure-as-a-Service)：基礎設施即服務。提供給消費者的服務是對所有設施的利用，包括處理、存儲、網絡和其它基本的計算資源，用戶能夠部署和運行任意軟件，包括操作系統和應用程序。消費者不管理或控制任何雲計算基礎設施，但能控制操作系統的選擇、儲存空間、部署的應用，也有可能獲得有限制的網絡組件(例如，防火牆，負載均衡器等)的控制。

雲計算三個層次的服務關係如下圖所示：

其中可以看出PaaS是承接Iaas和SaaS的關鍵點，是對底層IaaS的再次封裝從而提供完善的運行平臺來支撐不同的SaaS應用。PaaS的一種重要實現形式就是App Engine，本文分析的對象就是App Engine。

1.2 App Engine特點

App Engine具有PaaS平臺的三個特點:

平臺即服務：PaaS所提供的服務與其他的服務最根本的區別是PaaS提供的是一個基礎平臺，而不是某種應用。PaaS爲不同的業務應用提供全流程的運行環境支持，對具體的業務應用而言，PaaS就是一個服務，一個爲應用開發提供支持的平臺服務。

平臺及服務：一個App應用所需提供的服務，不僅僅是單純的基礎平臺，而且包括針對該平臺的技術支持服務，甚至針對該平臺而進行的應用系統開發、優化等服務。所以一個完善的PaaS運行平臺，不僅僅只能是運行環境，還需要提供各種相關服務，比如說完善的平臺控***務、自動化運維服務、彈性調度服務等等。

平臺級服務：PaaS運營商對外提供的服務不同於其他的服務，這種服務的背後是強大而穩定的基礎運營平臺，以及專業的技術支持隊伍。這種“平臺級”服務能夠保證支撐SaaS或其他軟件服務提供商各種應用系統長時間、穩定的運行。PaaS的實質是將互聯網的資源服務化爲可編程接口，爲第三方開發者提供有商業價值的資源和服務平臺。有了PaaS平臺的支撐，雲計算的開發者就獲得了大量的可編程元素，這些可編程元素有具體的業務邏輯，這就爲開發帶來了極大的方便，不但提高了開發效率，還節約了開發成本。有了PaaS平臺的支持，WEB應用的開發變得更加敏捷，能夠快速響應用戶需求的開發能力，也爲最終用戶帶來了實實在在的利益。

1.3 App Engine需求

App Engine將應用運行所需的 IT 資源和基礎設施以服務的方式提供給用戶，包括了中間件服務、資源管理服務、彈性調度服務、消息服務等多種服務形式。App Engine的目標是對應用提供完整生命週期(包括設計、開發、測試和部署等階段)的支持，從而減少了用戶在購置和管理應用生命週期內所必須的軟硬件以及部署應用和IT 基礎設施的成本，同時簡化了以上工作的複雜度。爲了確保高效地交付具備較強靈活性的平臺服務，在App Engine中，平臺服務通常基於自動化的技術通過虛擬化的形式交付，在運行時，自動化，自優化等技術也將被廣泛應用，以確保實時動態地滿足應用生命週期內的各種功能和非功能需求。

具體來說，搭建傳統 IT 基礎平臺是一個漫長的過程，通常由申請，審計，硬件購買與運輸，硬件安裝與配置，軟件安裝與配置等步驟組成。在這個過程中繁複的手工配置工作費時費力，而且容易產成人爲配置錯誤。同時，平臺環境的升級維護也面臨人爲配置錯誤頻繁產生問題，造成不必要的影響和損失。由於這些原因，搭建完成的應用運行平臺，即使在一定時期內不再需要，也不會被及時釋放回收，以供新項目使用。這是造成空閒硬件資源的原因之一。此外，傳統基礎平臺提供的應用運行能力是靜態的。然而在不同時間，應用負載往往是不一樣的。爲了確保高負載時應用的正常運行，應用運行平臺必須能夠提供最高運行能力，這就造成了非高峯時的衆多空閒硬件資源。

雲計算的產生，尤其是平臺服務App Engine的理念，從產生空閒硬件資源的根本原因入手建立了快速搭建部署應用運行環境和動態調整應用運行時環境資源這兩個目標。依據虛擬化與自動化技術實現應用運行環境的即時部署以及快速回收，降低了環境搭建時間，避免了手工配置錯誤，快速重複搭建環境，及時回收資源，減少了低利用率硬件資源的空置。另一方面，根據應用運行時的需求對應用環境進行動態調整，實現了應用平臺的彈性擴展和自優化，減少了非高峯時硬件資源的空置。

簡而言之，App Engine主要目標是：Easy to maintain, Easy to scale, Easy to build。

具體來說，需求可以從三個維護來分解：

第一、開發需求。從開發的角度來看，App Engine需要提供全流程的運行環境和全流程的開發環境。其中全流程的運行環境包含流量接入服務、運行環境、通用服務。全流程的開發環境包含：開發支持SDK、基礎框架基礎庫、代碼自動生產腳手架、單機運行環境。

第二、運維需求。運維是App Engine最重要的目標之一，運行資源彈性調度、資源審計、預算、資源利用率、安全隔離、訪問控制、實時監控等等都是重要的需求。

第三、產品支持需求。這裏面需要對開發、運維、產品提供全流程的管理支持工作，包含有開發上支持需求：業務監控、問題定位、分佈式日誌重建。運維上的報警、預算分析、自動調度。產品上的需求：統計分析、離線數據挖掘、在線實時計算。

2調研

主要調研分析了兩個比較典型的App Engine：最近開源的CloudFoundry和國內最近比較火的Sae平臺。

2.1 CloudFoundry

CloudFoundry是VMware公司在2011年4月份推出的開源PaaS平臺，官方網站是http://cloudfoundry.com/。在這過去的一年發展中，CloudFoundry發展非常迅速，目前已經支持PHP/JAVA/Ruby等各種運行環境，並且很好的和各種開源框架、服務進行對接。

CloudFoundry的整體架構如下圖所示：

其中各個模塊的工作如下：

1、 Request Router。顧名思義，是一個Router層，主要的工作是流量接入並進入路由分發請求到不同的App 執行環境中去。在CloudFoundry的具體實現中，Request Router是通過Nginx來實現的。

2、 App Exec Engine。同樣通過字面上的意義可以瞭解到這就是CloudFoundry的App執行引擎。不同語言的執行環境都是在這裏實現的，如何做到不同語言的執行環境同構化，CloudFoundry的實現方案很簡單：直接對異構運行環境進行封裝成一個tar包，並提供一個統一的start腳本來負責啓動對應的服務。目前關於隔離性、虛擬化方面暫無詳細支持計劃。

3、 Services。通用服務，對通用服務的調用進行了簡單的封裝，並提供了服務加入流程化支持。Cloud Foundry的Service模塊從源代碼控制上看就知道是一個獨立的、可Plugin的模塊，以方便第三方把自己的服務整合入 CloudFoundry生態系統。在Github上看到service是與CloudFoundry Core項目vcap獨立的一個repository，爲vcap-service。Service模塊其中設計原則是方便第三方服務提供商提供服務。在這方面CloudFoundry做得很成功，從Github上看，已經有以下服務提供：a)MongoDB; b) mysql; c) neo4j; d) PostgreSql; e) RabbitMQ; f) Redis; g)vBlob。基類都是放在base文件夾中。第三方如果需要自己開發CloudFoundry的服務，需要繼承改寫它裏面的兩個基礎類：Node和Gateway；而裏面一些操作，如：Provision，可以在base的provisioner.rb基礎上加入自己的邏輯，同樣的還有Service_Error和 Service_Message等

4、 Clond Controller。平臺控制器。Clond Controller是CloudFoundry的控制管理中心，目前的主要功能有：對app的增刪改讀、服務的停止啓動、app的部署、通用服務的部署管理。同時實現了一些簡單彈性調度策略，比如說通過HealthManager來獲取app應用的性能數據和健康數據，從而進行一些app實例的增加刪除操作。

5、 HealthManager。監控狀態管理中心。目前做的事情不復雜，簡單的說是從各個App Exec Engine裏面拿到運行信息，然後進行統計分析，報告等。統計數據會與Cloud Controller的設定指標進行比對，並進行相應的操作處理。HealthManager模塊目前還不是十分完善，但是在CloudManage裏面，自動化健康管理、分析是一個很重要的領域，而這方面可以擴展的地方也很多，結合OrchestrationEngine可以使雲自管理、自預警；而與BI方面技術結合，可以統計運營情況，合理分配資源等。

整體來說，CloudFoundry提供了比較完善運行環境支持，包含流量接入、app運行和通用服務，並實現了一定的平臺控制和業務支持功能，比如說彈性自動擴容。但目前在資源管理、虛擬化、資源控制、產品支持方面還有很多工作來做。同時對於app運行環境之間的隔離性、安全控制也缺少考慮。

2.2 SAE

SAE是國內目前相對比較成熟的App Engine平臺，從09年到現在已經爲超過15W+的app應用提供服務。SAE主推PHP開發環境，目前也支持JAVA、Python，主要是公有云集羣平臺，同時也針對部分VIP客戶提供了差異化的服務。

SAE的設計理念是：1、無狀態對等節點，方便擴展。2、無單點。目前整體架構完整情況未知，從公開的資料來看，SAE在運行環境上的架構如下圖：

主要特點是：

1、動態DNS。Isp和四層之間的工作。

2、 App Router。主要功能是反向代理、應用功能和權限配置、域名服務。是基於Nginx實現的。

3、 Runtime。實現沙箱(代碼隔離、訪問控制、分鐘配額控制)、應用配置(appconfig)、本地IO(安全考慮不允許本地文件操作)等等。目前是應用級別的隔離。

4、通用服務方面，目前已經支持非常多種通用服務，並且屏蔽了分佈式實現細節，比如說mysql、kvdb、memcache、fetchurl等等。

5、應用代碼管理。目前支持在線編輯、代碼採用svn來進行發佈來提交，同時提供code deployer來實現代碼的自動化發佈。

在平臺支持方面，目前SAE提供了統計和報表分析功能，也有部分資源審計、日誌查看方面的產出，據說架構如下：

3實踐

從前面的描述，基本上介紹了App Engine的背景、特點和需求，也對當前一些主流的App Engine進行了調研，本章節主要關注如何能夠搭建好一個完整的App Engine平臺。本章節首先會明確細化分析App Engine的需求，然後給出平臺的整體架構和方案，最後描述如何使用業界開源技術來搭建完成這個App Engine平臺。

3.1需求

App Engine的最基本需求是能夠給不同的應用提供全方面的服務，細分來說，App Engine平臺的整體需求如下圖：

具體描述如下：

1、 流量接入。流量接入層最重要的三個功能是防***、流量接入、業務分流。此外還需要考慮內部隔離性等方面的需求。

2、 應用運行層。應用運行層是整個業務能夠跑起來最重要也最關鍵的部分，包含運行基礎環境、安全隔離、應用防***、資源管理、集羣劃分、授權管理。

3、 通用服務。通用服務主要是爲App Engine提供各種基礎服務，從而方便不同的應用來使用。此外還需要其他通用服務提供完成的服務接入流程和方案。

4、 平臺控制。平臺控制中心，是整個在線運行平臺的中控中心。通過自動、手動想結合的方式把整個在線運行平臺的各個系統協調控制起來，從而實現整個平臺的正常運行。總體來說，平臺控制器中心的功能會分爲：業務調度、集羣管理、資源審計、命令總控、代碼管理、代碼發佈等等。

5、 日誌服務。日誌服務的主要作用是收集平臺上應用和運行環境相關的數據，併爲下游應用提供相應的數據訪問接口。主要包括兩個方面的工作：日誌收集、日誌處理。

6、 業務支持。由於所有的業務應用都統一運維，實現分佈式部署、動態調度，因此一些可以在具體機器上實現的功能需求，需要通過其他手段來實現相應的分佈式版本。比如說APP應用日誌查看、問題定位、監控、統計。

7、 平臺管理。平臺管理主要是方便平臺管理員來控制管理整個平臺，並提供友好可用的界面。主要功能包括：平臺監控、平臺管理和業務管理三大塊。

8、 開發支持。主要是對業務開發人員提供一系列的支持，方便業務開發人員使用ORP平臺，並更好的管理好自己的業務。主要包括：業務管理平臺、文檔中心、反饋跟蹤平臺、相關SDK和工具。

3.2 整體架構

針對上述需求，整體架構如下圖：

其中各個模塊的作用如下：

1、 App Router。對應流量接入層，主要工作是接收用戶請求，並轉發到不同的App Runtime。

2、 App Runtime。對應應用運行環境，爲各個應用提供基本的運行引擎，從而讓app能夠運行起來。

3、 Code Center。對應代碼中心，主要作用是完成代碼存儲、部署上線相關的工作。

4、 Services。對應各個通用服務，主要是對主流的服務提供通用的接入。

5、 Log Center。主要是實時收集相關係統的日誌，並提供實時計算和分析平臺，從而爲Platform Control和Platform Support提供最基礎的支持。

6、 Platform Control。平臺控制層，主要作用是實現彈性擴容、資源審計、集羣管理等相關工作。

7、 Platform Support。平臺支持層，主要爲app應用提供相關的支持，比如說app應用監控、問題定位、分佈式日誌重建、統計分析等基本功能。

3.3具體實現

3.3.1 App Router的實現

App Router的主要作用是流量接入 + 業務分流，從技術角度來看要滿足幾個點：高性能 + 完善的反向代理功能 + 足夠的擴展性。據此，Nginx是一個不錯的選擇，Nginx有足夠強勁的性能，並且在Http Proxy方面有着非常完善的支持，同時在防***、擴展開發方面也有着非常多的優勢。此外，Nginx還能夠非常方便的支持多域名多服務。具體可以參考http://blog.xiuwz.com/2011/12/08/nginx-internals/。