將胖客戶端應用程序重新設計爲分佈式工作流程

Question

我的公司目前使用基於Windows的胖客戶端應用程序爲其客戶端提供服務，該應用程序中嵌入了工作流程處理。基本上，客戶在工作流開始時插入一組文檔，通過多個工作流程步驟處理文檔，然後在一段時間後將輸出呈現給客戶。我們目前通過在其他機器上安裝應用程序來擴大更大的客戶範圍，並讓機器集羣在不同的文檔子集上工作。雖然不理想，但只需對應用程序進行微小的更改，便可輕鬆擴展至目前的水平。

我們現在面臨的問題是，隨着我們的客戶向我們提供了更大的文檔集，我們發現自己在機器，IT支持等方面花費超過預期......因此，我們開始考慮重新設計平臺使其具有可擴展性。我們解決方案的一個特點是每個文檔都可以獨立處理。我們還有10個工作流步驟，其中兩個步驟佔用了大約90％的處理時間。

我們正在研究的一個想法是向文檔模式添加一個工作流程步驟字段，以跟蹤文檔的完成工作流程步驟。然後，我們可以將整個機器集羣投入到單個文檔集中。單個機器不負責通過所有工作流程步驟順序處理文檔，而是查詢數據庫以獲取下一個文檔/工作流程步驟對，並執行該處理。這聽起來像一個合理的方法？有什麼建議麼？

在此先感謝。

Answer 1

雖然我不知道具體是什麼開發環境，您正在使用，我不得不應付，我們有源文件，各個步驟，等等都具有不同的性能特徵的數目不同的一些類似的工作流程。

假設你有一系列獨立的步驟 - 即步驟A的工作產品是步驟B的輸入，而步驟B的產品是步驟C的輸入等，我會將消息排隊看作潛在的解決方案。

例如，所有新文檔都被放入隊列中。一個或多個監聽器應用程序進入隊列並抓取下一個可用文檔以執行步驟A.當步驟A完成時，輸出產品和/或相關數據的鏈接將被放入另一個隊列中。一個單獨的偵聽器應用程序從第二個隊列拉入步驟B等，直到創建最終輸出產品。

通過這種方式，您可以使用一個隊列每個謹慎一步之間的保持區域，並且可以放大或縮小隊列之間的任何個人的過程。

例如，我們使用它從一些數據轉換，渲染過程轉到假脫機程序。數據快，效果是CPU約束，並且印刷是I/O綁定，但是每個單獨的步驟可根據需要進行擴展。

你可以（在技術上）使用DB的 - 但一個消息隊列和/或服務總線可能會更好地爲您服務。

希望你能朝正確的方向發展！