管理工人的多个实例的架构？

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 处理传入请求有助于提高工作效率。您可以与服务和网络应用程序共享安全性。我更喜欢前端有IIS，后端有Windows服务。这样我就不必使用 Windows 服务来管理安全性。尝试使用 NServiceBus 作为内部队列https://github.com/NServiceBus/NServiceBus。我还没评价过。

Answer 2

你不能简单地将工作线程托管在服务中并使其成为多线程吗？ Wcf 只会把事情搞砸，因为您必须创建一个读取队列并调用服务的调度程序。通过让消费者作为服务工作，您也可以将其安装在多台计算机上，配置为从同一队列中读取，以便您可以垂直和水平扩展。我假设您正在使用

MSMQ

或其他类似的队列机制，如果没有，请考虑使用它。

Answer 3

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

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