PaaS正能量：6人團隊，僅1人全職後端 支撐6000萬用

6人團隊，僅1人全職後端，可以支撐起日百萬活躍用戶的線上活動？SongPop用事實告訴我們，利用好PaaS這是完全可行的！而從PaaS上獲益的絕不是SongPop他們一個，近日Google博客上貼出了一些GAE的用例，其中包括：“Angry Birds”的擁有者Ravio，Ruzzle擁有者MAG Interactive等。

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

SongPop

SongPop，音樂版你畫我猜 游戲；於2012年5月上線，現已擁有6000萬個用戶，位列2012年iOS游戲下載榜第5。而今SongPop已有能力處理日百萬活躍用戶的線上活 動，然而問題的關鍵卻在於SongPop的工程師團隊只有6人！其中也僅有一個人在做全職的後端工作。SongPop只花了不到6個月就實現了從0到1萬 每秒查詢的擴展，他們把大部分的功勞歸結於所使用的PaaS平台 —— Goolge App Engine。

經驗總結如下：只做輕活，讓PaaS去承擔重的部分；當你需要擴展時，你只需要購買更多的資源和做少量的調整（當然，也可能會很多）；得到的回報是可以專心於App的特色開發，並且能夠以很小的團隊開始。

SongPop的架構圖解：

單一的看架構圖，顯然不能知曉SongPop以6人工作團隊去支撐每天百萬活躍用戶的關鍵。下面來看一下SongPop問題解決策略：

學到的知識

• Premier Support（企業技術支持服務）。看起來很像是推銷員的宣傳曲調？然而一旦活躍用戶達到了10萬，它們就會開啟一個Premier Support賬戶，這讓他們可以與一個在線工程師進行洽談，解決宕機問題。
• Denormalize（反規范化）。為了降低可預見的延遲，它們將幾個模型中的數據匯集到一個實體中。一個很老的方法，但是卻很實用。
• Cache（緩存）。為了減少用戶對游戲對手列表的查詢，列表會被儲存到緩存中，這同樣是GAE的特性之一。這個以及反規范化操作將花費一個工程師4天左右的時間。
• Deadlines（截止時間）。一旦某個操作的性能衰退到一個臨界，是時候轉換到一個更可預知的策略。
• 復合索引。查詢變的緩慢，其原因歸結於大部分索引性能被占用。解決方案就是使用組合索引或者把數據整合到一個實體中，這個問題的發現來自Premier Support的幫助，同樣這也是PaaS的弱點之一。
• 輕易實現與其它服務的整合。類似Google和Amazon這樣的公司都有一個相同的優勢，它們一般會建立一整套的協作服務。鑒於SongPop每天需要世界范圍類的處理和分配17TB的音樂和圖片，Google Cloud Storage顯然很適合他們，並且易於在GAE中使用。對於大數據技術，Google BigQuery更是隨時就緒。這也是設計中重要的一點。
• 位置頭文件。GAE請求自動的包含了基於客戶端請求IP的位置信息，SongPop使用了這個信息去為玩家匹配對手，並構建配置文件。
• Synchronous Simulated Gameplay。SongPop使用的一個創新策略就是Synchronous Simulated Gameplay。在游戲中保障可擴展、一致性、低延遲是相當不容易的，那麼SongPop是如何做到的呢？SongPop的做法是將游戲記錄，然後與你 對戰（就像你和其它人做的一樣）。你將得到一種與玩家對戰的游戲體驗，但是這樣工程師就避免了很多技術挑戰。只需要儲存聲音片段和游戲結果，匹配玩家進行 游戲，然後做出響應。確實很聰明。（更多詳請移足 “SongPop如何使用Google App Engine和Google Cloud Storage發展到6000萬用戶”）

通過以上幾個關鍵點，SongPop成功的實現了以6人工程師團隊處理每日百萬的在線用戶。然而從Google App Engine這個PaaS服務獲益絕不是SongPop一個，還有Rovio等：

幾個從GAE獲益的公司：

1. Ravio—— “憤怒小鳥”的擁有者。使用App Engine僅花費2周的工作就推出了游戲的網頁版，使他們能夠利用機會快速發展它們的業務。

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

3. MAG Interactive—— 休閒游戲的開發者，熱門游戲Ruzzle的創建者；通過App Engine對後端進行擴展，迅速的發展到500萬用戶，期間更“老練”的未發生任何擴展問題。

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

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

總結

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

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