單個EAR？還是多個EAR？

Question

我們正在開發基於JavaEE 6的應用程序以部署在JBoss EAP 6.1上。該應用程序有兩個主要的演示機制：一個Web管理控制檯和一個RESTful服務API。在後端，管理控制檯和RESTful服務API都依靠一系列EJB來執行事務邏輯和POJO服務來檢索數據。

完全有可能所有這些不同層的性能和資源需求可能不同。 RESTful服務相當簡單且完全無狀態，而管理控制檯是有狀態的，具有更多的交互功能（因此需要更多的內存和處理）。由於我們的EJB執行我們的主要事務性業務邏輯，因此它們需要比僅僅查詢數據庫的POJO數據服務更強大的處理能力。

考慮到這樣的設置，在所有這些組件中部署單個EAR（在多個集羣配置中的應用程序中），還是將各個組件分解爲單獨的EAR更合理？我認爲使用單獨的EAR是因爲，例如，如果我發現它們存在可伸縮性問題，即使Web控制檯（例如）可以擴展得很好，我也可以部署更多的EJB服務實例。

鑑於每個層/組件的可伸縮性都不相同，我應該採取什麼方法？不得不在EAR上進行遠程EJB調用的開銷太高而無法考慮這種模型？任何意見是極大的讚賞！

Answer 1

「Java EE」的方式是將應用程序部署爲集羣上的單個EAR。我假設你正在使用從REST /管理控制檯到EJB-s的本地接口調用。如果你不需要會話複製（你可以使用粘性會話），那麼部署將很簡單，那麼可伸縮性將會非常好。

您將需要的唯一額外元素是Web應用程序的負載平衡器（例如，Apache服務器，該服務器還負責SSL解碼，靜態資源服務以及可能緩存的緩存請求）。

這種設置的唯一問題可能出現在負載較重的情況下，例如EJB可能會佔用大量的服務器資源，所以Web應用程序的吞吐量將難以控制，並且會受到EJB的嚴重影響。如果您使用粘性會話，則用戶總是被重定向到同一臺服務器，因此只要用戶會話持續，沒有機會將某些用戶移動到裝載較少的服務器。因此，如果您計劃使用高負載，那麼將Web應用程序和EJB保留在單獨的盒子（或虛擬機）上是有意義的，因此可以更容易地識別瓶頸，並且更容易擴展需要的那一層。

對於這樣做的代價是：

1. 到EJB的遠程調用。然而，JBoss 6擁有相當先進的EJB池配置，所以它可能不是一個如此可怕的問題。
2. 這些遠程調用導致的網絡流量（所以如果你在EJB和web層之間傳遞大量數據，這可能是一個問題）。

Answer 2

爲支持彼得的偉大評論：

現在都捆綁在一起，並拆分只有如果確實需要在未來出現。

考慮Martin Fowler的First Law of Distributed Object Design: Don’t distribute your objects!作爲一個很好的指導方針 - 如果你打算打破它，至少有意識地和真正的業務需求。