關於這個用例的體系結構/設計的一些問題？

Question

我的應用程序需要作爲中間件工作，它已經從包含供應商ID的各種 客戶那裏獲得訂單（以xml的形式）。一旦獲得訂單，它需要以xml.i的形式向不同的供應商發送訂單請求 關於它的三個方面。在這裏，他們是： -

問題：

1. 什麼，我計劃在高級別就要求而來的是，把它放在JMS隊列（現在我不知道 ，我應該爲創建隊列。每個供應商或一個隊列應該是足夠的，我認爲一個隊列就足夠了，因爲保持大量的隊列將被開銷。每個供應商維護獨立隊列的好處是可以更快地處理消息，因爲每個隊列上都會有獨立的生產者。

2. 在將對象放入隊列之前 我需要做一些業務驗證。另外我輸入XML的結構我接收和輸出XML我需要發送給供應商是不同的。爲此，我計劃將輸入的xml轉換爲java對象，然後放在隊列 上，以便在消費者一側輕鬆進行驗證。另一個想法是不要將xml轉換爲java對象，只需通過xpath/xstream api獲取所有元素 的值並驗證它們並將xml字符串放在隊列中，因爲它在隊列中。然後在消費者端將xml轉換爲java對象，然後轉換爲不同的xml格式。有沒有辦法呢？

3. 現在我的要求是隊列中的消費者每5小時處理一次隊列中的消息，並將xml請求 發送給供應商。我打算在這裏使用石英調度程序，它將逐個選擇工作，並根據supplierId發送給相應的供應商 。這裏是我的問題，如果我的工作一個接一個地選擇信息，然後發送給供應商。 它會太慢。我打算處理它在哪裏石英作業創建ThreadPool的大小說10線程的時間 併發處理隊列中的消息（所以這裏將在隊列中的多個消費者。我認爲這對隊列無效。我是否需要在這裏的話題而不是隊列？）。第二種方法是更好還是有一些比這更好？

我期待50K要求的每小時這意味着每秒

Answer 1

你的基本要求是，從以客戶爲XML

1. 獲取訂單（你有沒有告訴你如何接收）
2. 做基本的業務驗證。
3. 發送訂單給供應商

而且你會50K除外請求（您沒有提供近似的訂單大小）。 假設您的平均訂單大小爲10K，只需將其保留在隊列中即可（大約需要500 MB）（不考慮隊列數量）。我不確定你正在運行哪個環境。

對於點＃1 我會選擇單個隊列而不是多個隊列 - 選擇合適的持久性存儲。 我假設您將使用分佈式隊列，以便在添加羣集時輕鬆進行擴展。

對於點＃2 我將轉換爲POJO（您自己的格式）並執行業務驗證。因此，如果您希望將業務驗證延伸到標尺或任何其他轉換，那麼以後將很容易維護。 - 基本上以任何形式獲取輸入（XML/POJO/JSON ...）並將其轉換爲中間格式（您可以在Middle fomart之上編寫客戶驗證器/轉換實用程序）。並且在通用格式之間保留映射以及輸出。這樣你可以編寫格式化程序並使用它們。在改變任何特定供應商的格式時，這不會影響未來。嘗試外部化格式映射。

對於點＃3 在您的情況下，訂單隻需要處理一次。所以我會和Queue一起去。並且您可以擁有多個Message Listener。消息偵聽器以異步方式傳遞訂單。所以你可以有一個隊列的多個監聽器。每個聽衆都會運行獨立的線程。 收到訂單後是否有問題？對您和供應商來說，在特定的時間避免重負荷會有好處。

Answer 2

既然你是中間件，你應該在接觸點進行快速的數據，讓你的手免費大約15請求的負載爲更多傳入的請求。因此，您必須找到一種方法將傳入數據儘可能快地分配爲低內存。將數據處理留給更具體的問題模塊。接待員只是指導客人在正確的位置。

如果您確實必須在以後閱讀並理解專業工作人員收到的數據，請使用線程池。通過這種方式，您可以並行處理數據，而不必擔心過多。只要巧妙地選擇你的游泳池大小，只使用一個。您可以使用偵聽程序模式將新傳入數據發送給worker多字節。如果可能的話，您應該避免使用jaxb或更好地完成數據的完全反序列化。它像地獄一樣吞噬記憶。

我不會使用jmx，因爲您的「消息」僅與一個偵聽器相關。

如果可以在工作完成後馬上發送郵件。如果沒有，請使用存儲。這樣，您可以稍後再處理數據，如果出現問題或者您必須更新軟件，則不必擔心易失數據。