OSB 深度使用总结

OSB 深度使用总结

1通过Workmanager进行流量控制

首先我们来看一下流量控制能为系统带来哪些不一样的效果，我们假设有转账交易A 和查询交易B，我们希望在遇到ESB繁忙的时候A能够得到优先处理，而当系统不繁忙的时候A和B都能够尽可能的得到处理。

为了能够比较容易的看到效果，我们让A，B交易的处理过程完全相同，这样便于看到因为请求数量变化所带来的影响。

当没有流量控制时：如果让A，B的初始请求数量完全1：1，可以看到AB交易的处理能力和响应时间的曲线是基本重叠的，并且随着达到系统处理能力的上限，响应时间会随并发请求数量的增长而增长。

如果这个时候增加低优先的B交易的并发数量，B的TPS会上升，高优先的A会下降，同时响应时间会增长，这并不符合高优先的控制原则。

Oracle在测试中使用的流量控制机制可以达到如下的效果：

如果只有低优先的业务，系统可以使用全部的资源进行处理，当出现高优先的业务时，按照比例让位给高优先业务。

先的处理多，低优先的处理少。

传统厂商的产品中也可以设置处理的优先级，但以消息优先级居多，通过控制消息的处理频率和密度，间接实现对处理资源的使用。Oracle除了设置消息的优先级之外，更重要的是可以调控不同级别的请求在ESB上所占用CPU的时间开销比例，真正实现了处理资源上

的分配和管理。

1.1 流量控制实现机制

LocalProxy调用时会使用前面ProxyService的线程模型继续执行，因此前面ProxyService 上的Dispatch Policy会一直作用到LocalProxy的处理过程之中。

Business Service会使用新的线程去执行，因此如果在Pipeline中routing到了其他的非LocalProxy，前端的流量控制就到此结束了。

Business Service如果是JMS等异步的方式，Biz上的流量控制效果会差一些，因为本身的处理过程太短，消息实际上都被堆在了队列里。

Oracle的OSB产品在前端接入和后端调用业务系统两个层面提供流量控制的能力，在配置前端接入的ProxyService和后端业务系统调用的BusinessService时可以指定相应的DispatchPolicy实现流量控制。

ProxyService中的流量控制策略：

BusinessService中的流量控制策略：

OSB底层通过使用WebLogic中的workmanager为流量控制提供最大并行执行数量、最大排队等待的请求数量、以及在所有请求超过系统处理能力的情况下按比例分配OSB的执行资源。

1.2 关于测试上的几点说明

从目前的测试过程来看，需要把测试的压力发起端和OSB分布在至少2台笔记本上。

如果在同一台设备上，不容易测试出流量控制的效果，经常在测试一段之间之后，出现与没有流量控制一样的图线。在OSB上让处理过程java call out sleep几十个毫秒，测出的曲线会更加平稳。

2联邦架构对比

2.1 基于消息队列的联邦

基于消息队列的联邦，是通过消息队列异步的可靠传输和高吞吐，实现ESB处理过程与数据传输相分离，以减少处理资源在长时间传输上的等待。但是因为消息队列所具有的单向传输特性，因此一个同步调用过程需要有请求和响应的两个队列才能完成处理，并且需要ESB根据消息中的关键字进行返回结果的匹配。因此对于双向调用的系统需要建立至少4个消息队列。

使用JMS或MQ建立联邦通道，除了需要在OSB上配置Business Service和ProxyService 之外，还需要单独建立JMS的消息队列和配置每一组MQ的通讯连接。

2.1.1JMS/MQ

JMS是OSB产品的内置通讯协议，可用于XML、文本或二进制任意一种格式报文的传输，使用JMS可以实现异步或同异步匹配的消息传输。在导入MQ的支持包后，OSB同时也支持基于IBM MQ作为异步传输通道。

队列方式的优势：

1．可以进行报文的持久化，在OSB服务器宕机后依然可以保证消息可被处理

2．由服务提供方根据自己的处理能力主动获取消息

3．可以提供单向无返回的报文传输

队列方式的不足：

1．为了实现两个联邦节点的双向调用，需要配置2对InQ和OutQ的队列集群。大规模集群情况下，需要维护和监控大量的队列。

2．如果在联邦的所有节点之间都允许互相调用，因为不可能为每一对联邦成员都建立2对InQ和OutQ集群，因此只能让所有的访问端使用共享方式的队列集群，当出

现队列拥堵时将造成应用间的相互影响。

2.1.2联邦架构原理

JMS可以很好的支持同异步结构的转换，将前端系统发起的同步请求转换为总线内部的异步处理，或者将前端的异步请求转换为总线对后端系统的同步调用。解决前后端系统在调用模式上的差异。

2.1.3联邦架构

ESB集群下基于消息队列的总行调用分行的联邦架构：

在服务方ESB实例上建立一个请求队列InQ集群和一个响应队列OutQ集群，分行ESB 上建立一个通用的服务方接收的ProxyService，该服务会自动邦定本节点上的消息队列实例，监听并响应消息，自动从消息头中获取CorrelationID或MessageID（在通道配置中可指定），并将该信息自动填充到响应的消息头中。客户端的ESB即根据该字段从异步返回的消息中识别对应的结果。

该通道同时存在另一种配置形式，当服务端希望响应的消息被准确无误的送达到请求

2.1.4测试中发现的问题

2.1.4.1 J MS

1.OSB上创建的JMS Proxy Service默认只会在Queue上创建16个Consumer，这个

数量对与局域网应用基本上还算够用，但是当这个Proxy需要从远程网络，比如

从广州向北京的OSB上获取消息时，表现出来的现象是，北京服务器的CPU使

用率始终不是很高。调高该数值需要为该ProxyService创建一个Dispatch Policy，

并指定该workmanager所对应的最大和最小线程限制，如果只指定其中的一个，

系统依然会只创建16个consumer。

2.JMS Proxy在传输大尺寸报文的时候效率非常差，并且会阻塞小报文的传输。即

使对大小报文都分了不同的Queue，不同的ConnectionFactory，不同Channel到

不同的端口，但是没有根本性的改变。

3.在增加了SAF后JMS的通道性能在1K报文下降为原有的1/3。

2.1.4.2 同异步匹配

因为同异步匹配的ID是存储在WLS的内存中，因此如果发起方的OSB重启，那么响应方虽然可能还在正确处理，但是请求方OSB已经匹配不到这时返回的消息，因此该返回的消息将被抛弃，目前还不知道是否可以把该消息放入错误队列。

当压力端停止后，JMS的Queue中仍然积压着大量的消息，如果这个时候又重新开始压力测试，压力测试工具将很长时间没有TPS输出，因为所有新发起的请求都被堵塞在队列中排队。

消除的方法是重启OSB，或者在JMS Server上disable掉Insertion,consumption,production，然后再enable。

2.1.4.3 M essageID和CorrelationID

如果联邦架构中不止2个OSB，希望请求方共享中心的同一个调用接口，并把处理结果放回到分支机构本地的队列中时，就只能使用MessageID方式，使得中心可以使用reply to 的方式将消息返回给不同的来源方。

请求方(分支)请求方(分支)

Out Out

In

响应方(中心)

2.2 SB联邦架构

ServiceBus Transport是OSB产品的内置通讯协议，目前支持XML格式和附件的数据传输，在传输文本和二进制数据时需要人工进行报文的包装，但是该协议仍然具有众多的优势：

1．协议为同步调用协议，支持出错后向调用端的异常通知，ESB流程可以直接捕获该异常。

2．建立在Weblogic Server的底层传输协议之上，支持SSL和TCP包的传输优化，由Weblogic Server负责通讯中连接的管理。

3．可以设置访问账户，在调用时进行身份认证

4．可直接使用OSB内建的集群机制保证调用者和服务提供者两个集群之间通过简单配置进行访问。

5．支持全局事务上下文的传递。

使用SB联邦通道，除了需要配置BusinessService 和ProxyService之外，只需要为每一个需要访问的实例配置一个JNDI的lookup地址和用户名、密码即可。

2.2.1联邦架构原理

Service Bus Transport联邦依靠Weblogic Server的RMI调用方式建立同步的联邦调用通道。RMI目前使用Java远程消息交换协议JRMP（Java Remote Messaging Protocol）进行通信。JRMP是专为Java的远程对象制定的协议RMI 采用，是构建在TCP/IP协议上的一种远程调用方法。

OSB的RMI底层采用的是Oracle专有技术的T3通讯协议为基础，T3协议在通讯期间使用定期的点对点“心跳”来通知和确定连续可用性。每个端点定期向对等方发布“心跳”，同样也通过连续接收对等方的心跳，确定对等方是否仍然可用。在等候缺少的心跳次数达到一定数量后，服务器实例将认定对等方不可用。根据需要T3协议也可以增强为支持SSL的T3S。

2.2.2联邦架构

SB联邦的集群化部署简单。只需要在服务调用者一方创建一个对服务提供者集群的JNDI Provider资源，无论服务提供者上存在多少物理上的调用通道，都可以通过JNDI Provider获得。同时系统自动将调用者对后端的通道定义部署到调用者集群中的所有节点，并自动将服务提供者定义的服务通道发布到服务提供者的集群。

SB Transport

SB Transport

2.2.3 测试中发现的问题

T3协议是单通道长连接协议，报文传输效率较高，但是单一通道仍然不能满足广域网情况下的传输需求，新建的t3通道经过测试只有默认的与admin 一起的t3通道处理能力的一半，目前原因不明。因此在测试中在默认的管理端口通道的基础上又额外创建了多个t3 channel 。

T3在传输大尺寸报文（目前测试过的是2M ）时，效率并不高。

2.3 性能测试

环境：

测试中OSB 上的处理流程：

报文中剔除了空格、回车换行等在转换中影响报文实际大小的字节。

400Http 1K,2K,8K,32K,2M Messge

OSB1

Test Client OSB2

XML Transform To target format

JMS SB JMS+SAF

Synchronized

Call

XML Transform To source format Sleep 200ms

We test three types of communication

后续的所有JMS 和SB 之间的测试都是在同一套OSB 运行实例上进行。

2.3.1 基准测试

为了验证参与测试的网络和服务器是否本身存在瓶颈，进行了面向网络和单个OSB 的压力测试，以获得其最高的处理能力。 测试压力机和OSB1/OSB2之间的网络带宽，向两台OSB 分别发送2K 的HTTP 请求，OSB 的ProxyService 空转后返回：

?

?

?

?GB18030

??

?

?FieldName?FieldValue

?

。。。。。。More element

?

?

?

?

?

?UTF-8

??

?

。。。。。。More element

?

?

Source Message Format Target Message Format

测试OSB1/OSB2在部署了应用后的自身处理能力，从压力测试机分别向两个OSB 上

在应用测试中可以实现OSB2的CPU 利用率达到100%。

2.3.2 JMS

通道

在所有测试中 JMS 的persistance 都被去掉了，并且connection 没有支持XA 。

2.3.2.1 J MS 通道测试

2.3.2.2 单一尺寸报文测试

在该组测试下CPU利用率始终在30%左右。

从测试结果看，在小报文下JMS通道最初的瓶颈出在consumer太少，但是当consumer 很多时，数据的传输效率成为瓶颈，目前尝试了在OSB1上建立更多的channel供OSB2使用，依然没有明显的效果。

当把OSB2的应用实例直接部署在OSB1的机器上时，可以得到如下的测试结果：

2.3.2.3 混合报文测试Nearly 1000TPS

1K Message 1.2M bytes

Over 800TPS

2K Message 1.7M bytes

400TPS

8K Message 3.5M bytes

120TPS

32K Message 4.6M bytes

TPS 读数出现了严重的锯齿状读数：

并且OSB2的CPU 利用率出现严重的波动。

2.3.3SB通道

SB使用t3协议作为底层的通讯协议，OSB的RMI底层采用的是Oracle专有技术的T3通讯协议为基础，T3协议在通讯期间使用定期的点对点“心跳”来通知和确定连续可用性。每个端点定期向对等方发布“心跳”，同样也通过连续接收对等方的心跳，确定对等方是否仍然可用。在等候缺少的心跳次数达到一定数量后，服务器实例将认定对等方不可用。根据需要T3协议也可以增强为支持SSL的T3S。

在测试的架构中，不同尺寸的报文被分配在不同的传输模块上，2K以下报文被分配在快速通道模块，对应4个OSB2监听端口，2K到100K报文被分配在中速模块，对应1个OSB2的监听端口，超过1M的报文分配在低速模块，对应OSB2的1个监听端口。同时每个处理模块分配不同的线程资源，分配传输过程中在两个OSB节点上CPU开销。

2.3.3.1 S B通道测试

2.3.3.2 单一尺寸报文测试

单分行节点测试：

在单一尺寸报文测试中，为了获得通道上的最大传输能力，保证全部压力可以被传送到OSB2上，1K到32K报文模块的t3通道全部设置为4条。在实际测试中，每个场景下OSB2的CPU使用率都达到了100%

分行节点负载均衡情况下的单一报文测试：

2.3.3.3 混合报文测试

混合报文测试中为了使整体TPS读数最高，必须限制1K以上报文的处理量，本次测试中分别从前端BusinessService，通讯通道，后端处理的ProxyService 3个位置进行了限制。