应用程序结构,如果一个对象应该在许多子域应用程序中

时间:2014-12-08 08:20:05

标签: design-patterns structure project-management

我想建立游戏管理。用户可以玩很多游戏,每个游戏都有自己的分数,级别,用户徽章。那么让我绘制这个应用程序的基本结构:

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,他可以查看他的朋友列表,他加入了多少次战斗。

但这是关键点,因为在后端,我的团队分别开发每个游戏,而在前端我只想在一个地方管理它们。所以这个想法是好还是坏?如果它很好,我如何在后端和前端构建我的应用程序?否则,请给我其他解决方案。谢谢!

2 个答案:

答案 0 :(得分:0)

我想我会建议你使用基于空间的架构 谷歌和雅虎等巨型公司广泛使用它来构建易于集成的不同类型的模块。

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

所以基本上你有经理对象,它会操纵你的模型 模型上的函数只能为一个模型接收一种类型的消息对象 模型上的函数还将为一个模型返回一种类型的消息对象。

所以,你有GameManager个对象作为处理网格层。
然后,您将Game1Message对象作为消息网格层。
接下来,您将DbModel: a.k.a User对象作为数据网格图层。

谢谢,

答案 1 :(得分:0)

这是一个很好的观点,我过去曾多次面对这个问题。

我用两种不同的方式解决了这个问题:

  1. 将统计信息/日志本地存储在服务器上,并从中央服务器收集。 优点:
    • 易于控制负载
    • 没有单点故障
    • 您在本地服务器上获得了一些备份空间
    • 每个游戏都可以向日志添加更多统计数据/数据,更容易添加此类数据
    • 本地磁盘写入是一种非常快速的操作,比RestApi更快。这里没有网络层。
    • 您可以控制中央服务器上的工作量
  2. 缺点:

    • 格式应该由所有不同的服务器满足
    • 如果一个游戏超级受欢迎,则扩大规模可能会有点问题
    • 您需要确保编写日志的文件都已同步
    • 使用中央服务器收集可能会在一台服务器上承担高工作量
    • 在高容量磁盘上始终具有最大容量(~600 I / O SaaS,5000 I / O SSD)

    2.RestAPI在中央服务器上,将处理所有stats.e.g每个游戏将通过API报告需要统计跟踪的事件。您还可以使用第三方事件记录器(Google Analytics事件)并通过API

    提取此报告

    优点:

    • 开发人员的简单集成
    • 轻松添加新功能
    • 使用应用扩展功能更加轻松。 API可以指向负载均衡器,该负载均衡器将指向多个 处理负载的服务器

    缺点:

    • 网络负载现已添加到服务器负载
    • 取决于网络延迟/停机时间
    • 依赖其他服务器加载游戏

    使用API​​实现非常简单,本地日志可能有点棘手。您需要分发日志格式。为日志创建一个已知文件夹,并为主服务器创建一个映射,以了解从哪里收集数据,然后将其解析为数据库。虽然听起来更复杂但我发现第一种方法非常有效,它帮助我降低了服务器成本。

    希望这有帮助..