版本 5 拓撲

ActiveMQ Classic 支援廣泛的不同部署拓撲，以及協定和線路格式。下圖顯示了一個具有幾種不同拓撲的聯合代理網路。

您選擇哪種拓撲取決於您。我們現在將更詳細地描述其中一些協定。

在 VM 中

當進行單元測試時，一個有用的選項是將 JMS 通訊限制在單個 JVM 內。為此，請使用協定

vm://127.0.0.1

您可以將 VM 協定分段為不同的組 - 例如，如果您想在同一個 JVM 內擁有邏輯上不同的 JMS 網路，您可以使用不同的 URI 對網路進行分組。例如：

vm://127.0.0.1/foo

這將確保不同的分段不會相互干擾。雖然我們通常使用唯一的主題和佇列目的地，以便所有流量都可以在同一個邏輯網路上愉快地共存。

對於需要從發布/訂閱到基於佇列的通訊等各種通訊選項的大量客戶端來說，這可能是最有效和最快的解決方案。通常，客戶端將使用協定（通常是 TCP 或 SSL，但也可能是 NIO 或其他協定）連接到訊息代理。

我們可以跨代理負載平衡客戶端，並提供代理容錯移轉，以便我們擁有一個具有高可用性的邏輯代理叢集。

例如：

tcp://somehost:port

或者對於 SSL：

ssl://somehost:port

您可以使用探索來尋找可連接的可用代理，這使得可以更輕鬆地無縫連接到代理叢集。

這在邏輯上等同於客戶端-伺服器，但某些（或所有）客戶端包含一個本地嵌入的代理。因此，客戶端和伺服器（代理）之間的通訊都在同一個 JVM 內，因此不使用實際的網路 - 儘管代理可能會與其他代理或連接到它的客戶端進行通訊。

這可以避免從生產者到代理再到消費者的額外躍點 - 這對於 RMI/RPC 樣式的情況來說是一個很好的優化，在這些情況下，您需要點對點網路的效能優勢（降低延遲），但同時需要靈活訊息傳遞結構的可擴展性。

嵌入式代理也可以簡化部署選項，因為它少了一個要執行的程序。

嵌入式代理的另一個用例是提供每個服務的儲存和轉發隔離 - 以便遠端代理可以正常失敗，而不會影響具有嵌入式代理的服務。例如，整個網路可能會失敗，但服務可以繼續將訊息發布到其嵌入式代理。

這允許建立基於對等的叢集，其中沒有伺服器 - 只有客戶端連接在一起。
有許多方法可以實作點對點 JMS 網路。一種簡單的方法是僅使用多播傳輸進行通訊；然後，同一多播位址上的所有節點都將接收到所有訊息，並且本地嵌入的訊息代理會將訊息路由到必要的 MessageConsumers。

我們目前有 3 種多播協定的選擇

多播在開發中非常好用，但通常您可能希望在生產環境中禁用此功能，並讓已知的伺服器固定在特定機器上。通常，基於套接字的通訊（使用點播）速度更快，並且更適合高負載 - 特別是在 Java 上 - 因此我們傾向於建議主要使用多播進行探索，並使用 TCP/SSL 進行繁重的訊息傳遞。

通常，我們可以將點對點拓撲用作引導，以建立客戶端和代理的叢集，然後將伺服器自動部署到叢集中，以實現真正的網格樣式網路。

因此，您可以使用探索以及獨立的代理或嵌入式代理來獲得基於對等的網路效果。

我們有一個 JXTA 傳輸，它將使用完整的 JXTA 堆疊來協商 NAT 並跨越防火牆等等，以建立真正的基於對等的 JMS 網路。

jxta://hostname:port

目前，您需要執行一個伺服器，所有人都通過 JXTA 連接到該伺服器。我們尚未建立一個純粹的基於對等的 JXTA 網路