将胖客户端应用程序重新设计为分布式工作流

Question

我的公司目前使用基于 Windows 的胖客户端应用程序为他们的客户提供服务，该应用程序嵌入了工作流处理。基本上，客户将一组文档插入到工作流的开头，这些文档通过多个工作流步骤进行处理，然后在一段时间后将输出呈现给客户。我们目前通过在其他机器上安装应用程序并让机器集群在不同的文档子集上工作来为更大的客户扩展。不理想，但对应用程序的改动很小，它确实让我们能够轻松地扩展到我们当前的水平。

我们现在面临的问题是，随着我们的客户向我们提供了更大的文档集，我们发现自己在机器、IT 支持等方面的支出超出了预期......因此，我们开始考虑重新构建平台使其可扩展。我们解决方案的一个特点是每个文档都可以相互独立地处理。此外，我们还有 10 个工作流程步骤，其中两个步骤占用了大约 90% 的处理时间。

我们正在考虑的一个想法是在文档架构中添加一个工作流步骤字段，以跟踪为文档完成了哪个工作流步骤。然后，我们可以让整个机器集群处理单个文档集。单台机器将不负责通过所有工作流程步骤按顺序处理文档，而是在数据库中查询下一个文档/工作流程步骤对并执行该处理。这听起来像一个合理的方法吗？有什么建议吗？

提前致谢。

Answer 1

虽然我不确定您使用的是什么特定的开发环境，但我不得不处理一些类似的工作流程，其中我们有不同数量的源文档、不同的步骤等，所有这些都具有不同的性能特征。

假设您有一系列独立的步骤 - 即步骤 A 的工作产品是步骤 B 的输入，步骤 B 的产品是步骤 C 的输入，等等。我将消息队列视为一种潜在的解决方案。

例如，所有新文档都被放入队列中。一个或多个侦听器应用程序进入队列并获取下一个可用文档以执行步骤 A。随着步骤 A 的完成，指向输出产品和/或相关数据的链接被扔到另一个队列中。一个单独的侦听器应用程序从第二个队列拉到步骤 B 等，直到创建最终输出产品。

通过这种方式，您可以在每个谨慎步骤之间使用一个队列作为等待区域，并且可以在队列之间放大或缩小任何单个进程。

例如，我们使用它来完成一些数据转换，通过渲染过程，然后输出到假脱机程序。数据速度快，渲染受 CPU 限制，打印受 I/O 限制，但每个单独的步骤都可以根据需要进行扩展。

您可以（技术上）为此使用数据库 - 但消息队列和/或服务总线可能会更好地为您服务。

希望这会为您指明正确的方向！