.net - 管理多个工作人员实例的架构？

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

我会将每个工作人员托管在一个单线程 Windows 服务中。这有以下好处：

1. 易于编码和测试（无多线程）。
2. 轻的
3. 不需要调度程序- 工作人员将在没有干预的情况下进行负载平衡。
4. 易于部署/管理。如果工人有问题，只需重新启动服务。

Answer 3

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