web-services - 在Windows Azure中扩展REST API以处理数千个请求的合适方法

Question

我有一个 REST API，通过它我允许用户应用程序(azure 应用程序)将 perfmon 数据发送到我的数据库。现在为了对这个 REST API 进行负载测试，我构建了一个包含 500 个 WebRole 的模拟器应用程序，每个 WebRole 有 10 个实例(总共 5000 个实例)，并且每 1 分钟 50000 个(大约)请求 会将数据发布到 REST API因此我需要使用最佳实践来扩展我的 REST API 来处理如此大的负载。

以下是我扩展 REST API 的测试用例

中 - 6 个实例 => 可以处理 300 个实例的请求

超大 - 2 个实例 => 可处理 300 个实例的请求

现在我的问题是这种类型的负载可以通过水平缩放还是垂直缩放来处理？意味着我应该增加中型或小型实例的数量，还是必须使用超大尺寸的实例？

此外，此 REST API 将发布数据 SQL Azure 数据库(5 GB 网络版)，那么在处理请求方面是否有任何限制？

在上述情况下，所有应用程序都考虑在同一区域

Answer 1

您的 6 个中型实例 = 12 个核心，而 2 个 XL 实例 = 16 个核心。从价格角度来看，最好使用 6 个中号，而不是 2 个 XL。

此外，如果您动态扩展，使用 XL，您只能扩展 8 个核心，而使用中型，您可以扩展 2 个核心。我会使用中型实例，如果可能的话，即使是小型实例。并将目标是水平扩展(也称为横向扩展) - 增加/减少实例数量。

我还会考虑在发送到 SQL 之前对数据进行某种缓冲，而不是直接与 Windows Azure SQL 数据库 (WASD) 通信。对于这种类型的负载，很可能每秒对 WASD 的命中都会因负载过重而遇到 transient 错误。考虑将数据缓冲到队列(Azure 存储队列或 Azure 服务总线队列)中并具有辅助角色(可能具有多个实例)，批量处理队列消息。

这种类型的量表很可能在 CQRS 模式中 react 更快、更可靠。你可以看看CQRS Journey Project有关 CQRS 和 Windows Azure 的更多信息和引用实现。