用于管理工作者的多个实例的体系结构？

Question

我应该选择什么样的架构？有一个工作进程将消息从队列中取出并逐个处理。现在我可以让很多Windows服务实例完成这项工作，或者我可以将一个WCF服务作为Windows服务托管，作为某种服务器，我可以为每个实例启动一个线程。

哪种方法会更好地扩展？当我们谈论基于云的基础设施（其中扩展速度非常快）以及非基于云的基础设施时，我想要观点。

Answer 1

云中最具扩展性的方法是使用WCF或Web-api配置处理服务的实例（如果您正在设计RESTFUL服务，则更可取）。这样的实例是可扩展的。如果是Azure，请将此视为使用IIS托管的Web角色。 IIS旨在与来自客户端的传入请求进行扩展。另一个优点是您可以使用IIS和asp.net基础架构来管理安全性和其他内容。但是，如果您不需要使用Windows服务托管的WCF或Web-api服务。然后，Web服务实例将对消息进行排队或将工作加载到队列中。对于Azure，队列可以是服务总线队列。然后，您可以使用Windows服务或Azure辅助角色从队列中提取工作项。通常，单个工作程序从队列中提取多个消息并对其进行处理。这样做时，其他工作人员无法获得这些消息。完成工作后，从队列中删除消息或工作负载。因为在一段时间之后，其他工作人员可以看到有可见性的设置，例如在亚马逊SQS中有可见性超时设置。 *在一个工作程序中拉5到10条消息，并将它们作为线程池线程并行运行作为“任务”。

请注意，前端具有可伸缩服务实例的体系结构，在后端接收传入请求和工作者角色，尽快清除工作项，这取决于云提供的分布式，健壮且可伸缩的队列，如Azure服务总线和亚马逊SQS。否则您可能会遇到争用问题。

对于内部（非云）部署，通常如果没有分布式队列，这里可以让IIS托管服务实例执行所有操作，或者Windows服务执行所有操作或组合。我建议使用IIS托管HTTP服务来提供网页并接收传入请求（REST服务）。 IIS很好用。但是，如果长时间没有请求，IIS池可以被回收，并且可能无法运行。因此，如果需要运行计划任务或作业后端的Windows服务是擅长的。让Windows服务做所有事情当然是可行的，但根据我使用IIS和asp.net传入请求的经验有助于提高工作效率。您可以与服务和Web应用程序共享安全性。我更喜欢在前端安装IIS，在后端安装Windows服务。有了这个，我不必用Windows服务来管理安全性。尝试NServiceBus用于内部队列https://github.com/NServiceBus/NServiceBus。我还没评价过。

Answer 2

难道您不能简单地将服务器托管在服务中并使其成为多线程吗？ 因为你必须创建一个读取队列并调用服务的调度程序，所以Wcf只是弄乱了。让消费者作为服务工作，您也可以将其安装在多台机器上，配置为从同一队列读取，以便您可以纵向和横向扩展。我假设您正在使用MSMQ或其他类似的队列机制，如果没有，请考虑使用它。

Answer 3

我会在单线程Windows服务中托管每个worker。这有以下好处：

1. 易于编码和测试（无多线程）。
2. 轻量级
3. Dispatcher没有必要 - 工人将在没有干预的情况下实现负载平衡。
4. 易于部署/管理。如果工人出现问题，只需重新启动服务。