應用程序結構如果一個對象應該在許多子域應用程序中

Question

我想構建遊戲管理。用戶可以玩很多遊戲，每個遊戲都有自己的分數，等級，用戶的徽章。因此，讓我得出這樣的應用程序的基本結構：

Game-Management 
    Game-1 
     User: (internal logic of gameplay: how user move, how user buy item, how get user's score...) 
    Game-2 
     User: (other logic: how user add new user to friend list, how user get to battle, ...) 
    ... 
    Game-N 

後端是非常好的，因爲每場比賽由一個團隊開發，這些團隊不需要知道對方。 但在前端，我想管理所有用戶遊戲的統計數據。用戶轉到他的個人資料頁面，此頁面列出他所玩的所有遊戲。當他點擊一個遊戲時，所有的統計數據都會顯示出來。例如，他點擊到Game-1，他可以查看他的分數，他購買的所有物品。如果他點擊Game-2，他可以查看他的朋友列表，他加入了多少次戰鬥。

但是這是關鍵點，因爲在後端，我的團隊分別開發每個遊戲，而在前端我只想在一個地方管理它們。所以這個想法好還是不好？如果它很好，我如何在後端和前端構建我的應用程序？否則，請給我其他解決方案。謝謝！

Answer 1

我想我會建議你使用基於空間的架構。
它被谷歌和雅虎等巨大公司廣泛用於構建易於集成的不同類型的模塊。

http://en.wikipedia.org/wiki/Space-based_architecture

所以基本上你有經理的對象，這將操縱模型。
模型上的函數將只接收一種模型的一種類型的消息對象。
模型上的函數還會返回一種模型的一種類型的消息對象。

所以，你有GameManager對象作爲處理網格層。
然後，你有Game1Message對象作爲消息網格層。
接下來，您將DbModel: a.k.a User對象作爲數據網格圖層。

謝謝

Answer 2

這是一個很好的點，我遇到這個問題了幾次過去。在服務器本地

1. 商店統計/日誌和從中央服務器收集此：

   我在兩種不同的方式解決了這個。 臨：

   • 易於控制負載
   • 有
   • 你獲得本地服務器上的一些備份空間
   • 每場比賽能更統計/數據添加到日誌它更容易無單一故障點添加這種類型的數據
   • 本地磁盤寫入是一個非常快速的動作，比RestApi更快。這裏沒有網絡層。
   • 您可以在中央服務器上控制工作負荷

缺點：

• 格式應該由所有不同的服務器
• 向上擴展來滿足，如果一個遊戲是超級流行的CAN有點問題
• 您需要確保寫入日誌的文件全部同步
• 與中央服務器可以收集在高容量磁盤放在高負荷的工作在一臺服務器
• 上總會有一個最大容量（〜600 I/O的SaaS，5000 I/O SSD）

2.RestAPI在一臺可處理所有數據的中央服務器上，每場比賽都會通過API報告需要進行統計跟蹤的事件。您還可以使用第三方的事件記錄（谷歌分析事件），並通過API

贊成這個報告拉：

• 簡單集成的開發
• 輕鬆地添加新的功能
• 規模與應用程序更容易。該API可以直接給負載均衡，將引導到處理負載

缺點很多
服務器：

• 網絡負載現在被添加到服務器的負載
• 依靠網絡延遲/停機
• 依靠遊戲上的另一臺服務器的負載

實施使用API​​非常簡單，本地日誌可能有點棘手。您需要分發日誌格式。爲日誌創建一個已知文件夾，併爲主服務器創建一個映射，以瞭解從何處收集數據，然後將其解析爲數據庫。儘管聽起來更復雜，但我發現第一種方法非常有效，並且幫助我降低了服務器成本。

希望有這個幫助..