云服务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，为什么不简单地启动更多服务器并使用负载平衡来处理更多负载？这样，随着负载的增加，您有更多的服务器来处理请求。

微软最近推出了Azure Service Fabric，它可以让您对旋转和关闭这些服务进行大量控制。