通过前一篇的翻译资料[翻译]Petals ESB 拓扑结构及集群,相信对Petals ESB的集群有所了解,但是实战时却发现跟想像的并不一样.
首先说下集群主要完成的事情有两件,1)负载均衡,2)单点故障.而Petal ESB并不是全局意义的集群环境.我也是在自己的臆想下做动手做,发现根据相关的文章拓扑结构能够完成,但是想测试集群的功能总是不能如愿似偿.亏得 jackiee_cn 告知,参考文档 http://forum.petalslink.com/Load-balancing-features-td2693411.html#a2693405 而正确理解了Petals ESB集群的真正内涵.
这是管理员 Vincent Zurczak 贴出对集群及路由的原文,
Hi, :) Here are some explainations about Petals' load balancing mecanisms. First, you must remember that Petals can be distributed. It means you may have several instances of Petals that run on different machines and that communicate together. As an example, you may have one consumer deployed on one machine (node) and the associated service providers deployed on other nodes. The invocation will be made transparently, just like if they were all on the same node. This answers one of your questions. Petals supports heteregenous hardware because each server has its own instance of Petals. And this instance can communicate with others. The only requirement is to have a communication network. Then, here is what we mean by load balancing. It means that the choice of a service provider (when a consumer requests it) is made in the bus according to certain routing criteria. So, in Petals, load balancing is equivalent to message routing. It is different from the clustering approach. Currenty, there are two routing strategies. The first one is random: among all the valid providers, we select one randomly. The second one is a proximity criteria: we can define priorities on what nodes should be chosen. We can either give priority to the services that are deployed on the same node than the consumer, or select one on a remote node. The hardware usage criteria (CPU, memory usage) is not implemented for the moment. But it could be one routing strategy. Once you have chosen a routing strategy (server.properties), the routing uses it. It is transparent. However, service consumers can set a different routing strategy on a given message. It depends on the Petals component you use. Petals supports it, but not all the components allow you to use this feature. Also, remember that a Petals service is identified by a triplet: the interface name, the service name and the end-point name. These values are all visible in the jbi.xml of a service provider. In order to use the routing, you must have at least two service providers that match the needs of a consumer. This is why service consumers should invoke a service by using either its interface-name, or it service-name, or both. But if they invoke a service by specifying the entire triplet, they will have, at most, one matching provider. And routing will not be used. Example: Suppose you have three services that implement the same interface. ( Service ID: interface name, service name, end-point name ) Service 1-1: SellPortType, Service1, Service1Endpoint1 Service 1-2: SellPortType, Service1, Service1Endpoint2 Service 2: SellPortType, Service2, Service2Endpoint1 Service 1-2 is the same service (same service name) than Service 1-1, but deployed somewhere else. Now, suppose you have one consumer. If it consumes SellPortType, then it will find 3 matching services. And thus, a routing strategy will be used. If it consumes SellPortType + Service1, then it will find 2 matching services. And thus, a routing strategy will be used. If it consumes SellPortType + Service1 + Service1Endpoint1, then it will find only 1 matching service. And thus, a routing strategy will be useless. I hope that it will help you. ;)
翻译如下:
Hi, :) 如下是对Petals ESB负载均衡的一些解释. 首先,Petals会实现分布式,这意味着你可以把相同的用例分布在不同的机器上进行协助运行.比如,你可以把消费者部署在一台服务器上,而把提供者部署在多台服务器上.而对于调用者来说是透明的,把调用服务认为是一个整体.(这回答你的第一个问题),Petals 支持不同的硬件,只要每台服务器都部署了Petals的实例,并且保证这些服务实例是可用的,这里只要求网络是畅通的. 好,这就是我们所谓的负载均衡. 也就是说服务提供供的选择(当有消费者调用时)是根据一定的路由标准来实现总线的. 所以说,Petals的负载均衡等同于消息路由,区别于其它集群实现方法. 当前,有两种路由策略. 第一种是随机(random):针对于提供者,是随机选择的. 第二种接近标准(其实就是highest,ADD):我们根据物理节点定义优先级,对于同一节点,消费者的调用优先于本机上的服务提供者,或者被动选择远程上的一个服务提供者节点.硬件环境(CPU,内存)暂时不做考虑,但这也是一种路由策略. 一旦你在server.properties文件当中选择了路由策略,路由就生效了,这是透明的. 然后,服务消费者者可以在一个给定的消息设置不同的路由策略。这取决于您使用的Petals组件上。虽然支持,但是不是所有组件都能这样使用. 同样,记住,Petals调用服务提供者有三个选项: interface name, service name 和 end-point name. 这些值都做为一个服务提供者,可以jbi.xml文件里看到,为了实现路由,你至少有两个服务提供者,一个服务消费者.这是为什么服务消费者通过使用interface-name 或者service-name.或者两者,他们会选择一个服务提供者.如果三个选项都选择,只会返回指定的一台服务提供者.(有点绕,看下面的例子!) 举例: 假如你有三个服务,实现相同的接口.
| ServiceId | Interface Name | Service Name | End-point Name |
| Service 1-1 | SellPortType | Service1 | Service1Endpoint1 |
| Service 1-2 | SellPortType | Service2 | Service1Endpoint2 |
| Service 2 | SellPortType | Service2 | Service2Endpoint1 |
Service 1-2 和Service 1-1有相同的服务,但部署在不同的地方. 现在,假如有一个消费者. 如果消费者,指定一个参数SellPortTye,则会发现三台机器上的服务提供者,同样,根据路由策略,将会选择其中的一个服务提供者. 如果消费者,指定两个参数:SellPortType + Service1,则会发现有二台机器上的服务提供者,同样根据路由策略,将会选择其中一个服务提供者. 如果消费者,指定三个参数:SellPortType + Service1 + Service1Endpoint1,则会发现只有一台机器上的服务者,同样,只能路由到这台服务器上的. 希望能够给你提供帮助. ;)
从如上的分析来说,也就是说,做为服务提供者,可以做为集群部署,但是服务消费者,可能还会存在单点故障问题.
理一下Petals ESB的集群环境.
这样的话,对于服务消费者来说,不能实现真正意义上的集群(负载均衡和单点故障),我想解决的方法应该有两个,
- 只部署服务提供者,使用API的方法让开发者来调用.
- 把服务消费者也做一个集群,如下图所示:
好了,如上是理论问题,下面将根据理论来指导一下实现.
第一步,选择你的拓扑方式,
主要有两个文件这里我一一贴出.
首先,主域使用static模式,子域使用master-slave模式.
主机的配置文件.topology.xml
<?xml version="1.0" encoding="UTF-8"?> <tns:topology xmlns:tns="http://petals.ow2.org/topology" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://petals.ow2.org/topology petalsTopology.xsd"> <tns:domain mode="static" name="PEtALS"> <tns:description>The static domain configuration</tns:description> <tns:sub-domain name="OHH" mode="master-slave"> <tns:description>description of the subdomain</tns:description> <tns:container name="CIQ" type="master"> <tns:description>description of the container 0</tns:description> <tns:host>192.168.32.85</tns:host> <tns:user>petals</tns:user> <tns:password>petals</tns:password> <tns:webservice-service> <tns:port>7600</tns:port> <tns:prefix>petals/ws</tns:prefix> </tns:webservice-service> <tns:jmx-service> <tns:rmi-port>7700</tns:rmi-port> </tns:jmx-service> <tns:transport-service> <tns:tcp-port>7800</tns:tcp-port> </tns:transport-service> <tns:registry-service> <tns:port>7900</tns:port> </tns:registry-service> </tns:container> <tns:container name="CIQS" type="slave"> <tns:description>description of the container CIQS</tns:description> <tns:host>192.168.32.84</tns:host> <tns:user>petals</tns:user> <tns:password>petals</tns:password> <tns:webservice-service> <tns:port>7601</tns:port> <tns:prefix>petals/ws</tns:prefix> </tns:webservice-service> <tns:jmx-service> <tns:rmi-port>7701</tns:rmi-port> </tns:jmx-service> <tns:transport-service> <tns:tcp-port>7801</tns:tcp-port> </tns:transport-service> <tns:registry-service> <tns:port>7901</tns:port> </tns:registry-service> </tns:container> </tns:sub-domain> </tns:domain> </tns:topology>
其中 server.properties当中:
petals.container.name=CIQ
从机上的topology.xml
<?xml version="1.0" encoding="UTF-8"?> <tns:topology xmlns:tns="http://petals.ow2.org/topology" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://petals.ow2.org/topology petalsTopology.xsd"> <tns:domain mode="static" name="PEtALS"> <tns:description>The static domain configuration</tns:description> <tns:sub-domain name="OHH" mode="master-slave"> <tns:description>description of the ITOWNET</tns:description> <tns:container name="CIQ" type="master"> <tns:description>description of the container CIQ</tns:description> <tns:host>192.168.32.85</tns:host> <tns:user>petals</tns:user> <tns:password>petals</tns:password> <tns:webservice-service> <tns:port>7600</tns:port> <tns:prefix>petals/ws</tns:prefix> </tns:webservice-service> <tns:jmx-service> <tns:rmi-port>7700</tns:rmi-port> </tns:jmx-service> <tns:transport-service> <tns:tcp-port>7800</tns:tcp-port> </tns:transport-service> <tns:registry-service> <tns:port>7900</tns:port> </tns:registry-service> </tns:container> <tns:container name="CIQS" type="slave"> <tns:description>description of the container CIQS</tns:description> <tns:host>192.168.32.84</tns:host> <tns:user>petals</tns:user> <tns:password>petals</tns:password> <tns:webservice-service> <tns:port>7601</tns:port> <tns:prefix>petals/ws</tns:prefix> </tns:webservice-service> <tns:jmx-service> <tns:rmi-port>7701</tns:rmi-port> </tns:jmx-service> <tns:transport-service> <tns:tcp-port>7801</tns:tcp-port> </tns:transport-service> <tns:registry-service> <tns:port>7901</tns:port> </tns:registry-service> </tns:container> </tns:sub-domain> </tns:domain> </tns:topology>
其中 server.properties当中:
petals.container.name=CIQS
如上的两个topology.xml是一样的,不一样的是server.properties当中的容器名字.
如果是flooding : 水淹(洪泛)模式,则第一个节点都应该是
<?xml version="1.0" encoding="UTF-8"?> <tns:topology xmlns:tns="http://petals.ow2.org/topology" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://petals.ow2.org/topology petalsTopology.xsd"> <tns:domain mode="static" name="PEtALS"> <tns:description>The static domain configuration</tns:description> <tns:sub-domain name="OHH" mode="flooding"> <tns:description>description of the ITOWNET</tns:description> <tns:container name="CIQ" type="peer"> <tns:description>description of the container CIQ</tns:description> <tns:host>192.168.32.85</tns:host> <tns:user>petals</tns:user> <tns:password>petals</tns:password> <tns:webservice-service> <tns:port>7600</tns:port> <tns:prefix>petals/ws</tns:prefix> </tns:webservice-service> <tns:jmx-service> <tns:rmi-port>7700</tns:rmi-port> </tns:jmx-service> <tns:transport-service> <tns:tcp-port>7800</tns:tcp-port> </tns:transport-service> <tns:registry-service> <tns:port>7900</tns:port> </tns:registry-service> </tns:container> <tns:container name="CIQS" type="peer"> <tns:description>description of the container CIQS</tns:description> <tns:host>192.168.32.84</tns:host> <tns:user>petals</tns:user> <tns:password>petals</tns:password> <tns:webservice-service> <tns:port>7601</tns:port> <tns:prefix>petals/ws</tns:prefix> </tns:webservice-service> <tns:jmx-service> <tns:rmi-port>7701</tns:rmi-port> </tns:jmx-service> <tns:transport-service> <tns:tcp-port>7801</tns:tcp-port> </tns:transport-service> <tns:registry-service> <tns:port>7901</tns:port> </tns:registry-service> </tns:container> </tns:sub-domain> </tns:domain> </tns:topology>
其中 server.properties当中:
petals.container.name=<你peer当中的容器名字>
如前一章节所述,拓扑结构只会影响消息的流向路径和选择,而不影响消息本身.
第二步,修改server.properties,选择你的路由策略.
# Alternate topology configuration file URL. This value must be a valid URL like : # - http://localhost:8080/petals/topology.xml # - file:///home/petals/config/topology.xml # - or any valid URL (java.net.URL validation) # If not specified, the local topology.xml file is used # 这个可以忽略,主要如果你使用主域使用动态模式时,把topology.xml共享出来. #petals.topology.url= # This property defines the strategy of the router # Two kind of strategy can be defines: 'highest' or 'random'. # The following parameters, separated by commas, represent respectively the weighting for a local # endpoint, the weighting for a remote active endpoint and the weighting for a remote inactive endpoint. # The 'random' strategy chooses an endpoint randomly in function of the defined weightings. # Every endpoint has a chance to be elected, but the more the weight is strong, the more the endpoint # can be elected. # The 'highest' strategy chooses an endpoint amongst the endpoints with the strongest weight. # If not specified, the strategy 'highest,3,2,1' is selected by default #默认是highest 高可用,也就是查找就近的服务提供者. petals.router.strategy=random,3,2,1 # This property defines the number of attempt to send a message to an endpoint. #这个属性是定义一条消息能够传递的节点数量 # Several attempts can be done when there is transport failure during the convey of a message # If not specified, 2 attempts is selected by default #默认是2 petals.router.send.attempt=2 # This property defines the delay between the send attempts, in milliseconds. # If not specified, 1 second is selected by default petals.router.send.delay=1000
如上红色部分一定要打开,否则只是默认的.
第三步,创建一个服务提供者,并部署到两台不同的服务器上,
步骤略,参与以前的文档.
第四步,创建一个服务消费者,并部署到一台服务器上.
这里有一个讲究,一定要注意.示例一下.
- 创建一个服务消费者,Service Units->右键->New->Service Consumer(SU)
- 选择服务,选定参数一定要注意. 如下图所示.
完成后,部署在一台服务器上.
第五步,测试.
使用soapUI来调用服务消费者,就可以看到已经实现random路由了.
呵呵.