Apache CXF负载平衡和故障转移

最新推荐文章于 2021-09-17 22:53:32 发布

dnc8371

最新推荐文章于 2021-09-17 22:53:32 发布

阅读量329

点赞数

文章标签： spring java 分布式 mysql zookeeper

前一段时间，我们已经面临基于Apache CXF的负载平衡Web服务客户端的需求。此外，当某些服务器关闭时，客户端应自动进行故障转移。更糟糕的是，服务器目标地址列表要从外部服务获取并在运行时更新。

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

但是，不要怪我们，仅提及此功能会指向非常糟糕的文档页面（如果您将404称为“差”）。如果不在正式文档中，我希望可以在Apache CXF Web服务开发书中找到它-不幸的是，那里也很不幸。但是，嘿，您自己探索这些功能不是更有趣吗？这是我们开始的客户端配置：

<beans xmlns="http://www.springframework.org/schema/beans"
       xmlns:jaxws="http://cxf.apache.org/jaxws"
       xmlns:clustering="http://cxf.apache.org/clustering"
       xmlns:util="http://www.springframework.org/schema/util">

    <jaxws:client id="testServiceClient"
                  serviceClass="com.blogspot.nurkiewicz.cxfcluster.SimpleService"
                  address="http://serverA/simple">
    </jaxws:client>

</beans>

端点接口在这里并不重要，足以知道将testServiceClient注入到其他一些服务中，并且负载平衡和故障转移功能不应影响现有代码。请注意，服务地址是固定的且经过硬编码的（当然可以将其外部化并在启动时读取）。

令人惊讶的是，仅启用故障转移是非常简单，直接和不言自明的（尽管是XML）：

<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>

serverA地址用作主要端点，但是当它失败时，将以随机顺序检查所有故障转移端点（ serverB ， serverC和serverD ）。为了发挥这种配置的作用，我建议您打开Apache CXF请求和响应日志记录：

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

再次（！），官方文档中没有提到非常方便的配置参数prettyLogging ，该参数可以应用于日志记录功能，以便在进行记录之前对XML请求和响应进行正确的格式化（换行和缩进）。我不建议在生产设置中使用它，但是在开发和测试过程中，格式化SOAP消息是非常宝贵的：

<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 {

    @Resource
    private List alternateAddresses;

    @ManagedOperation
    public void addAlternateAddress(String address) {
        alternateAddresses.add(address);
    }

    @ManagedOperation
    public boolean removeAlternateAddress(String address) {
        return alternateAddresses.remove(address);
    }

    @ManagedAttribute
    public 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 {

    @Override
    protected ObjectPool createObjectPool() {
        return PoolUtils.synchronizedPool(super.createObjectPool());
    }

}

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

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

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

相关文章：

翻译自: https://www.javacodegeeks.com/2011/06/apache-cxf-load-balancing-failover.html

dnc8371

关注

0
点赞
踩
0

收藏

觉得还不错? 一键收藏
0
评论
Apache CXF负载平衡和故障转移

前一段时间，我们已经面临基于Apache CXF的负载平衡Web服务客户端的需求。此外，当某些服务器关闭时，客户端应自动进行故障转移。更糟糕的是，服务器目标地址列表要从外部服务获取并在运行时更新。最终，我们最终获得了自己开发的负载平衡微库（ESB / UDDI / WS-Addressing似乎是一个有趣的替代方案，但在我们的情况下这是一个过大的选择）。如果我们只知道Apache...
复制链接

扫一扫