我应该选择什么架构？有一个工作进程从队列中取出消息并逐一进行处理。现在，我可以让许多 Windows 服务实例完成这项工作，或者我可以将一个 WCF 服务作为 Windows 服务托管，充当某种服务器，在该服务器上我可以为每个实例启动一个线程。
哪种方法可以更好地扩展？当我们谈论扩展速度非常快的云基础设施以及非基于云的基础设施时，我想要一些观点。
最佳答案
云中最具可扩展性的方法是配置一个实例，使用 WCF 或 Web-api 处理服务(如果您正在设计 RESTFUL 服务，则更佳)。这样的实例是可扩展的。如果是 Azure，请将其视为由 IIS 托管的 Web 角色。 IIS 旨在根据来自客户端的传入请求进行扩展。另一个优点是您可以使用 IIS 和 asp.net 基础架构来管理安全性和其他内容。但是，如果您不需要，请使用 Windows 服务托管的 WCF 或 Web-api 服务。然后，Web 服务实例会将消息排队或将工作加载到队列中。对于 Azure，队列可以是服务总线队列。然后，您可以使用 Windows 服务或 Azure 辅助角色从队列中提取工作项。通常，单个工作人员从队列中提取多条消息并对其进行处理。这样做时，其他工作人员无法获取这些消息。工作人员完成后，从队列中删除消息或工作负载。因为一段时间后，其他工作人员将可以看到它们，因此有可见性设置，例如在亚马逊 SQS 中，有可见性超时设置。 *在单个工作线程中拉取 5 到 10 条消息，并将它们作为线程池线程作为“任务”并行运行。
请注意，前端具有可扩展服务实例、接收传入请求和后端辅助角色尽快清除工作项的架构依赖于云提供的分布式、健壮且可扩展的队列，例如 Azure服务总线和 Amazon SQS。否则你可能会遇到争用问题。
对于内部(非云)部署，如果没有分布式队列，通常可以在此处让 IIS 托管服务实例执行所有操作，或者让 Windows 服务执行所有操作或组合。我建议使用 IIS 托管 HTTP 服务来提供网页服务并接收传入请求(REST 服务)。 IIS 在这方面很擅长。但是，如果长时间没有请求，IIS 池可能会被回收，并且可能无法运行。因此，如果需要在后端运行计划任务或作业，Windows 服务就很适合这样做。让 Windows 服务来做所有事情当然是可行的，但根据我的经验，使用 IIS 和 asp.net 处理传入请求有助于提高工作效率。您可以与服务和网络应用程序共享安全性。我更喜欢前端有IIS，后端有Windows服务。这样我就不必使用 Windows 服务来管理安全性。尝试使用 NServiceBus 进行内部队列 https://github.com/NServiceBus/NServiceBus 。我没有评价过。
关于.net - 管理 worker 的多个实例的架构？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/13244604/