# Playfish 的社交游戲架構-每月有 5000 萬用戶并且不斷增長 > 原文： [http://highscalability.com/blog/2010/9/21/playfishs-social-gaming-architecture-50-million-monthly-user.html](http://highscalability.com/blog/2010/9/21/playfishs-social-gaming-architecture-50-million-monthly-user.html) 每天有 1000 萬玩家，每月超過 5000 萬玩家使用 Facebook，MySpace 和 iPhone 等社交平臺上的 [Playfish](http://playfish.com) 游戲與朋友進行社交互動。 Playfish 是游戲行業發展最快的細分市場中的早期創新者：[社交游戲](http://radoff.com/blog/2010/05/24/history-social-games/)，這是休閑游戲和社交網絡之間的摯愛。 Playfish 還是 Amazon 云的早期采用者，其系統完全在 100 臺云服務器上運行。 Playfish 發現自己處于某些熱門趨勢（可能是 EA 為什么以 [3 億美元](http://mashable.com/2009/11/09/ea-acquires-playfish-2/)買下它們，并認為 [10 億美元游戲](http://venturebeat.com/2010/04/20/ea-playfish-president-the-billion-dollar-social-game-is-achievable/)成為可能）的趨勢：在社交網絡上構建游戲， 在云中構建應用程序，移動游戲，利用數據驅動的設計來不斷發展和改進系統，敏捷開發和部署，以及將[出售為商業模型。](http://blogs.forbes.com/velocity/2010/02/23/eas-playfish-big-real-world-sales-in-virtual-goods-game/) 一家小公司如何實現所有這些目標？ 為了解釋這種魔術，我采訪了 Playfish 的工程高級總監 Jodi Moran 和 Playfish 的首席建筑師，第一任工程師兼運營總監 Martin Frost。 很多好東西，讓我們繼續講究細節。  網站： [playfish.com](http://playfish.com/) ## 統計資料 1. 每月 5000 萬活躍用戶 2. 每天有 1000 萬活躍用戶 3. 100 臺服務器計算機 4. 10 款游戲，一直在發布 5. 已下載，安裝和播放了 2 億個游戲 6. 服務器與操作人員的比例為 100：1 7. 4 間工作室中的約 200 名員工和 250 名承包商  ## 平臺 1. 客戶端上的 Flash 2. 服務器端的 Java 3. 一些 PHP 工具 4. 亞馬遜：EC2，CloudFront，S3，Hadoop /彈性地圖簡化，Hive，一些 SQS，一些 SimpleDB 5. HAProxy 用于負載平衡 6. MySQL 用于分片，blob 存儲 7. 碼頭應用服務器 8. [YAMI4](http://www.inspirel.com/yami4/) 用于服務傳輸。 提供點對點連接，低延遲。 ## 關鍵力量 塑造 Playfish 體系結構的主要力量是什么？ 1. **游戲是免費（F2P）**。 Playfish 游戲是免費的：它們不需要花錢就可以玩，但仍然需要花錢來運行。 這種模型的結果是不可能簡單地將硬件扔到問題上。 成本必須得到控制，因此它們試圖精益高效地運行。 與其他游戲機型一起，每月訂閱可補貼硬件和產品投資。 [MMO](http://en.wikipedia.org/wiki/Massively_multiplayer_online_game) （大型多人在線游戲），例如，每臺服務器可運行數百或數千個用戶。 Playfish 的目標是在此數量級以上。 MMO 可提供服務器密集型游戲體驗，但它們唯一的方法是每月收取 10 至 50 美元的訂閱費，這是一個完全不同的空間。 2. **游戲是社交游戲**。 Playfish 專注于社交游戲，這意味著您與朋友互動和互動。 實際上，您只能和真正的朋友一起玩，也可以和您的社交游戲一起玩。 游戲并不是真正贏球。 結果是按分數和水平排序的，但是人們會發揮更多的作用來表達自己并炫耀其設計技巧。 這是另一種游戲類型。 例如，在[餐廳城市](http://www.youtube.com/watch?v=a8AyQ7xBAZ0)中，目標不是成為最富有或最好的餐廳，而是擁有最具創意和表現力的餐廳。 較新的游戲甚至不再使用全球排行榜。 較早的游戲使用全球排行榜，每個人都與其他人競爭。 游戲的結構傳統上更具挑戰性，并且“看我的得分比你的得分還要大”。 現在他們有了一個排行榜，但它只是在您和您的朋友之間。 現在更親密了。 人們不在乎是否比其他國家的人更好，而在乎是否比朋友的人更好。 3. **游戲是異步**。 異步游戲是玩家可以在不同時間玩的游戲。 由于您的朋友很少同時在線，因此社交游戲是異步進行的。 你們不必都同時玩。 例如，在類似 MMO 的《魔獸世界》中，玩家同時存在于同一空間中并且可以同時行動，這使得他們對延遲非常敏感并且難以擴展。 Playfish 的游戲有所不同，它們是異步播放的單人或多人游戲。 玩家不會同時出現在同一個游戲空間中，而是在其本地客戶端中玩。 與朋友一起玩耍時，您不會受到朋友的阻攔，可以自己進步。 該模型導致各種專業設計的可能性。 異步游戲的例子是熟悉的游戲，如 Scrabble 或 Texas Hold'em，玩家輪流玩。 更具創新性的游戲是 Playfish 的“最大大腦”游戲，該游戲中的朋友不斷嘗試證明誰更聰明，它使用排行榜顯示您的朋友及其分數的圖片，因此您始終可以看到誰在領先。 這是異步的，因為每個玩家都獨立游戲，但排行榜允許所有玩家檢查彼此的進度。 4. **游戲是休閑游戲**。 異步游戲可以是硬核策略游戲，例如 1950 年代的[外交棋盤游戲](http://en.wikipedia.org/wiki/Diplomacy_(game))。 [社交游戲](http://radoff.com/blog/2010/05/24/history-social-games/)往往是[休閑游戲](http://en.wikipedia.org/wiki/Casual_game)，它們確實很容易玩，只要在短時間內從任何位置單擊幾下鼠標，就可以玩。 Playfish 通過高產值 3D 圖形，易于控制，自定義角色和多人游戲挑戰擴展了該模型，從而帶來了很高的[用戶參與度](http://www.workatplay.com/think/what-user-engagement-anyway-part-1)。 5. **規模受限于各個社交網絡**的規模。 與社交意味著[難以擴展](http://highscalability.com/blog/2009/10/13/why-are-facebook-digg-and-twitter-so-hard-to-scale.html)的其他應用領域相反，對于 Playfish 社交來說，這不僅是一個擴展問題，還是一個擴展解決方案。 Playfish 游戲并不具有全球意義，因為有一百萬人不會嘗試同時玩同一游戲。 Playfish 游戲是社交性的。 他們與您的朋友一起玩的樂趣更多，而不是艱難和骯臟的比賽。 這樣的結果是，個別游戲固有地可擴展，因為它們只涉及很少的玩家。 以一個擁有 5000 萬用戶的全球排行榜為例。 在單個數據結構上需要大量寫入，并且可能需要分片以使其擴展。 由幾個參與者組成的社交網絡的排行榜更容易實現。 6. **大量用戶**。 積極玩游戲的用戶數量眾多，這給他們的體系結構帶來了壓力，要求它們擴展為整個系統。 每個單獨的游戲可能都相對容易擴展，但是對于這么多的活動游戲來說，完整的系統并不是那么容易擴展。 7. **快速增長**。 通過設計，這些游戲具有病毒性，因為它們利用了社交圖譜。 它們也很有趣，易于玩耍并有助于維持朋友之間的關系。 所有這些因素都促進了社交游戲的快速發展，這意味著 Playfish 不僅需要應對大量用戶，還必須應對持續不斷的新用戶。 8. **快速更改**。 游戲市場發展迅速，競爭激烈。 這也是一個非常新的領域，每個人仍在學習什么有效，哪些無效，流失很多。 Playfish 不能等待漫長的采購流程，漫長的設計周期或漫長的發布周期。 他們必須保持敏捷。 9. **游戲的熱門驅動性質**。 很難預測哪些游戲會成功，因此當一款游戲成功起飛時，它必須能夠立即擴展。 游戲盛行時，沒有時間利用新資源。 為每個游戲的最大預期增長分配資源根本行不通。 他們的游戲太多了，這將需要大量的服務器，而這些服務器很可能將不使用。 10. **實驗性游戲發布**。 游戲可以看作是針對利基市場的實驗。 有些實驗會比其他實驗更成功。 這回到了社交游戲行業非常敏捷的本質。 11. **多個游戲**。 Playfish 不是一家單一產品公司。 其他公司僅支持一個游戲。 Playfish 必須同時支持和開發多個游戲，并且新游戲總是按計劃進行。 這給開發和運營帶來很大壓力。 12. **智能客戶端**。 Playfish 游戲是用 Flash 編寫的，這是一個非常強大的富客戶端。 它可以智能地緩存數據，支持本地操作并消除大量服務器負載。 13. **游戲是應用程序，而不是網站**。 由于智能客戶端會刪除許多讀取，因此大多數數據庫活動都是**大量寫入**。 典型數據庫主機上 60％的負載是寫操作，而大多數網站往往讀起來很繁瑣。 由于游戲是通過網絡進行的，因此很容易將它們視為網站，但實際上它們是通過網絡交付的應用程序。 14. **重負載時間延遲**。 Playfish 游戲具有全球用戶的意義，因此具有全球性。 由于游戲是在智能客戶端中異步進行的，因此游戲等待時間并不重要，這意味著在加載游戲（即 Flash 游戲+資產）時，用戶會遇到最明顯的等待時間，因此，他們必須盡可能減少這種情況。 15. **來自用戶**的實時反饋。 社交游戲通過網絡以數字方式在社交網絡上分發，從而完全繞開了通過商店或電信公司的傳統分發渠道。 第一次沒有中間人控制游戲發行。 任何用戶都可以坐在家里，隨時隨地與他們一起玩。 游戲制作者現在可以以前所未有的方式與觀眾建立聯系。 可以直接與用戶群聯系，以幫助發展和改進游戲。 用戶可以向游戲設計師提供實時反饋，并影響他們玩的游戲的設計。 16. **社交游戲是服務，而不是盒子**。 傳統游戲是在盒子中的架子上購買的，而發行商則控制頻道。 他們向同一位 25 歲的硬核游戲玩家銷售產品。 社交游戲正在擴展到[新市場](http://venturebeat.com/2010/08/23/one-in-five-americans-plays-games-on-social-networks/)，吸引了從未玩過游戲的人。 作為一項服務的游戲在玩家和游戲背后的創意團隊之間建立了非常長的關系。 可以每周發布一次，一起培養游戲，并不斷學習玩家的需求。 在擁有多年的開發周期之前，這是不可能的。 17. **人們已斷開連接，正在尋找連接**的方法。 寵物協會是一個虛擬的世界，玩家在這里裝飾自己的房屋和朋友的房屋。 在圣誕節前后，他們開始以每個 2 美元的價格出售虛擬圣誕節和裝飾品。 他們出售了價值 4000 萬美元的虛擬貨幣。 行為分析的忠實擁護者，他們問用戶為什么要這么做？ 歸結為與斷開聯系的人們建立聯系。 以前，他們家里會有一棵樹，人們會看到樹和他們的創造力。 現在人們都斷開了連接，因此 3-4 個朋友可以看到真實的圣誕樹，而他們所有的朋友都可以看到 Facebook 上的虛擬圣誕樹。 在吸引人方面，您的虛擬貨幣有更大的優勢。 推動購買的是對社交表達自我的渴望，虛擬商品是手段，社交網絡是新領域。 就像在現實世界中一樣，購買虛擬禮物是為了在與朋友互動中獲得感知的價值。 18. **背景模擬**。 像 Restaurant City 這樣的游戲開始具有后臺模擬組件，即使用戶不在網上也可以運行。 這導致游戲以鼓勵玩家定期回頭的方式發展。 例如，在《餐廳城》中，玩家需要確保為餐廳員工提供食物。 此模擬組件是一個有趣的新負載，必須將其集成到游戲基礎結構中。 19. **需要一次縮放幾個不同的維度**。 Playfish 需要擴展以支持更多的用戶，更多的游戲，每位用戶更多的數據，每位用戶更多的訪問權限，更多的開發人員和更多的運營人員。 擴展最困難的事情是擴展支持一切的人員。 ## 關鍵擴展策略 為了應對這些力量，Playfish 遵循了一些關鍵的擴展策略： 1. **樂趣**。 為了推動增長，關鍵的設計指標是創造一款如此有趣的游戲，以至于它會產生強烈的情感，使人們感到他們只需要玩游戲，就必須邀請他們的朋友加入游戲，以獲得更多的樂趣。 在朋友的社交網絡中分享情感時，情感會最大化。 傳統游戲是具有出色聲音和圖形的沉浸式體驗。 Playfish 嘗試設計用于社交互動的游戲，通過邀請朋友讓您從游戲中受益。 您可以自己玩 Restaurant City，但邀請您的朋友在您的餐廳做飯會更有趣。 通過在游戲中添加朋友，您會逐漸獲得更多樂趣。 用戶希望與朋友互動以獲得更多樂趣的愿望推動了更大的發行量和增長。 2. **基于微交易的收入模型**。 [微型交易](http://blogcritics.org/gaming/article/microtransactions-in-games/)通常是高交易量，低價值的交易。 為了支付服務費用，Playfish 通過玩家購買游戲內虛擬物品和服務來賺錢。 Playfish 還從廣告和[產品展示位置](http://venturebeat.com/2010/04/20/ea-playfish-president-the-billion-dollar-social-game-is-achievable/)中獲利。 該策略支持免費游戲模式，同時基于自然游戲收入提供收入。 3. **云**。 Playfish 從一開始就一直是 100％基于云的，并于 2007 年在 EC2 上發布了他們的第一款測試版游戲。云幾乎是我們上一節所介紹的眾多力量的完美答案。 我不會談論云的所有[奇觀，但您很容易看到彈性如何幫助解決他們的許多可變需求問題。 如果游戲變得流行，它們可以增加更多資源來處理負載。 無需采購流程。 如果需求下降，他們可以簡單地將實例退還給您。 云的 API / IaaS（基礎設施即服務）性質可以輕松滿足其對敏捷性的需求，保持團隊規模的需求以及早期及經常發布的要求。 您可能會認為按使用付費模式的云太昂貴了，我們將在云部分中對此進行更多討論，但是他們并不這么認為。 他們更加擔心無法在快速發展的市場中開發新游戲和改進現有游戲的機會成本。](http://highscalability.com/how-do-you-explain-cloud-computing-your-grandma) 4. **SOA（面向服務的體系結構）**。 他們在 SOA 方面非常重要。 這是他們架構的組織原則以及他們如何構造團隊。 每個游戲都被視為單獨的服務，并且彼此獨立發行。 內部組織成提供 API 的組件的軟件，并且這些組件分別進行管理和可伸縮。 5. **分片**。 Playfish 是一項寫重服務。 為了處理寫入，Playfish 采用了[分片架構](http://highscalability.com/blog/category/shard)，因為這是擴展寫入的唯一真正方法。 6. **BLOB** 。 沒有為用戶存儲多個記錄。 相反，用戶數據存儲在 MySQL 中的 [BLOB](http://en.wikipedia.org/wiki/Blob_(computing)) （二進制大對象）中，因此可以通過鍵值方法快速訪問它。 7. **異步**。 在服務器上進行寫操作與游戲是異步的。 用戶不必等待服務器上的寫入完成就可以繼續玩游戲。 他們試圖盡可能向用戶隱藏延遲。 在 MMO 中??，每一步都必須傳達給所有用戶，而延遲是關鍵。 Playfish 游戲并非如此。 8. **智能客戶端**。 通過使用智能 Flash 客戶端，Playfish 能夠利用客戶端計算機上更高的處理能力。 隨著他們添加更多用戶，他們還增加了更多的計算能力。 他們必須正確平衡服務器端和客戶端端的內容。 適當的組合因游戲而異。 智能客戶端緩存讀取內容，但它也允許游戲在客戶端上獨立進行，而無需與服務器對話。 9. **數據驅動的游戲改進**。 Playfish 收集了大量的游戲數據，用于持續改進現有游戲并幫助確定接下來要發明的游戲。 他們正在使用 Amazon 的 Elastic Map Reduce 作為其分析平臺。 10. **敏捷**。 Playfish 的所有思想中的一個共同點是對靈活性的不懈需求，以便能夠快速，輕松，高效地應對各種情況。 敏捷性體現在他們對云的選擇上，圍繞服務進行組織，快速發布周期，保持團隊規模小和有能力，并通過數據挖掘和客戶反饋不斷改進游戲設計。 ## 基本游戲架構 1. 游戲在 Flash 客戶端中運行。 2. 客戶端以服務級別 API 的形式將請求發送到 HAProxy 服務器，該服務器在 Amazon 云中運行的 Jetty 應用程序服務器之間負載均衡請求。 3. 所有后端應用程序均使用 Java 編寫，并使用面向服務的體系結構進行組織。 4. Jetty 服務器都是無狀態的，從而簡化了部署，升級并提高了可用性。 5. MySQL 被用作數據層。 數據在 MySQL 服務器之間進行分片，并以 BLOB 格式存儲。 6. Playfish 是 Amazon 云的早期采用者，因此他們無法利用諸如負載平衡之類的 Amazon 后來的開發。 如果他們必須從頭開始，他們可能會朝這個方向發展。 7. 更改被異步推送到服務器。 該系統的設計不是讓用戶單擊按鈕，而是將操作發送到服務器以查看發生了什么，而是使系統有權讓客戶端決定操作是什么，然后由服務器檢查該操作是否有效。 處理在客戶端。 如果用戶和服務之間存在高延遲，則由于異步保存和智能客戶端，用戶將看不到它。 在一天結束時，用戶看到的才是最重要的。 重要的是，當網絡中出現故障或等待時間較長時，用戶將獲得有趣的游戲體驗。 8. Playfish 的前幾款游戲是簡單的單人游戲，例如《誰擁有最大的大腦》，并具有高分和挑戰等功能。 在服務器端不是很復雜，也不是很沉重。 從項目開始到結束，他們只有 5 周的時間。 其中包括對 Facebook API 的學習和編碼，對 AWS 的學習和編碼，對游戲服務器的編碼以及建立生產基礎架構。 前三場比賽延續了這種模式：高分和挑戰。 這給了他們一些喘息的空間，可以開始建立自己的基礎架構。 改變事物的第一款游戲是 2008 年的寵物協會。這是第一款大量使用虛擬物品的游戲。 數據存儲從為每個用戶存儲一些屬性（如化身定制和高分）到為每個虛擬項目存儲每個用戶潛在的數千個項目。 這給系統帶來很大壓力。 早期，隨著服務增長非常迅速，出現了一些大服務問題。 然后他們進行分片，系統變得更加穩定。 但是首先，他們嘗試了其他各種技術。 他們嘗試一次添加更多的只讀副本，例如一次添加 12 個，但這并沒有真正起作用。 他們嘗試盡最大可能修補系統。 然后他們咬住子彈并放入分片中。 從開始到推出共花了 2 周的時間。 在該游戲中，所有性能問題都消失了。 隨著時間的流逝，用戶獲得了很多虛擬物品，因此行的數量爆炸了。 每個項目都存儲在其自己的行中。 即使您將用戶劃分為舊用戶的碎片，即使用戶數量保持不變，碎片也會不斷增長。 這是轉到 BLOB 的原始驅動程序之一。 BLOB 擺脫了導致此類性能問題的多個行。 隨著時間的流逝，游戲開始變得越來越復雜。 寵物協會沒有任何模擬元素。 然后，他們在 2008 年底推出了“餐廳城市”，該餐廳具有第一個離線模擬元素。 當玩家不在時，您的餐廳繼續營業并賺錢。 這帶來了挑戰，但是在云中添加額外的處理相對簡單。 模擬邏輯是在客戶端中實現的，服務器將執行諸如檢查欺詐的操作。 ## 面向服務的架構 1. Playfish 確實是 SOA 的主要倡導者。 SOA 將數據和功能封裝在一起，可以通過分布式系統獨立部署。 分布式組件通過稱為*服務合同*的 API 進行通信。 2. 服務確保系統所有部分之間的依賴性是眾所周知的，并且盡可能松散耦合。 3. 支持復雜性管理。 該系統可以組成單獨的易于理解的組件。 4. 組件是獨立部署和升級的，這提供了靈活性和敏捷性，并使得擴展開發和運營團隊變得更加容易。 5. 可以獨立于其他服務來優化獨立服務。 6. 服務失敗時，更容易正常降級。 7. 每個游戲都被視為一項服務。 UI 和后端是一個包。 他們沒有分別發布 UI 和后端。 ## 云端 1. Playfish 從一開始就是 100％基于云的，于 2007 年在 Beta 版 EC2 上發布了他們的第一款游戲。 2. Cloud 使 Playfish 能夠以極低的摩擦力進行創新并嘗試新功能和新游戲，這是快速發展的市場的關鍵。 從他們的多個只讀副本系統遷移到分片系統需要 2 個星期，如果沒有云的靈活性，這是不可能完成的。 3. 云使他們能夠專注于使他們與眾不同的地方，而不是構建和管理服務器。 由于云運營無需專注于機器維護，因此他們可以專注于更高價值的服務，例如跨所有不同服務器和游戲開發自動化。 4. 現在，在設計應用程序時將容量視為一種商品。 5. 服務器與操作人員的比例為 100：1。 由于云基礎架構，如此高的比率是可能的。 6. 服務器發生故障，因此必須從頭開始計劃。 7. 不可能繼續向服務器添加內存，因此您可能必須提前擴展。 8. 云的關鍵特征是*靈活性*。 您可以根據需要靈活地進行操作。 當您突然得到大量流量時，您無需感到驚訝。 您不必等待服務器的采購。 9. 您永遠都不知道游戲將以多快的速度起飛。 有時您確實知道，體育游戲發展很快，但其他游戲可能會突然爆炸。 在云中，這不一定是問題。 10. 從一開始，就從來沒有想到它們可以在云中進行擴展。 一切都旨在通過添加更多計算機來擴展。 11. 他們不能使用所有的 Amazon 服務，因為必須自己滾動。 離開他們所了解的自己的系統會帶來不必要的風險。 例如，沒有 ELB 和 RDS，因此必須自己構建。 現在切換到那些服務沒有任何意義。 12. Playfish 是云的核心。 他們充分利用了云中的一切。 輕松獲取更多容量。 他們根本沒有內部服務器。 所有開發機器都在云中。 云使啟動新環境變得輕而易舉。 例如，要測試分片很容易，只需使用新配置復制所有內容即可。 在數據中心中運行時，這要困難得多。 13. 考慮到所有因素，**云比裸機更昂貴**。 1. 基于帶寬和機架空間的單位，裸機可能看起來更便宜，但是如果您查看所獲得的所有東西，那將是很多工作。 以高級可用性功能為例。 更改 API 調用，您將獲得雙數據中心。 在裸機情況下，您無法做到這一點。 僅考慮設置和維護的人員成本。 云看起來確實很昂貴，但是當您獲得真正大容量時，中斷就開始了。 2. 要考慮的主要成本是**機會成本**。 這是最大的優勢。 例如，當他們第一次在 Pet Society 中實施分片時，從開始到部署需要 2 周。 用戶立即感到高興。 它們的實現速度取決于能夠在生產中激發整個服務器負載以及測試和遷移數據。 如果您有兩個月的交貨時間，那么您將有兩個月不滿意的用戶。 14. Playfish 在同一區域內的多個可用區中運行。 服務器相對靠近，這減少了延遲。 它們不會像 MMO 系統那樣散布開來。 使用異步寫入，客戶端中的緩存和 CDN 中的緩存在更高級別上處理延遲。 在服務器上執行游戲操作可能需要 3 秒鐘，但是由于它是異步的，因此用戶不會注意到。 CDN 有助于減少他們注意到的內容，即資產和游戲的負載。 15. CloudFront 用于減少負載延遲。 從某種意義上說，Playfish 是全球性的，擁有世界各地的用戶。 游戲的加載時間（包括 Flash 代碼和游戲資產）是它們最明顯的延遲。 CloudFront 可以在分發內容時減少這種延遲。 ## 數據庫系統 1. MySQL 被用作存儲 BLOB 的分片鍵值數據庫。 2. 用戶跨多個數據庫集群進行分片，每個集群都有自己的主副本和只讀副本。 1. 他們擁有更多副本的好處不多，因為它們寫得很重。 幾乎所有流量都是寫操作。 寫入很難縮放。 無法緩存，更多的只讀副本無濟于事。 2. 在較早的體系結構中，他們有一個具有 12 個讀取從屬設備的主設備，表現不佳。 3. 通過分片，他們從一個母版和 12 個只讀副本變成了兩個母版和兩個只讀副本，這對讀寫都有幫助。 3. 分片意味著索引變小，這意味著它們可以容納在內存中。 將索引保留在緩存中可確保用戶查找不必打到磁盤，可以從 RAM 提供查找。 4. 通過分片，他們可以控制每個分片中有多少用戶，因此，他們可以確保自己不會破壞內存索引緩存并開始訪問磁盤。 5. 他們試圖優化用戶記錄的大小，以便更多用戶可以容納在內存中。 這就是為什么他們去存儲 BLOB 而不是使用標準化為行的數據的原因。 現在，每個用戶只有一個數據庫記錄。 6. 工作從數據庫服務器中取出并移到應用程序服務器，這些服務器很容易在云中水平擴展。 7. 大多數網站都使用諸如內存緩存之類的擴展技術來進行讀取緩存，而這些技術對 Playfish 并不那么有用。 使用 Flash 客戶端時，將在 memcache 中緩存的大部分內容都將緩存在客戶端中。 將其發送到服務器一次并存儲。 8. 分片用于獲得更高的寫入性能。 1. 寫操作占 60％的工作量。 通常情況下是 10：1。 他們仍然使用 MySQL 進行數據存儲，因為他們對負載等情況下的性能統計非常滿意。 2. 每個分片都有一個母版，至少在只讀副本上。 大多數情況下，只有一個只讀副本，但這取決于服務的訪問模式。 讀取將拆分為讀取副本。 對于確實具有更多讀取的一些地方，它們具有更多的讀取副本。 只讀副本還用于遠程保留數據作為備份。 9. Playfish 是由純粹的必需品驅動的。 他們建立了自己的鍵值存儲，因為必須這樣做。 為什么不使用 NoSQL？ 他們正在研究選項，但同時他們有一個可行的解決方案，他們知道它將如何工作。 對 NoSQL 解決方案感興趣，用于操作端，用于管理多個數據庫。 進入運行 NoSQL 的模式并不容易，但這是由其需求驅動的。 10. 在橫向擴展情況下，您必須進行分片之類的操作，此時許多 SQL 功能都將消失。 您必須自己做很多工作。 現在，當您進行大批拆分時，您將無法添加索引。 11. 使用 NoSQL 時，您將放棄訪問模式的靈活性。 關系數據庫非常好，因為您可以隨時以所需的方式訪問數據。 例如，由于他們不能再使用 SQL 來匯總字段，因此它們都可以即時聚合或使用批處理過程進行聚合。 12. 備份到 S3。 ## Flash-客戶端 1. 客戶端的 CPU 和資源隨用戶數量的增加而擴展，因此明智地利用客戶端。 將盡可能多的處理推送給客戶端。 2. 更改被異步寫回到服務器，這有助于向用戶隱藏網絡延遲。 3. 在服務器端檢查更改以檢測作弊。 4. Flash 使用服務級別 API 與 Jav??a 應用程序服務器對話。 5. 使處理過程更接近客戶端可為用戶帶來更好的體驗。 網站使服務器更靠近用戶。 Playfish 在客戶端上使處理過程更加緊密。 ## YAMI4-訊息 1. 經過長時間的評估，YAMI4 是 Playfish 決定使用的消息傳遞系統。 它提供點對點連接，低延遲，無單點故障以及異步消息傳遞，以在多個后端服務中進行事件驅動的處理和并行處理。 2. 服務經過發現階段以了解每個端點的位置后，消息將直接在服務之間傳輸。 這是一種無經紀人的模式。 消息不會集中到集中式服務中，然后再重新分發。 使用此模型，消息傳遞非常有效，因為沒有中間躍點，因此減少了延遲。 他們特別不想讓一個單獨的組件來處理流量，然后傳遞消息。 這種方法減少了故障點和延遲。 3. 被認為是節儉的，但是 YAMI4 因其異步操作而獲勝。 Thrift 使用看起來像本地函數調用的 RPC 模型，這使得處理錯誤，超時等更加困難。YAMI4 是消息傳遞模型，而不是 RPC 模型。 4. YAMI4 不處理服務發現方面，而是在發現階段然后直接與其他服務對話的基礎上構建自己的服務。 互聯網的運作方式更多。 5. 作為消息傳遞系統，消息不會調用對象上的方法。 也沒有對象在網絡上流動。 對象存在于服務中。 每個服務負責激活，鈍化和調度操作。 ## 處理多個社交網絡 1. 他們的主要挑戰之一是能夠支持這么多不同且越來越不同類型的游戲。 2. 盡可能使用*松耦合*的原理： 1. 團隊擁有的服務使團隊結構與體系結構相匹配。 2. 服務保持良好定義的接口，以便每個團隊可以迭代并部署自己的服務，而不會影響其他團隊。 3. 當需要更改接口時，將對接口進行版本控制。 他們試圖保持向后兼容性，以便其他團隊不必推出更改。 3. 為了促進所有這些，將一套通用的標準應用于所有服務： 1. 公共服務運輸（YAMI4） 2. 通用操作標準，例如如何配置服務以及它們如何提供監視信息。 4. 通用標準和松散耦合的結合使開發和運營團隊既靈活又高效。 ## 開發與運營 1. 服務彼此獨立發布。 2. 資源按服務分開。 一項服務出現問題不會影響不相關的服務。 3. 團隊是按服務組織的，盡管有一些重疊。 4. 盡管存在密切的關系，但運營團隊與開發團隊是分開的。 沒有大的交接階段。 他們不只是在墻上扔一個釋放。 操作包括在設計中。 5. 開發人員不發布代碼。 他們將其檢入并由操作人員將其撿起。 6. 團隊在部署方面具有很大的靈活性。 大多數游戲每周發布一次。 一切都是迭代的，這意味著代碼足以投入使用，但功能不一定完全完成。 每周發布周期對于帶有虛擬物品的游戲特別有價值，因為用戶喜歡每周都知道有新的令人興奮的東西。 其他團隊可以使用更長的功能塊。 這取決于。 這是從事 SOA 的優勢之一。 團隊可以獨立工作。 不需要一個發布周期。 ## Java-服務器 1. Java 支持創建干凈的可重用組件。 2. 有大量的開源庫。 3. Java 是靈活的：它可用于實現 Web 應用程序，流程請求，批處理和事件驅動的系統。 4. Java 有許多調優選項。 他們做了很多工作來調整垃圾回收以提高性能。 ## 游戲設計 1. 為了使游戲用戶享受 Playfish 的樂趣，它將數據驅動的設計與良好的，受人啟發的古老游戲設計結合在一起。 數據可用于指導用戶制作游戲的許多決策。 他們可以從數據中看到用戶最擅長的事情。 這告訴了他們如何使游戲和個人游戲變得更好，以及在設計新游戲時該怎么做。 2. Playfish 喜歡行為分析。 他們查看人們在游戲中正在做什么，然后問他們為什么。 在支持方面，客戶端和服務器具有很大的能力來生成有關用戶操作的事件。 然后處理這些事件，以創建有關用戶在游戲中所做操作的匯總信息。 他們現在正在使用 EMR / Hadoop / Hive 來通過類似 SQL 的界面訪問大量的數據。 在云中使用 EMR 的效果非常好，他們對此非常滿意。 大量數據可以粒度形式存儲，并且由于所有內容都可以并行工作，因此仍然可以快速找出所需內容，非常適合游戲產生的事件類型數據。 3. 用戶想要什么真是令人驚訝。 他們甚至可能自己都不知道。 人們認為他們想要的與人們實際使用的有所不同。 有時，用戶會說他們確實想要一些昂貴的功能，但最終卻沒有使用它們。 然后是沒有人提及但人們一直在使用的功能。 在論壇上發帖的人通常是不喜歡事物的人，因此很容易獲得一種非常不平衡的觀點，因為他們對游戲充滿熱情，討厭任何變化。 數據有助于找出人們真正喜歡的東西。 4. 游戲設計不能只是數據驅動的，否則游戲將毫無生氣。 您必須正確獲得數據驅動的平衡。 您不能僅僅按照數據說明的去做。 隨您的靈感去增加或增加游戲中的內容，然后使用數據來完善游戲。 5. 某些功能需要大量的工作來創建，但由于功能太復雜，用戶并沒有最終完成。 他們設置了渠道，以了解人們是否在完成功能之前就放棄了功能，然后他們就能找出原因。 也許某個功能需要調整或放棄。 參與度是用戶對游戲的熱愛程度的衡量標準。 然后，他們投資使人們回頭的內容，以便生態系統得以發展。 6. 敏捷+數據+設計=允許快速試用新啟發的功能，以查看它們是否有效。 結果是一個有趣的游戲。 7. 團隊分為緊密的小組，這些小組具有完全的創作自由。 所有團隊成員都對什么使游戲更有趣發表了意見。 8. 運行游戲實驗是為了尋找合適的位置，以查看合適的位置。 有些會成功，有些會失敗。 ## 得到教訓 1. **建立一個利用應用程序特殊性質的體系結構。** Playfish 已針對其特定需求量身定制了一種體系結構。 不要嘗試構建可以擴展所有內容的通用體系結構。 利用空間的本質，使生活盡可能輕松。 2. **不用擔心第一次正確**。 把東西拿出來，開始學習。 如果他們試圖達到 3 年前的現狀，那么他們仍然會構建系統。 他們提出了一些根本無法擴展的東西，但他們在 5 周內就解決了。 這是關鍵。 3. **不要害怕堅持知道和了解的東西**。 選擇您熟悉的東西。 您不需要選擇最新和最酷的產品。 充分了解產品并能夠預測產品在您的用例中的運作方式具有很多價值。 這樣，您將減少很多麻煩。 4. **首先保持簡單，然后在需要時進行擴展**。 利用該提前期來構建您所需的內容。 5. **碎片和 BLOB** 。 使用分片擴展寫操作。 使用 BLOB 將每個用戶的記錄數減少到一。 這樣可以加快對象訪問速度，并允許在 RAM 中添加更多對象。 6. **總是有一個粗略的想法，你將如何擴展**。 不要過早設計功能，但不要創建破壞性的依賴關系。 例如，可以在不進行適當縮放的情況下啟動就可以了，擁有在分片后無法使用的功能也不是一件很酷的事情。 7. **縮放數據比縮放處理**困難。 您在哪里存儲數據？ 有多少人需要讀寫？ 無狀態應用程序服務器使添加更多處理變得容易，而數據擴展則困難得多。 8. **不要過度復雜**。 擴展簡單系統更容易。 保持盡可能長的簡單性。 這使您可以了解痛點所在，然后可以專門解決這些痛點。 許多人認為他們必須從第一天開始就建造巨大的東西。 例如，如果您不需要多級緩存，則不要放入它，因為您必須支持它。 9. **使用 SOA 管理復雜性**。 隨著新游戲的添加，將代碼分成由不同團隊管理的不同組件有助于降低系統的整體復雜性，從而使一切易于擴展。 10. **承擔計算的風險**。 Playfish 進入了云環境，但是有一個備份計劃，以防萬一失敗。 這是一種風險，但也有很多好處。 如果亞馬遜取消了他們的服務，那么如果他們真的需要，他們可以搬家。 這就是使用“基礎架構即服務”的好處。 使用“平臺即服務”存在更大的風險，因為您建立了更深的依賴關系。 例如，當 fPlayfish 擁有自己的有效鍵值數據庫時，轉移到 NoSQL 產品的風險也太大。 11. **運營和開發應了解系統如何在生產中工作**。 容易管理嗎？ 支持客戶容易嗎？ 如何配置和監視它？ 開發您需要實現所有這些的東西。 開發人員不能只是在墻上扔代碼。 應該沒有墻。 12. **使用數據可以幫助您找到人們真正喜歡的東西。** 用戶并不總是知道自己最喜歡什么。 檢測您的代碼并分析數據以找到有意義的模式，并使用該信息來不斷改進系統。 13. **最難擴展的是人**。 必須使人們的工作變得非常容易。 獲得更多的服務器要比獲得更多的人容易得多。 我要感謝 Playfish 抽出寶貴時間進行了這次翔實而有見地的采訪。 如果您希望 HighScalability.com 上具有您的體系結構，請[與我](http://highscalability.com/contact/)聯系以開始使用。 Playfish 正在尋找人。 有關職業機會，請參見其[職位頁面](http://www.playfish.com/?page=jobs)。 從我與幾個人的交往中，一個 Playfish，他們似乎把他們的東西放在一起。 值得一看的是，他們有很多空缺職位，他們正在尋找服務器端工程師。 他們希望構建新系統，以使用 EMR / Haddop / Hive 更好地了解用戶，并擴展整個系統以添加更多用戶和游戲。 ## 相關文章 1. [Playfish 展示了“游戲即服務”如何在云中擴展](http://www.readwriteweb.com/cloud/2010/08/playfish-shows-how-games-as-a-.php) 2. [訪談：Playfish 通過我的帝國在簡單的動作中尋找意義](http://www.gamesetwatch.com/2010/08/interview_playfish_on_finding.php) 3. [AWS 案例研究：Playfish](http://aws.amazon.com/solutions/case-studies/playfish/) 4. [EA Playfish 高管吹捧下一代 Facebook 游戲](http://venturebeat.com/2010/05/14/ea-playfish-exec-sebastien-dehalleux-touts-next-generation-facebook-games/) 5. [深入了解：Playfish](http://blog.kissmetrics.com/an-in-depth-look-playfish/) 6. [介紹 Playfish](http://www.slideshare.net/sdehalleux/introducing-playfish) 7. [在社交游戲峰會](http://www.insidesocialgames.com/2008/06/13/lives-notes-from-asynchronous-games-on-social-networks-at-social-gaming-summit/)上直播“社交網絡異步游戲”的筆記 8. 視頻： [SGS09：大規模構建社交游戲](http://www.youtube.com/watch?v=dLCSGm_tkfM)。 9. 視頻： [SGS2008：社交網絡上的異步游戲](http://www.youtube.com/watch?v=3zIXY1upwTI)。 10. [異步游戲](http://www.cs.vu.nl/~eliens/media/pattern-asynchronousgames.html)。 11. [異步多人游戲：Ian Bogost 的休閑多人游戲體驗](http://www.bogost.com/writing/asynchronous_multiplay_futures.shtml)的未來。 非常有趣的東西-感謝分享！ 我真的沒有這樣的句子：“要招募更多的人要比招募更多的人容易得多。” 請解釋。 謝謝托德，它非常有用。 順便說一句，我喜歡 Playfish 的運作方式： > 由于您的朋友很少同時在線，因此社交游戲是異步進行的。 如果您認為 Cloud 最好，那顯然是因為您尚未大規模使用它。 我們在亞馬遜上運行著數百臺服務器，而連接問題的數量（即無法到達實例，x 可用區網絡問題）和它們具有的 I / O 性能讓我們感到“驚訝”； 在過去的六個月中，他們最長可以無問題地停留的時間是 8 天，這意味著我們每周或更少的時間都會因為亞馬遜的“超級云”而獲得生產“成功”。 我的建議：使用云來擴展和穩定，然后移開地獄。 干杯。 這是拼寫錯誤的塞巴斯蒂安，謝謝。 克里斯，那是您的現代時代:-) 很棒的文章 Tood，感謝您提供。 Playfish 在數據庫分片方面的經驗與我們在快速增長的 dbShards 實現中所發現的完全一樣。 如上文所述，由于利用內存來實現數據庫平衡，因此我們的社交應用程序以出色的性能運行。 關于此報價： > 在橫向擴展情況下，您必須進行分片之類的操作，此時許多 SQL 功能都將消失。 您必須自己做很多工作。 現在，當您進行大批拆分時，您將無法添加索引。 我們可以輕松支持混合使用典型表和鍵/值 blob 數據，就像 Playfish 一樣。 我想知道其他人怎么想：傳統表結構與鍵/值 Blob 的無縫結合？ 在這兩種情況下，我們都可以支持高可用性操作，而無需開發人員的任何努力。 這樣，您可以從常規表中獲得所有索引/搜索優勢，并且它們可以在適當的地方指向 Blob 值（例如，用戶個人資料信息）。 很棒的文章。 他們使用什么 Web 服務器？