使用破壞程序和執行程序在Java中設計Orchestrator

Question

我們正在設計一個java中的Orchestrator系統，它將託管一個Web服務，並根據請求調用一個用XML編寫的流程，這些流程只是一個接一個執行的步驟， XML告訴用戶流程是什麼，他也可以通過更改XML來改變流程。他可以添加一項新服務並將其添加到XML中。但是在設計時，我現在感到困惑於類似的東西。

1. 我應該做一個服務，一個阻塞隊列，可運行，並通過將其安排到執行，所以當新的請求到達時我會推入阻塞隊列請求保持它活着的時候，該服務將處理它。並創建一個郵箱，它將在不同的服務之間傳遞消息傳遞任務。

2. 而不是使服務可運行我應該使用春天國際奧委會，將使類單身，因此只有一個實例將在那裏，我會直接發送一個請求到服務方法，因此將不會有麻煩，我必須做因爲沒有線程，也不需要實現任何郵箱。

3. 我讀到了事件驅動系統如何像nodejs和ngnix一樣快，所以我正在考慮使用disuptor框架將所有傳入的請求推送到環緩衝區，然後編寫一個處理程序將事件發送到協調器，開始處理請求，併發送一個回調與請求，以便當編排器完成後，它將使用回調將回復發回給調用者。但由於請求的類型不同，所以我無法利用干擾對象分配。

系統需要提供最大吞吐量，低時延，系統將增加新的服務/流向XML在未來，所以應該採用新的流程沒有擊中性能。我被允許只使用Java 7，沒有Scala，所以我是有限的。

Answer 1

答案＃1是一個可怕的想法。您將有效地綁定每個服務的線程。如果服務數量超過了支持執行程序服務的線程數量，則您擁有即時自動DOS。另外，如果這些服務是相互依賴的......你可以鎖死所有的方式。另外，如果實際需要M（<N），則使用N個線程的效率低下。

解決方案2：如果提議的流程是請求解析 - >調度 - >服務處理 - >回調，那麼您依靠實際的'服務'不要玷污，因爲這會阻止回調被調用和/或DOS應用。基本上：如果服務中發生異常會發生什麼？這是否也會影響未來對相同服務和/或其他服務的請求？

此外，並行機會僅限於框架處理傳入請求的方式。這意味着如果你有X請求，並且框架固有地串行處理它們，你會得到X請求的積壓。在這種情況下，您的等待時間要求可能很難滿足。

答案＃3：一個事件驅動的系統確實是更好的方法：讓一個調度程序將作業排除在執行程序服務之外，以允許系統動態分配所有服務的總負載，並且具有生成和響應的機制事件來處理控制流。如果服務數量變得非常大並且每個「工作」相當可觀（因此調度/調度的開銷與正在執行的實際工作相比較低），則這可以更好地擴展。