PaaS正能量：6人團隊僅1人全職后端 支撐6000萬用戶
相信有很多人對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的架構圖解：
#p#
單一的看架構圖，顯然不能知曉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平臺發展的愈加成熟，各個服務的缺點會得到進一步改善，優點則會更加的突出。而經過用戶與服務供應商之間的共同努力，從中獲益的模式以及途徑將變的更加清晰。
