最终，我们最终获得了自己开发的负载平衡微库（ESB / UDDI / WS-Addressing似乎是一个有趣的替代方案，但在我们的情况下这是一个过大的选择）。 如果我们只知道Apache CXF已经（几乎）开箱即用地支持所有这些功能？

<jaxws:client id="testServiceClient"serviceClass="com.blogspot.nurkiewicz.cxfcluster.SimpleService"address="http://serverA/simple"><jaxws:features><clustering:failover><clustering:strategy><bean class="org.apache.cxf.clustering.RandomStrategy"><property name="alternateAddresses"><util:list><value>http://serverB/simple</value><value>http://serverC/simple</value><value>http://serverD/simple</value></util:list></property></bean></clustering:strategy></clustering:failover></jaxws:features></jaxws:client>

<cxf:bus><cxf:features><cxf:logging/></cxf:features>
</cxf:bus>

<bean id="abstractLoggingInterceptor" abstract="true"><property name="prettyLogging" value="true"/>
</bean>
<bean id="loggingInInterceptor" class="org.apache.cxf.interceptor.LoggingInInterceptor" parent="abstractLoggingInterceptor"/>
<bean id="loggingOutInterceptor" class="org.apache.cxf.interceptor.LoggingOutInterceptor" parent="abstractLoggingInterceptor"/><cxf:bus><cxf:inInterceptors><ref bean="loggingInInterceptor"/></cxf:inInterceptors><cxf:outInterceptors><ref bean="loggingOutInterceptor"/></cxf:outInterceptors><cxf:outFaultInterceptors><ref bean="loggingOutInterceptor"/></cxf:outFaultInterceptors><cxf:inFaultInterceptors><ref bean="loggingInInterceptor"/></cxf:inFaultInterceptors>
</cxf:bus>

<jaxws:client id="testServiceClient" serviceClass="com.blogspot.nurkiewicz.cxfcluster.SimpleService"><jaxws:features><clustering:loadDistributor><clustering:strategy><bean class="org.apache.cxf.clustering.SequentialStrategy"><property name="alternateAddresses"><util:list><value>http://serverA/simple</value><value>http://serverB/simple</value><value>http://serverC/simple</value><value>http://serverD/simple</value></util:list></property></bean></clustering:strategy></clustering:loadDistributor></jaxws:features></jaxws:client>

请注意，客户端本身不再定义地址属性。 这表明， alternateAddresses列表仅在所有调用中使用，并且不存在主地址-实际上是这种情况。 SequentialStrategy将使用一个端点接另一个端点，以提供良好的循环实现（也提供RandomStrategy ）。 同样，在此配置中，您将免费获得故障转移–如果任何端点发生故障，将从第一个端点开始的所有端点都将受到检查（显然，刚刚发生故障的端点除外）。

大！ 现在，CXF客户端更加严格和容错。 但是，在我们追求更高可用性并最大程度地减少停机时间的过程中，仅在应用程序启动时才加载备用节点（换句话说，添加新服务器需要重新启动所有客户端）实在太过局限了。 幸运的是，我们可以通过两个简单的步骤使负载均衡更加动态。

<jaxws:client id="testServiceClient" serviceClass="com.blogspot.nurkiewicz.cxfcluster.SimpleService"><jaxws:features><clustering:loadDistributor><clustering:strategy><bean class="org.apache.cxf.clustering.SequentialStrategy"><property name="alternateAddresses" ref="alternateAddresses"/></bean></clustering:strategy></clustering:loadDistributor></jaxws:features></jaxws:client><util:list id="alternateAddresses" list-class="java.util.concurrent.CopyOnWriteArrayList"><value>http://serverA/simple</value><value>http://serverB/simple</value><value>http://serverC/simple</value><value>http://serverD/simple</value>
</util:list>

没什么，提取嵌套的匿名bean。 但是可以访问此列表（请注意，我使用了java.util.concurrent.CopyOnWriteArrayList ）使我们可以将其注入任何其他服务，从而可能改变其状态。 我怎么知道这会起作用？ 好吧，我花了几天的时间调试Apache CXF，以最终发现负载平衡算法：第一次调用时，CXF要求策略提供可能节点的列表。 然后它会将这个列表返回策略要求到（在这里小编WTF ......）挑选一个战略决定哪些地址，使用和删除列表中挑选地址（另一个小一个在这里...）当CXF发现列表是空的，故事重复本身。 因此，如果我们在运行时替换备用地址列表，则一轮新列表将返回到核心CXF基础结构。

因为我是JMX的拥护者，所以这是我们修改地址列表的方法（您可以使用任何喜欢的机制）：

@Service
@ManagedResource
public class AlternateAddressesManager {@Resourceprivate List alternateAddresses;@ManagedOperationpublic void addAlternateAddress(String address) {alternateAddresses.add(address);}@ManagedOperationpublic boolean removeAlternateAddress(String address) {return alternateAddresses.remove(address);}@ManagedAttributepublic List getAlternateAddresses() {return Collections.unmodifiableList(alternateAddresses);}}

是的，这是SequentialStrategy使用的非常相同的alternateAddresses列表，因此，只需对其进行修改，就可以更改CXF寻址行为。 可以说，我们可以扩展CopyOnWriteArrayList，添加一些额外的启用JMX的方法（或者，探索Springs的灵活性，直接通过JMX公开List方法！），但这会降低可维护性，我认为这是较差的设计。

最后，我们可以按照下面的屏幕快照启动jconsole或JVisualVM，并享受我们的负载平衡基础架构：

快乐？ 并不是的。 在研究CXF源代码时，我遇到了有关LoadDistributorFeature和FailoverTargetSelector类的可怕的JavaDoc注释，它们在负载平衡过程中起着重要的作用：

/ **

* […]

*请注意，此功能会即时更改导管，从而使

* 客户端不是线程安全的。

* /

重点放在粗体的文本上（好的，老实说，我不理解其余内容）。 如果您已经使用Spring一段时间，您就会知道testServiceClient bean是多个线程同时使用的共享单例（否，使其原型作用域无济于事；为什么？），这与默认的EJB无状态会话bean相反，被汇集。 幸运的是，Spring也有一个内置的解决方案。 但是，在我最终提出正确的解决方案之前，出现了一些障碍。

首先，来自CXF名称空间的jaxws：client标记不允许定义bean范围，默认情况下为单例，而我们要合并客户端。 因此，我不得不使用org.apache.cxf.jaxws.JaxWsProxyFactoryBean恢复到良好的旧bean定义。 没问题，稍微冗长些，尽管如果您不希望使用自定义Spring名称空间，则可能从一开始就使用它。 现在最好的部分是：我可以将具有原型范围的任何bean封装在特殊的代理中，Spring会自动创建一个对象池（基于commons-pool库），并根据需要创建尽可能多的bean实例，以使每个bean仅由一个使用。线。 配置如下：

<bean id="testServiceClientFactoryBean" class="org.apache.cxf.jaxws.JaxWsProxyFactoryBean"><property name="serviceClass" value="com.blogspot.nurkiewicz.cxfcluster.SimpleService"/><property name="features"><util:list><bean class="org.apache.cxf.clustering.LoadDistributorFeature"><property name="strategy"><bean class="org.apache.cxf.clustering.SequentialStrategy"><property name="alternateAddresses" ref="alternateAddresses"/></bean></property></bean></util:list></property>
</bean><bean id="testServiceClientTarget" factory-bean="testServiceClientFactoryBean" factory-method="create" scope="prototype" lazy-init="true"/><bean id="testServiceClient" class="org.springframework.aop.framework.ProxyFactoryBean"><property name="targetSource"><bean class="org.springframework.aop.target.CommonsPoolTargetSource"><property name="targetClass" value="com.blogspot.nurkiewicz.cxfcluster.SimpleService"/><property name="targetBeanName" value="testServiceClientTarget"/><property name="maxSize" value="10"/><property name="maxWait" value="5000"/></bean></property>
</bean>

您是否注意到maxSize和maxWait池属性？ 他们真是太酷了 ！ 您可以告诉Spring在池中创建的客户端不要超过10个，并且如果池为空（当前正在使用所有Bean），则我们应该等待不超过5000毫秒（此后可以配置！）实际上是非常简单但功能强大的限制机制，比JMS或显式线程池简单得多，我们绝对免费！ 例如，不想服务超过20个并发Web服务客户端？ 使服务器端点访问服务Bean的大小限制为20。超过此限制的客户端将被拒绝，因为没有可用的服务Bean。

当然，在成人世界中，没有任何效果可以预期。 我很快发现JaxWsProxyFactoryBean.create不是线程安全的， 并报告了CXF-3558 。 作为解决方法，我必须通过将其 子类化 来同步 CommonsPoolTargetSource 使用的客户端工厂 ：

import org.apache.commons.pool.ObjectPool;
import org.apache.commons.pool.PoolUtils;
import org.springframework.aop.target.CommonsPoolTargetSource;public class SynchCommonsPoolTargetSource extends CommonsPoolTargetSource {@Overrideprotected ObjectPool createObjectPool() {return PoolUtils.synchronizedPool(super.createObjectPool());}}

似乎需要同步工厂，因此我创建了SPR-8382-也许它将找到正式发行的方式。 顺便说一句，在撰写本文时，我还报告了IDEA-70365 – 报告了List类型bean的 虚假 “无法自动装配”错误 。

最后！ 我们的负载平衡和故障转移就像一个魅力。 下一步将是暂时丢弃掉了几秒钟的节点，如果此后端点仍然掉线，则增加此时间。 但是Apache CXF在这一领域的API如此糟糕，以至于我不得不离开这个话题一段时间。 也许您可以帮忙？

参考： NoBlogDefFound博客上的 JCG合作伙伴 Tomasz 在Apache CXF中启用负载平衡和故障转移 。

相关文章 ：

• 带有Spring和Maven教程的JAX–WS
• Spring3 RESTful Web服务
• Tomcat 7上具有RESTeasy JAX-RS的RESTful Web服务-Eclipse和Maven项目