使用Disruptor和Executor在Java中設計Orchestrator

Question

我們正在用Java設計一個Orchestrator系統，它將托管一個Web服務，並在請求時將調用以XML編寫的流，該流只是一個接一個地執行的步驟，但是XML告訴用戶該流是什么，他也可以通過更改XML來更改流程。 他可以添加新服務並將其添加到XML。 但是在設計時，我現在對類似的東西感到困惑。

1. 我是否應該使服務成為具有阻塞隊列的可運行服務，並通過將其調度到執行程序來使其始終處於活動狀態，所以當新請求到達時，我會將請求推送到阻塞隊列中，然后服務將對其進行處理。 並創建一個郵箱，它將承載不同服務之間的消息傳遞任務。

2. 而不是使服務可運行，我應該使用spring IOC，它將使類成為單例，因此那里只有一個實例，並且我將直接向服務方法發送請求，因此不會有麻煩，因為沒有線程並且不需要實現任何郵箱。

3. 我了解了像nodejs和ngnix這樣的事件驅動系統如何更快，因此我在考慮使用Disuptor框架將所有傳入請求推送到環形緩沖區，然后編寫一個將事件發送給協調器的處理程序，該處理程序將開始處理請求並還發送帶有請求的回調，以便協調器完成后，它將使用回調將響應發送回調用方。 但是由於請求的類型不同，所以我將無法利用中斷對象分配。

系統需要以低延遲提供最大的吞吐量，系統將來會向XML添加新的服務/流，因此它應該采用新的流而不會影響性能。 我被允許只使用Java 7，沒有Scala，所以我受到了限制。

Answer 1

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

答案2：如果建議的流程是“請求解析->調度->服務處理->回調”，則您依賴於實際的“服務”不會阻塞，因為這將阻止調用回調和/或使應用程序DOS。 本質上：如果服務中發生異常會怎樣？ 這還會影響將來對同一服務和/或其他服務的請求嗎？

同樣，並行的機會僅限於框架處理傳入請求的方式。 這意味着，如果您有X個請求，並且框架固有地按順序處理它們，則會積壓X個請求。 在這種情況下，您的延遲要求可能很難滿足。

答案3：事件驅動的系統確實是更好的方法：讓調度程序將作業分配給執行服務，以使系統動態分配所有服務的總負載，並具有對事件進行生成和響應的機制以處理事件。控制流。 如果服務數量變得非常大且每個“工作”相當合理（這樣，與實際執行的工作相比，調度/調度的開銷就很低），則這種方法的擴展性更好。