云服务API架构设计

Question

背景：

我有一个本地应用程序，它处理用户输入 3 秒（大约），然后将答案（输出）返回给用户。

（我不想详细介绍我的应用程序，以免使问题复杂化并使其成为纯粹的架构问题）

我的目标：

我想让我的应用程序成为云中的服务并公开 API （适用于即将推出的网站以及无需在本地安装软件即可连接服务的客户）

可能的解决方案：

1. 在云上部署 WCF 并在那里使用我的应用程序，因此客户端可以调用服务并在云上使用我的应用程序。 （RPC 风格）
2. 使用 Web-API 将请求插入队列，然后工作角色将请求出列并将结果发布到数据库，因此客户端将发送一个请求以在队列中创建请求，并发送另一个请求获取结果（Web-API 将从数据库中获取）。

问题：

• 如果我使用 WCF 解决方案 (#1)，我将无法处理大量请求，可能同时处理 10-20 个请求。
• 如果我使用 WebAPI-Queue-WorkerRole 解决方案 (#2)，有时客户端需要多次请求结果，这可能是个问题。
• 如果我使用 WebAPI-Queue-WorkerRole 解决方案 (#2) 过程不同步，客户端一旦请求处理完成就不会得到结果，他需要请求结果。李>

问题：

1. 在 WebAPI-Queue-WorkerRole 解决方案 (#2) 中，我可以在客户端的请求处理完成后以某种方式提醒他吗？所以我可以保存客户端的多个请求（对于结果）。

2. 多次询问结果不是老东西吗？我记得 10 到 15 年前它被接受了，但现在呢？我知道VirusTotal API 使用这种设计。

3. 有更好的解决方案吗？一个可以处理大量负载并且是同步或异步的（完成后将结果返回给客户端）？

谢谢。

Answer 1

如果您使用的是 Azure，为什么不简单地启动更多服务器并使用负载平衡来处理更多负载？这样一来，随着负载的增加，您就有更多的服务器来处理请求。

Microsoft 最近推出了 Azure Service Fabric，让您可以对启动和关闭这些服务进行大量控制。