4.5.1静态网络

第一种配置和连接代理网络的方法时通过使用静态配置的URI--配置一个可连接的代理URI列表。唯一的先决条件是你要知道你想使用的所有代理的地址。一旦你有了这些地址，你需要知道如何在配置中使用它们。所以让我们看看建立静态代理网络的可用连接器。
静态连接器
静态连接器被用来在一个网络中建立一个多个代理的静态配置。该协议使用了一个组合URI--一个包含其它URI的URI。一个组合URI包含多个在网络连接另外一端的代理地址或URI。
这里是静态协议的URI语法：
static:(uri1,uri2,uri3,...)?key=value
你能在ActiveMQ网站(http://mng.bz/r74v)上找到该传输的完整的说明文档。
现在看一下下面的配置示例：
<networkConnectors>
  <networkConnector name="local network"
    uri="static://(tcp://remotehost1:61616,tcp://remotehost2:61616)"/>
</networkConnectors>
假设这个配置是在localhost上的代理的并且在remotehost1和remotehost2上的代理起了并运行了，当你启动本地代理的时候你将注意到下面的信息：
...
INFO DiscoveryNetworkConnector - Establishing network connection between
from vm://localhost to tcp://remotehost1:61616
INFO TransportConnector - Connector vm://localhost Started
INFO DiscoveryNetworkConnector - Establishing network connection between
from vm://localhost to tcp://host2:61616
INFO DemandForwardingBridge - Network connection between vm://
localhost#0
and tcp://remotehost1:61616 has been established.
INFO DemandForwardingBridge - Network connection between vm://
localhost#2
and tcp://remotehost2:61616 has been established.
...
这些输出代表了在localhost上的代理已成功配置了连接另外两个运行于远程主机的代理的转发桥（forwarding bridge）。换句话说，发送到本地的消息会被转发到运行于remotehost1和
remotehost2的代理，但只是在有消费者请求这些信息的时候。
最好的理解的方式是通过修改使用股票示例。图4.6提供一个在该示例中使用的代理技术的透视图。（图略）
在该图中，两个代理已连接。代理通过URI和静态协议使用网络。消费者被绑定到代理B的一个目标中，它将穿过网络连接器请求消息。当生产者向代理B中相同的目标发送消息的时候，消息会被转发到有请求的代理上。这种情况中，代理A转发消息到代理B。接下来的例子将过一下这种基本的使用方法。
为了使例子工作，首先我们需要开启这两个连上的代理，让我们从代理B开始：
<broker xmlns="http://activemq.apache.org/schema/core"
brokerName="BrokerB"
dataDirectory="${activemq.base}/data">
<transportConnectors>
<transportConnector name="openwire" uri="tcp://localhost:61617" />
</transportConnectors>
</broker>
这个简单的配置启动了一个代理监听端口61617。我们可以通过下面的命令启动这个代理：
${ACTIVEMQ_HOME}/bin/activemq console \
xbean:src/main/resources/org/apache/activemq/book/ch4/brokerA.xml
现在是时候配置代理器A了：
<broker xmlns="http://activemq.apache.org/schema/core"
brokerName="BrokerA"
dataDirectory="${activemq.base}/data">
<transportConnectors>
<transportConnector name="openwire" uri="tcp://localhost:61616" />
</transportConnectors>
<networkConnectors>
<networkConnector uri="static:(tcp://localhost:61617)" />
</networkConnectors>
</broker>
除了传输连接器监听者61616端口，它定义了连接到代理B的网络连接。在另外独立的控制台窗口，你能像这样开启这个代理：
${ACTIVEMQ_HOME}/bin/activemq console \
xbean:src/main/resources/org/apache/activemq/book/ch4/brokerB.xml
现在我们已经启动了这两个代理，让我们运行股票示例。首先我们会打开我们的publisher并把它连接到代理A：
$ mvn exec:java -Dexec.mainClass=org.apache.activemq.book.ch4.Publisher \
-Dexec.args="tcp://localhost:61616 CSCO ORCL"
...
Sending: {price=65.713356601409, stock=JAVA, offer=65.779069958011, up=true}
on destination: topic://STOCKS.JAVA
Sending: {price=66.071605671946, stock=JAVA, offer=66.137677277617, up=true}
on destination: topic://STOCKS.JAVA
Sending: {price=65.929035001620, stock=JAVA, offer=65.994964036622, up=false}
on destination: topic://STOCKS.JAVA
...
实际上它与早前TCP连接示例的命令是相同的。现在启动消费者并连接到代理B:
$ mvn exec:java -Dexec.mainClass=org.apache.activemq.book.ch4.Consumer \
-Dexec.args="tcp://localhost:61617 CSCO ORCL"
...
ORCL 65.71 65.78 up
ORCL 66.07 66.14 up
ORCL 65.93 65.99 down
CSCO 23.30 23.33 up
...
使用该设置，消息会被提交到代理A。这些消息将被转发到代理B，并被消费者接收。这个例子的所有功能没有改变并且publisher和consumer的表现和原来单个代理如出一辙。唯一不同的是它们现在连接不同的代理，这些代理被静态协议网在一起。
从这个简单的例子你能推断这个特定配置能帮助你处理这样的情况：你需要你的分布式客户端受益于与本地代理交互而不是远程代理的性能优点。
使用静态协议的示例
情况不同配置代理网络能也会不同。静态协议的使用考虑到一个明确标记网络应该存在。考虑这样的情况：位于远程办公室的客户端正在连接家里办公室的代理。根据每个远程办公室的客户端的数量，你可能最终会有太多的广域网连接到你的家庭办公室。这可能导致不必要的网络负担。为了使连接最小化，你可能想要在每个远程办公室里放置一个代理并允许一个在远程办公室代理和家庭办公室代理间的网络。这不仅会最小化远程办公室和家庭办公室网络连接数，而且会允许远程办公室的客户端应用运行得更有效率。在广域网上长连接的迁移意味着较少的潜在因素，并会减少对客户端应用的等待时间。
故障转移（FAILOVER）协议
在至今为止的示例中，客户端被配置去连接唯一特定的代理。但是万一你无法连接想连的代理或你的连接在之后的阶段掉了你该怎么办？你的客户端有两种选择：他们将优雅的死去或者尝试连接相同或一些其他代理并回复他们的工作。正如你可能猜到的，股票示例使用这些协议运行至今并不免于网络问题和不可用的代理。那就是例如故障转移协议来实现自动重连的地方。与网络连接器的情况类似，有两种方法提供一个合适的可用于客户端连接的代理的列表。在第一种情况下，你提供一个可用代理的列表。这种方式用户故障转移交互连接器（failover transport connector）。在第二种情况下，动态发现可用代理被使用。这会在下面一章介绍。这节将检验故障转移交互连接器。
故障转移器的URI语法类似之前的静态网络连接器的URI。实际上有两种格式：
failover:(uri1,...,uriN)?key=value
或者
failover:uri1,...,uriN
完整的说明信息可以在ActiveMQ的网站（http://mng.bz/u58s）上找到。
默认的，该协议使用一个随机算法来选择一个优先连接器。如果这个连接失败（在开启的时候或者后面的阶段），传输会选择另外一个URI并尝试连接。默认的配置也实现了重连延迟逻辑，意味着传输会在第一次尝试重连时有10毫秒延迟并在后面的尝试时翻倍，直到30000毫秒。同时，重连逻辑会无限期尝试重连。当然，所有的重连参数可以根据你的需要使用合适的传输选项进行配置。
回忆在上一节定义的静态代理网络。在那个示例中，所有发送到本地代理的信息可能被转发到位于remotehost1和remotehost2上的代理。因为所有的信息可能被同时发送到这两个代理，那些消息能被其中一台代理消耗。在这同样如此。唯一不同的是故障转移传输在代理的故障转移中会自动尝试重连。为了体验这个传输的使用，运行股票消费者和配置它使用故障转移连接器连接到代理：
$ mvn exec:java -Dexec.mainClass=org.apache.activemq.book.ch4.Consumer \
-Dexec.args="failover:(tcp://remotehost1:61616,tcp://
remotehost2:61616) CSCO ORCL"
这个解决方案的优美之处在于它在代理失败的事件中为了增加对自动重连的支持不需要对应用做改变。
现在让我们看看工作中的故障转移连接器。想象故障转移传输中的随机算法已被选择去连接host1上的代理。你能预见消费者会在启动时打印下面的log信息：
org.apache.activemq.transport.failover.FailoverTransport$1 iterate INFO: \
Successfully reconnected to tcp://host1:61616
正如我们所说的，所有发布者发送到本地代理的消息会被转发到host1上的代理并被消费者接收。现在尝试通过关闭host1上的代理模拟一个代理失败。消费者会打印如下的日志信息：
org.apache.activemq.transport.failover.FailoverTransport handleTransportFailure
WARNING: Transport failed,
attempting to automatically reconnect due to: java.io.EOFException
java.io.EOFException
at java.io.DataInputStream.readInt(DataInputStream.java:375)
at org.apache.activemq.openwire.OpenWireFormat.unmarshal(OpenWireFormat.java:268)
at org.apache.activemq.transport.tcp.TcpTransport.readCommand(TcpTransport.java:192)
at org.apache.activemq.transport.tcp.TcpTransport.doRun(TcpTransport.java:184)
at org.apache.activemq.transport.tcp.TcpTransport.run(TcpTransport.java:172)
at java.lang.Thread.run(Thread.java:619)
org.apache.activemq.transport.failover.FailoverTransport$1 iterate
INFO: Successfully reconnected to tcp://host2:61616
注意最初的异常指出了失败，接着是重连到另外一个代理的日志信息。这个意味着消费者成功连接到另外一个代理并且你能看到在没有任何的帮助下它恢复了它的正常操作。
故障转移使用示例
由于它的重连能力，你为所有的客户端使用故障转移协议是非常明智的，即使一个客户端只连接到一个代理。例如，当代理因任何原因关闭的时候下面的URI会尝试恢复对同一个代理的连接：
failover:(tcp://localhost:61616)
它的优点是在代理失败（或维护等待）的情况下客户端不需要被手动重启。一旦代理再次可用客户端会自动重连。这意味着通过简单的利用ActiveMQ的特性是你的应用更健壮。
故障转移传输连接器在实现例如高性能和平衡加载的高级功能上扮演了一个重要的角色，也将会在第12章说明。