我公司目前使用基于Windows的胖客户端应用程序为其客户提供服务，该应用程序中嵌入了工作流程处理。基本上，客户将一组文档插入到工作流的开头，通过许多工作流程步骤处理文档，然后在一段时间之后将输出呈现给客户。我们目前通过在其他计算机上安装应用程序来扩展大客户，并让机器集群在不同的文档子集上工作。虽然不是很理想，但只需对应用程序进行最小的更改，它就可以轻松扩展到我们当前的级别。
我们现在面临的问题是，随着我们的客户为我们提供了更大的文档集，我们发现自己在机器，IT支持等方面的支出超过了预期...因此，我们开始考虑重新构建平台使其可扩展。我们的解决方案的一个特点是每个文档可以彼此独立地处理。我们还有10个工作流程步骤，其中两个步骤占用了大约90％的处理时间。
我们正在考虑的一个想法是向文档架构添加工作流步骤字段，以跟踪文档已完成的工作流步骤。然后，我们可以抛出整个机器集群来处理单个文档集。单个机器不负责通过所有工作流程步骤顺序处理文档，但查询数据库以查找下一个文档/工作流程步骤对并执行该处理。这听起来像是一种合理的方法吗？有什么建议吗？
提前致谢。
答案 0 :(得分：1)
虽然我不确定您正在使用的具体开发环境，但我不得不处理一些类似的工作流程，其中我们有不同数量的源文档，各种步骤等，所有这些都具有不同的性能特征。
假设您有一系列独立的步骤 - 即步骤A的工作产品是步骤B的输入，步骤B的产品是步骤C的输入，等等。我会将消息排队视为潜在的解决方案。
例如，所有新文档都被放入队列中。一个或多个侦听器应用程序到达队列并获取下一个可用文档以执行步骤A.当步骤A完成时，将输出产品和/或相关数据的链接扔到另一个队列中。一个单独的监听器应用程序从第二个队列拉入步骤B等，直到创建最终输出产品。
通过这种方式，您可以在每个谨慎步骤之间使用一个队列作为保留区域，并且可以在队列之间向上或向下扩展任何单个进程。
例如，我们使用它来从一些数据转换，到渲染过程，再到假脱机程序。数据速度快，渲染是CPU绑定的，打印是I / O绑定的，但每个步骤都可以根据需要进行扩展。
您可以（技术上）使用数据库 - 但是消息队列和/或服务总线可能会更好地为您服务。
希望能指出你正确的方向！