我們有一個基於JMS的消息應用程序，每天處理大約200萬條消息。JMS體系結構 - 平衡設計原則與體積
現在我們還有一項額外的功能將啓動，影響總消息的60％，即每天120萬條消息。 該計劃是有一個內部隊列上，我們將轉發該消息該附加特徵
認爲到目前爲止，2個設計方案是：
一）轉發所有郵件到第2個隊列在其上消息驅動的bean（MDB）將處理它們 - 這將第一個應用程序與根本不需要此功能的應用程序隔離開來。
b）在原始應用程序，篩選出只有60升％的體積並轉發給必要的隊列 - 從而減少不必要的交通內部
所以基本上平衡設計VS冊 - 哪種方式shuld我們去哪裏？
備選案例B.未來可能會給您帶來前景。在兩個業務應用程序中保持這樣的過濾邏輯幾乎不是一個好主意 - 考慮未來對過濾規則的更改會觸發兩個應用程序的新版本。
1.2M信息/天是一個相當多的數字，如果消息不是微小的。如果系統可以處理數量，那麼解決方案A）是構建和處理時間最簡單的方法。我會做一些負載測試，如果一切正常，請繼續b）。
根據您正在構建的plattform等等，許多中間件和消息傳遞產品提供了可應用於中間件而不是實際應用中的邏輯和過濾功能。
[First Queue] -> Middleware, Copy All -> [Orig Appl. input queue]
, Filter -> [New application input queue]
例如，這可以很容易地通過Apache Camel在幾行XML中配置。