Azure 可扩展架构设计答案

【问题标题】：Azure scalable architecture designAzure 可扩展架构设计
【发布时间】：2015-03-06 02:22:41
【问题描述】：

我需要为服务设计一个 AZURE 架构。一些关键特性：

用户负载可以达到每秒 50K 请求
架构应该是可扩展的
该服务需要实时用户通知
某些请求必须排队，因为对特定调用有限制（用户应该知道操作正在等待处理）
全球可用性

我的第一个想法是：

MVC 作为客户端入口点（天蓝色网站）
WEB API 作为后端（天蓝色网站）
服务总线（用于请求排队）
Web 作业（排队请求的工作人员）
用于数据存储的 Azure DB
用于实时通知的 SignalR 中心
Azure 流量管理器

您对以上内容有何看法？有什么建议/最佳实践可以使这个高度可扩展和可用吗？

【问题讨论】：

如果您确实每秒有那么多请求，您应该查看事件中心。它们专为可以处理更高负载的物联网场景而设计

标签： azure asp.net-web-api signalr azureservicebus

【解决方案1】：

首先，只是为了确保：每秒 50k 个请求？你确定那不是 50k 并发用户之类的吗？ 50k/秒接近 Twitter 音量。每秒大约 1/10 的 Google 请求量 - 这是巨大的。
50k 并发用户通常转化为 500-600 个请求/秒（假设每 15 分钟用户会话有 10 个页面浏览量）

现在，关于您的问题：我会重新考虑将 Azure 服务总线用于如此大容量的系统，并考虑使用事件中心（正如 Panagiotis 指出的那样），或者坚持使用更简单但更具可扩展性的 Azure 存储队列来进行消息传递。您需要设计一个队列策略，通过该策略将消息分散到多个队列中，以免使位于单个存储分区中的单个队列溢出。

我还会考虑使用 Azure Web 角色而不是 Azure 网站来托管 IIS 并运行队列处理。网站仅限于每个负载平衡端点 10 个服务器。核心数量也有限制。对于 50k/sec 的请求，您将需要相当大的马力来运行队列和服务流量，而 10 台服务器可能还不够。

您指的是哪个 Azure DB？ Azure 文档数据库？ SQL Azure 数据库？

【讨论】：

实际上，这就是事件中心卷。这不是物联网场景的大量事件。以非常粗略的方式，事件中心按照您建议的方式工作：它们接收事件并将它们转发给工作人员进行处理。比使用队列、worker 和配置自动缩放来处理负载变化手动编写类似的基础架构要好得多。
同意事件中心
我肯定会避开该数量的 Azure 网站，而是使用 Roles/CloudServices 运行。这可能是您开发降压的最佳选择：规模（并且您仍然可以使用 WebApi/mvc，我个人觉得这些天比 WCF 更有品味:)）。您可以考虑将有意排队的请求放入表中，而不是并排队列。您将在如何管理请求的优先级和折叠方面获得更大的灵活性。
我指的是 SQL Azure DB。 50k / s 可能有点夸张，但我正在尽我所能做好准备。关于服务总线与事件中心 - 我必须测试哪个对我更好。您对信号 r 有什么建议吗？是否有任何替代方法可以存储离线通知？我在原来的帖子中犯了一个错误：WEB API 作为后端（天蓝色的网站）——事实上，Web API 是作为云服务托管的。您如何看待网络工作？我可以上传它们的多个实例并使它们成为多线程...