# 擴展世界杯-Gambify 如何與 2 人組成的團隊一起運行大型移動投注應用程序 > 原文： [http://highscalability.com/blog/2014/7/7/scaling-the-world-cup-how-gambify-runs-a-massive-mobile-bett.html](http://highscalability.com/blog/2014/7/7/scaling-the-world-cup-how-gambify-runs-a-massive-mobile-bett.html)  *這是 [cloudControl](https://www.cloudcontrol.com) 的 Elizabeth Osterloh 和 Tobias Wilke 的來賓帖子。* 初創企業在構建軟件時所面臨的問題與大公司完全不同。 較大的公司在更長的時間范圍內開發項目，并且通常擁有整個 IT 部門來支持它們創建定制的體系結構。 當初創公司有一個好主意，它廣受歡迎并且需要快速擴展時，情況就完全不同了。 Gambify 就是這種情況，Gambify 是一種組織投注游戲的應用程序，適時發布了世界杯足球賽。 該公司成立于德國，僅由兩個人經營。 當他們設法獲得一些主要認可（包括阿迪達斯和德國隊明星托馬斯·穆勒）時，他們不得不為突然涌現的用戶以及非常特定的高峰時間做好準備。 ## Gambify 應用：基本架構 Gambify 的核心是基于 Symfony2 的 PHP 后端，該后端通過 Rest API 將數據提供給前端。 前端是用于桌面瀏覽器的 Ember.js 應用程序，其中的 PhoneGap 包裝用于移動應用程序。 Gambify 代碼庫分為多個包，可用于不同的場景，例如 隨后是世界杯的比賽場景，然后是德國國家聯賽或其他歐洲聯賽的聯賽場景。 為了存儲數據，Gambify 除了使用結果表之外，還使用常規的 MySQL 數據庫。 在這里，他們將賭注匯總到 Redis 中。 ## 主要挑戰 * **在沒有專門團隊的情況下實現可用于生產的基礎架構**。 最初，團隊從托管在專用服務器上的較小，較不高級的應用程序版本開始。 他們面臨配置和維護它的困難，因此決定專注于開發應用程序本身。 他們需要一個易于維護和擴展的解決方案。 * **規劃基于需求的資源使用，尤其是在比賽**之后的高峰時段。 用戶傾向于在游戲后立即登錄以查看比賽結果及其排名-此時，負載可能會增加到每分鐘 10.000 個請求。 * **最大化應用速度，** **，尤其是在更新匹配結果和排名**時。 用戶期望在使用該應用程序時將延遲降到最低，并在訪問當前結果和排名時獲得快速響應。 ## 與云基礎架構集成 Gambify 決定在如此小的團隊中配置和維護專用服務器很困難，因此決定搜索平臺即服務提供商。 他們決定使用 cloudControl PaaS。 **Buildpacks** ：Gambify 是用 PHP 編寫的，最初在 Apache 服務器上運行以進行測試。 cloudControl 平臺使用 Buildpack 系統，這是一種用于準備要部署的映像的開放標準，它已成為事實上的云平臺之間互操作性的行業標準。 cloudControl PHP buildpack 提供了與原始設置相同的開源組件，因此 Gambify 能夠將其現有應用程序“插入”到 cloudControl 平臺，而無需進行任何重大更改。 **容器**：cloudControl 平臺基于容器。 容器基于 LXC 技術，并且包含堆棧映像，部署映像和配置。 堆棧映像提供了底層操作系統和通用庫。 部署映像包含現成的應用程序。 這些配置可以包括數據庫和其他第三方服務的訪問憑據。 可以垂直縮放容器（跨多個實例）或水平縮放容器（通過增加內存和處理能力）。 Gambify 能夠在單個容器上測試其應用程序，然后使用 cloudControl 的粒度擴展功能根據需要進行擴展。 **路由&請求分發**：cloudControl 路由層使用反向代理負載平衡器集群來管理用戶請求的接受和轉發到平臺上運行的應用程序。 智能 DNS 以循環方式提供快速可靠的域名解析服務。 所有節點均等地分配到三個不同的可用區域，但可以將請求路由到任何其他可用區域中的任何容器。 為了保持較低的延遲，除非沒有可用的路由層，否則路由層將嘗試將請求路由到相同可用性區域中的容器。 這是自動處理的，因此 Gambify 可以將此方面外包給 cloudControl 作為服務提供商。 ## 優化基于需求的資源使用 Gambify 使用 New Relic 監視其性能。 這有助于他們確定游戲之前，之中和之后的用戶高峰模式。 他們還實時使用 Google Analytics（分析）來查看用戶負載何時增加，而請求負載卻沒有增加。 Gambify 優化的主要部分已預先完成，并通過使用 Loader.io 的負載測試進行了說明。 這樣一來，Gambify 就可以在客戶群過大而無法處理工作負載之前發現瓶頸。 **Gambify 應用：原始狀態** -10 個容器@ 512 mb -數據庫：MySQLd“微型”附加組件  （Loader.io：60 秒內有 2000 個客戶端） 從優化角度來看，Gambify 主要通過使用索引字段查詢來優化數據庫訪問，將對時間不敏感的部分移動到異步處理中，并在某些請求中跳過一些抽象層（ORM）。 這些優化有助于縮短單個請求的加載時間。 為了處理高峰時間，他們使用 cloudControl 的粒度擴展功能來進行擴展，尤其是在人們登錄游戲后立即查看結果和得分時。 然后，負載可以增加到每分鐘 10.000 個請求。 白天，Gambify 只能由一名工人在六個（128mb）容器上運行。 在比賽中，比賽后八名工人將它們最多擴展到 18（1024mb）個容器。 MySQL 數據庫在擴展方面面臨挑戰，因此他們決定使用一種大型 RDS 設置。 對于未來，他們正在考慮遷移到可伸縮數據庫。 **Gambify 應用：當前狀態** -18 個容器（512 mb） -MySQLd“中”加載項  (Loader.io: 2000 clients in 60 seconds) ## 最大化應用速度 Gambify 的許多應用程序速度優化都是通過異步作業處理來完成的，以便保持主要請求的快速。 為此，Gambify 使用了幾個與 cloudControl 平臺集成的第三方附加服務。 作業隊列通過 Redis 處理。 **用戶搜索**：異步處理的部分之一是外部 Web 服務，例如用戶搜索功能。 用戶與搜索索引（Searchly）同步，該索引使人們可以找到他們的朋友。 **用戶內容**：Amazon S3 用于存儲用戶內容，例如。 個人資料圖片。 圖片上傳被異步處理并調整大小，以防止移動客戶端在僅需要顯示縮略圖時加載更大的原始圖片。 **下注包裝**：Gambify 能夠非常快速地處理賭注并發布結果，因為所有賭注都分組為 1000 個賭注的包裝。 然后從 Redis 的作業隊列中處理這些。 因為他們知道最大的工作量是在每次比賽之后發生的，所以他們啟動了多個工作人員來盡快處理結果。 這些作業將加載所有賭注，并為每個單獨的賭注計算分數，然后重新計算表格中的相應分數。 ## 解決方案摘要 * **在沒有專門團隊的情況下實現可用于生產的基礎架構**。 Gambify 團隊決定專注于開發應用程序本身，并將基礎架構外包給 cloudControl。 通過 cloudControl，資源分配，路由和請求分配得以自動化。 * **規劃基于需求的資源使用，尤其是在比賽**之后的高峰時段。 通過使用 New Relic 監控性能，Gambify 能夠確定比賽之前，之中和之后的高峰時間。 他們使用 cloudControl 的細化縮放功能在比賽后的高峰時段直接放大，然后在一天的其余時間進行縮減。 * **最大化應用速度，** **，尤其是在更新匹配結果和排名**時。 Gambify 使用了幾種集成的第三方服務來最大化其應用程序中的響應時間，特別是通過使用 Redis 進行異步作業處理。 ## 在比賽結束時 這就是在德國比賽之后，對于 Gambify 來說，真正的請求高峰看起來是什么樣的-特別是 6 月 30 日對阿爾及利亞的比賽。 有趣的事實：根據 Gambify 的說法，這場比賽的頂峰略低，因為當德國獲勝時，人們會慶祝而不是檢查結果。  ## 目標！ 垂直擴展不是要向同一臺機器增加更多功率，水平擴展不是要添加新機器嗎？ 您在 cloudControl 容器部分中說了另一種方法。 非常有趣的文章，因為我目前在相同情況下（僅一名開發人員）開發服務。 只是一個錯誤：“容器可以垂直縮放（跨多個實例）或水平縮放（通過增加內存和處理能力）” 垂直擴展：增加內存和 CPU 水平擴展：添加更多服務器實例 我很好奇這種設置的成本，以及它們在高峰時段如何變化？ 與類似的專用服務器解決方案（具有如此規模）的成本有何比較？ 實際上，縮放是錯誤的方法。 非常不幸的混搭...我們將聯系 HS 進行修復。 通常，云服務提供更大的靈活性，而 PaaS 通常專注于在整個應用程序生命周期中提供自動化和編排，以幫助開發人員提高其日常工作效率。 成本收益通常不在于購買的每臺原始計算能力的價格比，而在于效率的提高，更多的是效率的提高，即通過使用該服務節省的時間，您可以專注于重要的事情。 可以這樣想：使用專用服務器，為服務器支付的費用較低，但是會附加大量的運營成本。 對于 PaaS，部分運營成本包含在使用服務的成本中。 但是總體而言，PaaS 的成本應該更便宜，因為運營商由于規模經濟而降低了運營成本。 小型項目通常可以很便宜地啟動并利用收益。 當您成長時，它通常會保持很長一段時間的經濟性。 最終可能會有一點，DIY 再次變得更加高效。 但這是一個問題，一旦您足夠大就可以輕松解決。