我認爲你想擺脫JMS,因爲管理很多隊列中的很多消息並不像你想要的那麼「輕量級」......而且你的代碼庫正在增長!
- 您經常監視許多隊列以查看問題或瓶頸。
- 如果其中一個外部系統關閉了一段時間,則會發出很多調用並失敗,並且所有消息都會進入錯誤隊列。
- 如果您想了解單個「工作流程」實例發生的情況,請查看日誌文件。
- 如果你想看到工作流程從頭到尾,你將不得不求助於手寫文檔(這並不總是準確的)。
- 如果您添加或刪除一個步驟,則必須查找並更新所有導致該步驟的步驟,儘管它們沒有更改。
- 在部署新版本之前,您需要等待舊版本的作業運行到最終狀態。
雖然你的JMS解決方案滿足他們,都需要考慮新的解決方案更多的非功能性需求:可擴展性,可靠性等所有的一切,這些都是滿足......與嚴格要求任何技術。
也許你可以考慮不同的區域,其中「輕量」是最重要的是你:
- 可以測試普通的業務邏輯部分,而無需啓動整個框架?即與框架耦合的業務邏輯有多強烈?
- 學習編程和操作系統有多困難?找到已經知道的人有多難?
- 你可以從舊系統遷移到新的一步或只是在一個大爆炸?
在這個領域有很多解決方案,但他們都不是一個一站式的解決所有問題的解決方案。一些是面向批處理的(比如Spring Batch或Java Batch),其他則是面向消息的(比如Akka或Hystrix)。比較它們本身就是一門科學。有這麼多的力量或agains它們,你就不會在這裏得到一個完美的答案,即使你提供了很多細節,比如高峯的任務數,步數,外部系統調用號,等我」我一次又一次地看到它:如果您完全瞭解業務工作流程,可以更輕鬆地替換技術......所以這是一個先決條件。
然後,我建議你玩不同的解決方案(如果你有時間),還是留你在哪裏......這可能還不是最壞的所有可能的解決方案。不...我真的意味着:不要實現另一個「輕量級」的東西,你可以打賭,會不會很「輕量級」更快超乎你的想象。
最後一兩件事:我分享傳統BPM框架,即BPEL和朋友你的感受。但是還有像Camunda BPM這樣的輕量級和開源框架值得一看。