用于赌场类型游戏的 Azure 架构 [关闭]答案

【问题标题】：Azure Architecture for Casino type game [closed]用于赌场类型游戏的 Azure 架构 [关闭]
【发布时间】：2014-05-28 13:46:20
【问题描述】：

我正在创建一个允许用户对事件进行投注的赌场类型游戏，并且我计划使用 Microsoft Azure 作为处理和数据存储（表格存储）的后端。我正在寻找有关如何验证信息并通知用户任何更新的任何想法。

理念： 该应用程序允许用户对事件下注，例如在线博彩公司（PaddyPower、Ladbrokes 等）。

工作流程：

情景（简化）：

过程：

解决方案 1 - 使用队列：当用户下注时，一条消息将被放入队列（所有用户使用）并由 Worker Role 处理。

如果下注对赛事来说太迟了，或者玩家最终赢得了赌注，则需要通知他们结果。

因此，每个活动用户都有自己的队列，客户端应用程序会轮询任何更新。这将允许客户端应用程序获取任何通知并将其显示给用户。

解决方案 2 - 使用 WCF 和队列：当用户下注时，他们会连接到 WCF 服务，它会进行事件开始检查，如果有任何问题，他们会立即收到通知。

将任何通知返回给用户的唯一方法是使用解决方案 1 中的 Queue 方法。

注意：

那么哪种解决方案是理想的，还是有更好的解决方案？

【问题讨论】：

可扩展性要求如何？有多少用户、事件、每秒最大投注数、每秒最大通知数、投注大小（xml？）...这可能会对您的设计决策产生影响。
@Herve 我实际上正在寻找允许根据您描述的参数进行缩放的最佳方法。但要回答您的问题 - 我希望 Azure 根据需要扩大和缩小工作人员角色。没有办法真正知道我可以获得多少用户，但我使用的是 10,000 DAU 的庞大数字。我看不出有超过 500 个赌注/秒。通知队列将每 1-2 秒从客户端轮询一次。此外，下注的大小将在队列的 64kb 以内。
要做出两个重要决定：一个与客户有关，另一个与下注时间所需的精度有关。如果客户端是电话或移动设备，我建议您使用服务 (WCF)，而不是将队列直接暴露给客户端应用程序。如果是网站，那么队列可能没问题。但是，在第二点上，如果您需要高水平的投注精确度，例如谁在何时下注，相对于其他更好的投注，这可能会影响投注池，例如，暂停可能比未处理的投注更好，因为队列处理延迟。

【解决方案1】：

我做的事情几乎和你一样。经过仔细考虑，我选择了以下内容：

SQL Azure / EF 模型。更容易使用和可扩展服务总线队列。带有工作人员角色的控制台应用程序的 VM。虽然我们将转移到工作人员或 Web 作业来执行此操作，但我们可以使用 VM 上的控制台应用程序和使用任务调度程序来快速监控和部署。

当我们做对了并且所有可能的异常等都消失了时，我们将转向可扩展的工作者角色或网络作业。

【讨论】：

【解决方案2】：

我建议您查看 CQRS 模式，尤其是本文档涵盖的参考实现的详细信息：CQRS Journey。

参考实现使用 Azure，我认为它非常适合您描述的系统。此外，它还提供了一种极具可扩展性和弹性的架构。

【讨论】：

【解决方案3】：

如果我是你，我会花时间计划如何设置 PartitionKey + RowKey 组合，以支持来自 Table Storage 的快速查询。只是因为从表中查询数据，尤其是没有 PartitionKey/RowKey 的情况下，比较慢。我学得很辛苦:)

【讨论】：

【解决方案4】：

新技术可能有点早，但可以考虑使用Orleans

哦，不要排除使用 SQL Azure 来获取您的用户信息……尤其是在涉及财务的情况下。 NOSQL 并不是持久性的全部和终结...

【讨论】：

【解决方案5】：

您的解决方案看起来不错，但是您可以考虑使用 SignalR 进行轮询，这将提高性能。三件事的结合也应该起作用 1. 网络角色 2. 工人角色 3. WCF 服务 - 自托管工作角色

使用 SignalR 很好，因为你永远不知道什么时候轮询，所以将此任务委托给服务器/角色

【讨论】：