# SongPop 在 GAE 上可擴展至 100 萬活躍用戶，表明 PaaS 未通過 > 原文： [http://highscalability.com/blog/2013/2/25/songpop-scales-to-1-million-active-users-on-gae-showing-paas.html](http://highscalability.com/blog/2013/2/25/songpop-scales-to-1-million-active-users-on-gae-showing-paas.html)  您應該在下一個項目中使用 PaaS 嗎？ 通常，答案是“否”，因為您想要控制，但這是 [SongPop](http://www.songpop.fm/) 中的一個示例，顯示了為什么 PaaS 的承諾沒有通過。 SongPop 能夠自動擴展到 6000 萬用戶，100 萬每日活躍用戶，每天在全球范圍內提供 17 TB 的歌曲和圖像，每秒處理 10k +次查詢，所有這些都由 6 人的工程團隊組成，并且只有一名工程師全職工作 后端。 不幸的是，這里并沒有很多細節，但是可以在[通過 App Engine 和 Google Cloud Storage](http://googleappengine.blogspot.com/2013/02/scaling-songpop-to-60-million-users.html) 將 SongPop 擴展到 6000 萬用戶中找到。 大綱遵循腳本。 你從小開始。 讓 PaaS 做繁重的工作。 而當您需要擴展時，您只需購買更多資源并進行一些調整（也許很多）。 收獲是，您可以專注于功能開發，并且可以與一個小型團隊合作。 這是他們的體系結構圖：  一些經驗教訓： * **首要支持。** 這聽起來有點像銷售推銷，但是一旦他們的每日活躍用戶達到 10 萬，他們就開設了“高級支持”帳戶，從而使他們可以與現實生活中的人交談并快速解決停機問題。 * **使**歸一化。 為了減少就緒延遲，他們將跨多個模型散布的數據收集到一個實體中。 老歌，但仍然是一個巨大的勝利。 * **緩存**。 為了減少查詢，將用戶的反對者列表緩存到 memcache 中，這是 GAE 的功能。 這個和非規范化更改花費了一名工程師 4 天的時間。 * **截止日期**。 一旦操作的性能超過閾值，就該回落到另一個更可預測的策略了。 * **綜合索引**。 查詢速度很慢，其原因可追溯到正在使用的許多索引屬性。 解決方案是使用復合索引或將數據合并到單個實體中。 借助 Premier Support 的幫助可以追溯到此問題，Premier Support 也顯示了 PaaS 的弱點，程序員不應該找到這些問題嗎？ 也許查詢日志很慢？ * **易于與其他服務**集成。 亞馬遜和谷歌等公司的一個優勢是，他們可以創建功能強大的協作服務套件。 由于 SongPop 需要每天在世界范圍內消費和分發 17 TB 的歌曲和圖像，因此他們發現 Google Cloud Storage 價格合理，并且可以從 GAE 輕松使用。 而且，當您想做一些 BigData 時，已經內置了 Google BigQuery。 設計要點。 * **位置標頭**。 GAE 請求會自動包含標頭，這些標頭包含基于客戶端請求的 IP 地址的位置信息。 SongPop 使用此信息選擇對手并建立個人資料。 * **同步模擬游戲。** Song Pop 使用的一種有意義的策略是[同步模擬游戲](http://uncrunched.com/2012/06/22/980/)。 可擴展的，一致的，低延遲的游戲很難，那么為什么要那么做呢？ SongPop 所做的是錄制游戲，然后在您玩游戲時與您對戰。 您似乎是在和一個真實的人比賽，但是沒有一個討厭的工程挑戰。 您只需要存儲聲音片段和游戲結果，將玩家匹配到游戲，然后答復游戲即可。 相當聰明。 顯然，這是您的標準 Facebook 風格游戲，因此它不是復雜的應用程序，但將其包含在體系結構決策矩陣中是一個很好的存在證明。 ## 相關架構 * [通過 App Engine 和 Google Cloud Storage 將 SongPop 擴展到 6000 萬用戶](http://googleappengine.blogspot.com/2013/02/scaling-songpop-to-60-million-users.html) * [Song Pop 每天吸引 200 萬活躍用戶，其中許多人可能在調情](http://techcrunch.com/2012/07/03/song-pop/)