拓扑
ActiveMQ Classic 支持各种不同的部署拓扑，以及 协议 和线格式。下图显示了一个具有几种不同拓扑类型的代理的联合网络。
选择哪种拓扑取决于您。我们现在将更详细地描述其中一些协议。
在 VM 中
单元测试时一个有用的选项是将 JMS 通信限制在单个 JVM 内。为此，请使用以下协议
vm://127.0.0.1
您可以将 VM 协议分割到不同的组 - 例如，如果您想在同一个 JVM 内拥有逻辑上不同的 JMS 网络，您可以使用不同的 URI 对网络进行分组。例如
vm://127.0.0.1/foo
这将确保不同的段不会互相干扰。虽然通常我们使用唯一的主题和队列目标，以便所有流量可以愉快地共存于同一个逻辑网络上。
客户端-服务器
这可能是对大量需要从发布/订阅到基于队列的通信等各种通信选项的客户端来说最有效和最快的解决方案。通常情况下，客户端将使用协议（通常为 TCP 或 SSL，但也可以是 NIO 或其他协议）连接到消息代理。
我们可以跨代理负载均衡客户端，并提供代理故障转移，以便我们拥有具有 HA 的逻辑代理集群。
例如
tcp://somehost:port
或者对于 SSL
ssl://somehost:port
您可以使用 发现 来查找可供您连接的可用代理，这使得无缝连接到代理集群变得更加容易。
嵌入式代理
这在逻辑上等同于客户端-服务器，但一些（或所有）客户端包含一个本地嵌入式代理。因此，客户端和服务器（代理）之间的通信都在同一个 JVM 内，因此不会使用真正的网络 - 尽管代理可能会与连接到它的其他代理或客户端通信。
这可以避免从生产者到代理再到消费者的额外跳转 - 对于 RMI/RPC 类型的场景来说，这是一个很棒的优化，您希望获得点对点网络的性能优势（减少延迟），但同时又具有灵活的消息传递结构的可扩展性。
嵌入式代理还可以简化部署选项，因为它减少了一个需要运行的进程。
嵌入式代理的另一个用例是为每个服务提供存储转发隔离 - 这样远程代理可以毫无问题地故障，而不会影响带有嵌入式代理的服务。例如，整个网络都可能发生故障，但服务可以继续将其消息发布到其嵌入式代理。
您可以了解如何 在这里配置嵌入式代理
对等
这允许创建没有服务器的对等集群 - 只有客户端互相连接。
有多种方法可以实现对等 JMS 网络。一个简单的方法就是使用多播传输进行通信；然后同一个多播地址上的所有节点都会收到所有消息，本地嵌入式消息代理会将消息路由到必要的 MessageConsumers。
我们目前有 3 种多播协议选择
- 多播
- jgroups：使用 JGroups 库实现可靠的多播
- jrms：使用 Sun 的 JRMS 库实现可靠的多播
多播在开发中非常棒，尽管您通常可能想要在生产环境中禁用此功能，并将已知服务器固定在特定机器上。通常情况下，基于套接字的通信（使用点播）更快，并且更适合繁重的任务 - 特别是在 Java 上 - 所以我们倾向于建议主要将多播用于发现，并将 TCP/SSL 用于繁重的消息传递。
通常情况下，我们可以使用对等拓扑作为引导来创建客户端和代理的集群，然后自动将服务器部署到集群中，以形成真正的网格式网络。
因此，您可以使用 发现 以及独立代理或嵌入式代理来获得对等网络的效果。
JXTA
我们有一个 JXTA 传输，它将使用完整的 JXTA 堆栈来协商 NAT 和跨防火墙等等，从而创建真正的基于对等的 JMS 网络。
jxta://hostname:port
目前，您需要运行一台服务器，所有人都通过 JXTA 连接到该服务器。我们还没有创建使用 JXTA 的纯对等网络。
