【深度】中台始作俑者Supercell的架構演進

成立于2010年，僅憑政府借貸的30萬歐元起家，從芬蘭30平走出來的遊戲公司Supercell在短短4年時間裡憑借《海島奇兵》《部落沖突》《卡通農場》這三款遊戲獲得了17億美元的收入，第五年受馬雲及阿裡高管團隊的登門取經，第六年被恐為人後的騰訊以86億美元收購其84.3%的股權。

騰訊下了一步好棋，在過去的十年（2010-2019）裡，Supercell的《部落沖突》和《皇室戰争》在全球手遊總收入排行榜上分别位列第一和第十（農藥第七）。當然錯失先機的阿裡也并非一無所獲，從Supercell高效的組織模式與技術架構，阿裡改組了事業群編制，并提出出了“大中台，小前台”的架構，一直熱門至今。

回頭來看Supercell這家公司，從其各款遊戲的畫風來看，基本是由一套統一的3D模型加工而成。（下圖從左至右：部落沖突、皇室戰争、海島奇兵）

當然這完全可以了解，畢竟畫風就是遊戲公司的招牌，換畫風相當于放棄既有使用者群體。另一方面也最大程度減小了美工團隊的規模和工作量，我們可以看到目前250人的Supercell中每個遊戲（共5款遊戲）平均隻有20人的團隊運維，其中還包括3名伺服器開發人員。

詳細來說，Supercell将組織按産品線分割，而非傳統的職能分割，管理以自底向上的方式，其創始人埃卡·潘納甯在接受采訪時就表示希望成為全球最“弱”的CEO，所有決定由遊戲團隊來做，畢竟研發者才是最接近玩家的，他們比任何人都更清楚玩家的需求。扁平化的管理也使得開發流程更加高效，靈活的不僅是開發團隊，還包括整個組織。

Supercell沒有單獨的運維團隊，每個遊戲團隊有自己獨立的AWS賬号（Supercell的IT輕資産化，所有應用程式都搭建在AWS EC2上），每個團隊各自應付數以億計的活躍使用者、高達400萬次的峰值并發帶來的應用壓力，以及AWS EC2上成百到數千的執行個體和跨地域不同數量的資料庫帶來的運維壓力。

解決了組織架構，為滿足企業在不同時期所面臨的外部并發，技術架構也必須是彈性擴充的，為此Supercell在成立第二年（2011年）就完成了應用的微服務化與資料庫層的切片。甚至來說Supercell的微服務更輕量級，所有的遊戲都複用一套網關代理、首頁子產品、比對子產品和戰鬥子產品。整個組織使用一套高可用的元件庫，一種開發語言，一個團隊即One Repo，One Language，One Team。上過阿裡中台課程的同學聽着是不是很熟悉？

微服務化可以友善地對任何一個功能子產品進行橫向擴充，作為一款遊戲來說，玩家的狀态資訊是實時變化的，是以戰鬥子產品中的所有元件都需要更新使用者狀态，全局的Zookeeper服務可以保證各元件間的使用者狀态保持一緻。使用者的所有狀态更新會通過事件的形式存放在持久資料湖中，關于事件驅動可檢視小編之前的文章。以下是玩家等級提升的事件樣例。

資料切片是将海量的使用者資料分地域存儲，每個地域的資料保持多個副本。類似于對資料的行進行拆分，但是不同地區資料的Schema是一緻的。在資料量不斷增大時，隻需增加切片數量來應對。

2012年，Supercell采用了統一的事件收集器，使用者産生的所有遊戲内資料通過REST API傳遞到AWS上的事件接收器，再以CSV的形式存放到Amazon S3存儲中。

随後的一年，一些團隊發現S3中的資料品質堪憂，為提升資料的精度，在2013年，Supercell的技術架構上加入了服務端事件收集器作為資料品質校驗的補充事件源，使用UDP通訊協定的目的是減少互動，最小化對遊戲主伺服器的影響。

事件管道的好處是架構簡單并且比傳統資料庫更能展現細節，畢竟傳統資料庫隻展示資料的最終狀态，事件可以幫助檢視達到這一狀态的完整過程。其弊端就是無法提供實時通路，稍不注意就會磁盤寫滿導緻資料溢出，并且Amazon S3是消費資料的唯一管道。

2013年下半年，Supercell終于考慮添加流式管道（Streaming Pipeline）作為資料緩沖層，由于之前和AWS的良好合作，這次的流管産品多數團隊也是投票給了Kinesis，相對于Kafka，它的運維更加簡單，體驗更好（天生與AWS管理界面內建），後續可以對接各種事件消費者，不論是實時查詢面闆，第三方內建，實時分析，還是通過事件內建入庫S3。

這套架構的優勢在于即便在系統故障時資料仍是安全的；通路資料更實時以及多通路的資料消費/訂閱，這有點像之前小編介紹的Uber資料架構，隻是streaming的産品換了。

熟悉Kafka的人都知道，在同一個消息分區（Partition）中，事件的時序是有保障的，但是為了運維友善加之對遊戲軟體對時序并不敏感，Supercell采取了随機分區的方式在不同資料切片上的負載均衡。

2013年同期在數倉設計上，Supercell使用Azkaban批量工作流任務排程器将CSV資料加載到AWS的Vertica數倉中，資料科學家通過開發接口對曆史資料進行分析，形成一些資料服務，對内或對外輸出。

這個架構在今後幾年裡遇到了新的瓶頸。首先Vertica叢集的負載達到的峰值，第二在ETL的時候查詢會變得緩慢，第三數倉的擴容花費巨大，第四存儲與計算耦合緊密，第五再大的寬表資料庫都會有列的極限。注意到這些問題之後，Supercell緻力于：

• 限制Vertica的資料存儲量；
• 将存儲與計算資源切割；
• 将ETL流程與查詢流程切割；
• 維護單一來源的置信資料；
• 利用雲的便利性優化資源使用。

到2018年，公司決定将Amazon S3作為單一置信來源，以Parquet清單的形式存放資料，将Amazon EMR用作ETL轉存目标，原來的Vertica隻用來存放計算結果（例如賬号、統計資料和KPI）而不是原始資料。

這樣一來，Azkaban還是控制ETL流程，隻是這次加載到Amazon EMR托管叢集平台，然後以多張Parquet清單的形式存放到Amazon S3中，因為公司已經對資料行數做了切片，使用清單存儲更能提升存儲效率。

分布式的S3作為唯一置信源，消費使用與清單更加契合的Athena作為查詢工具，資料科學家可以到源數倉EMR中檢視實時資料并做分析，包裝成實時資料産品，也可以通過界面工具到置信源S3或結果數倉Vertica中檢視OLAP大資料并進行模組化分析，生成資料産品。

在2018年完成改造之後，由于EMR的延展性，可以瞬間擴充出大量的資料集就很好地解決了列寬的問題，并且有效地将存儲與計算分離（EMR複制計算，S3負責存儲）。在ETL時可以通過計劃任務擴建一個叢集跑ETL，跑完之後釋放資源。而且EMR的環境對于資料科學團隊來說更加友好。

現在Supercell已被騰訊收購，相信Pony不隻是為了代理它的海島奇兵，騰訊雲一定也在醞釀一個“中台計劃”。