相信有很多人對PaaS持謹(jǐn)慎態(tài)度，到底是用還是不用?而在前一階段“ 用戶指責(zé)Heroku私自修改路由機(jī)制造成高支出”這場風(fēng)暴過境后，PaaS似乎變的更加讓人望而卻步了。然則PaaS真像這些負(fù)面所說，高投入之后卻帶不來應(yīng)有的回報?下面就看一看那些來自PaaS的正能量，本文將以一個重點(diǎn)做陳述，下面來一覽High Scalability上總結(jié)的 小團(tuán)隊(duì)PaaS成功之旅：

SongPop

SongPop，音樂版你畫我猜游戲;于2012年5月上線，現(xiàn)已擁有6000萬個用戶，位列2012年iOS游戲下載榜第5。而今SongPop已有能力處理日百萬活躍用戶的線上活動，然而問題的關(guān)鍵卻在于SongPop的工程師團(tuán)隊(duì)只有6人!其中也僅有一個人在做全職的后端工作。SongPop只花了不到6個月就實(shí)現(xiàn)了從0到1萬每秒查詢的擴(kuò)展，他們把大部分的功勞歸結(jié)于所使用的PaaS平臺 —— Goolge App Engine。

經(jīng)驗(yàn)總結(jié)如下：只做輕活，讓PaaS去承擔(dān)重的部分;當(dāng)你需要擴(kuò)展時，你只需要購買更多的資源和做少量的調(diào)整(當(dāng)然，也可能會很多);得到的回報是可以專心于App的特色開發(fā)，并且能夠以很小的團(tuán)隊(duì)開始。

SongPop的架構(gòu)圖解：

#p#

單一的看架構(gòu)圖，顯然不能知曉SongPop以6人工作團(tuán)隊(duì)去支撐每天百萬活躍用戶的關(guān)鍵。下面來看一下SongPop問題解決策略：

學(xué)到的知識

Premier Support(企業(yè)技術(shù)支持服務(wù))。看起來很像是推銷員的宣傳曲調(diào)?然而一旦活躍用戶達(dá)到了10萬，它們就會開啟一個Premier Support賬戶，這讓他們可以與一個在線工程師進(jìn)行洽談，解決宕機(jī)問題。

Denormalize(反規(guī)范化)。為了降低可預(yù)見的延遲，它們將幾個模型中的數(shù)據(jù)匯集到一個實(shí)體中。一個很老的方法，但是卻很實(shí)用。

Cache(緩存)。為了減少用戶對游戲?qū)κ至斜淼牟樵?，列表會被儲存到緩存中，這同樣是GAE的特性之一。這個以及反規(guī)范化操作將花費(fèi)一個工程師4天左右的時間。

Deadlines(截止時間)。一旦某個操作的性能衰退到一個臨界，是時候轉(zhuǎn)換到一個更可預(yù)知的策略。

復(fù)合索引。查詢變的緩慢，其原因歸結(jié)于大部分索引性能被占用。解決方案就是使用組合索引或者把數(shù)據(jù)整合到一個實(shí)體中，這個問題的發(fā)現(xiàn)來自Premier Support的幫助，同樣這也是PaaS的弱點(diǎn)之一。

輕易實(shí)現(xiàn)與其它服務(wù)的整合。類似Google和Amazon這樣的公司都有一個相同的優(yōu)勢，它們一般會建立一整套的協(xié)作服務(wù)。鑒于SongPop每天需要世界范圍類的處理和分配17TB的音樂和圖片，Google Cloud Storage顯然很適合他們，并且易于在GAE中使用。對于大數(shù)據(jù)技術(shù)，Google BigQuery更是隨時就緒。這也是設(shè)計中重要的一點(diǎn)。

位置頭文件。GAE請求自動的包含了基于客戶端請求IP的位置信息，SongPop使用了這個信息去為玩家匹配對手，并構(gòu)建配置文件。

Synchronous Simulated Gameplay。SongPop使用的一個創(chuàng)新策略就是Synchronous Simulated Gameplay。在游戲中保障可擴(kuò)展、一致性、低延遲是相當(dāng)不容易的，那么SongPop是如何做到的呢?SongPop的做法是將游戲記錄，然后與你對戰(zhàn)(就像你和其它人做的一樣)。你將得到一種與玩家對戰(zhàn)的游戲體驗(yàn)，但是這樣工程師就避免了很多技術(shù)挑戰(zhàn)。只需要儲存聲音片段和游戲結(jié)果，匹配玩家進(jìn)行游戲，然后做出響應(yīng)。確實(shí)很聰明。(更多詳請移足 “SongPop如何使用Google App Engine和Google Cloud Storage發(fā)展到6000萬用戶”)

通過以上幾個關(guān)鍵點(diǎn)，SongPop成功的實(shí)現(xiàn)了以6人工程師團(tuán)隊(duì)處理每日百萬的在線用戶。然而從Google App Engine這個PaaS服務(wù)獲益絕不是SongPop一個，還有Rovio等：

幾個從GAE獲益的公司：

1. Ravio—— “憤怒小鳥”的擁有者。使用App Engine僅花費(fèi)2周的工作就推出了游戲的網(wǎng)頁版，使他們能夠利用機(jī)會快速發(fā)展它們的業(yè)務(wù)。

2. GetAround—— TechCrunch Disrupt出品的汽車租賃服務(wù)，使用App Engine建立了一個連接汽車業(yè)主的市場，用戶可以從中租借汽車。幾乎無額外工作就完成了他們產(chǎn)品的擴(kuò)展。

3. MAG Interactive—— 休閑游戲的開發(fā)者，熱門游戲Ruzzle的創(chuàng)建者;通過App Engine對后端進(jìn)行擴(kuò)展，迅速的發(fā)展到500萬用戶，期間更“老練”的未發(fā)生任何擴(kuò)展問題。

4. Nubbius—— Cloud Gate使用App Engine建立，允許律師在任何地點(diǎn)管理其工作流程的SaaS平臺。在快速部署擴(kuò)展的同時，每年成本節(jié)約更超過13萬美元。

5. RedBus，在線旅行社使用Google BigQuery調(diào)度上萬汽車的日程表。不到30秒就可以分析2TB的數(shù)據(jù)(在Hadoop上需要大約一天的時間)，成本卻不到Hadoop基礎(chǔ)設(shè)施的20%。

總結(jié)

以上闡述的是一些從Google App Engine中獲益的用例，然而從Google App Engine中獲利的公司絕不止以上幾個;同樣可以獲益的PaaS平臺也絕不是Google一家所有，比如：Netflix大愛的Amazon，受廣大微軟用戶擁護(hù)的Azure，以及廣受Rails用戶喜歡、雖然前一階段卻遭受質(zhì)疑的Heroku。

由此可見，***的服務(wù)是不存在的(畢竟還存在宕機(jī)、安全這些難以攻克的問題)，選擇匹配自己業(yè)務(wù)類型(數(shù)據(jù)類型及程序原型等)的服務(wù)才是根本。同樣，隨著PaaS平臺發(fā)展的愈加成熟，各個服務(wù)的缺點(diǎn)會得到進(jìn)一步改善，優(yōu)點(diǎn)則會更加的突出。而經(jīng)過用戶與服務(wù)供應(yīng)商之間的共同努力，從中獲益的模式以及途徑將變的更加清晰。