OSB深度使用总结VIP免费

OSB 深度使用总结 1 通过Workmanager 进行流量控制 首先我们来看一下流量控制能为系统带来哪些不一样的效果，我们假设有转账交易A和查询交易B，我们希望在遇到ESB 繁忙的时候A 能够得到优先处理，而当系统不繁忙的时候A 和B 都能够尽可能的得到处理。 为了能够比较容易的看到效果，我们让 A，B 交易的处理过程完全相同，这样便于看到因为请求数量变化所带来的影响。 当没有流量控制时：如果让 A，B 的初始请求数量完全 1：1，可以看到AB 交易的处理能力和响应时间的曲线是基本重叠的，并且随着达到系统处理能力的上限，响应时间会随并发请求数量的增长而增长。 如果这个时候增加低优先的B 交易的并发数量，B 的TPS 会上升，高优先的A 会下降，同时响应时间会增长，这并不符合高优先的控制原则。 Oracle 在测试中使用的流量控制机制可以达到如下的效果： 如果只有低优先的业务，系统可以使用全部的资源进行处理，当出现高优先的业务时，按照比例让位给高优先业务。 如果高低优先的业务同时在ESB 上处理，并且并发数量相同，OSB 可以直接控制高优先的处理多，低优先的处理少。 传统厂商的产品中也可以设置处理的优先级，但以消息优先级居多，通过控制消息的处理频率和密度，间接实现对处理资源的使用。Oracle 除了设置消息的优先级之外，更重要的是可以调控不同级别的请求在ESB 上所占用 CPU 的时间开销比例，真正实现了处理资源上的分配和管理。 1 .1 流量控制实现机制 LocalProxy调用时会使用前面ProxyService的线程模型继续执行，因此前面ProxyService上的Dispatch Policy 会一直作用到LocalProxy 的处理过程之中。 Business Service 会使用新的线程去执行，因此如果在Pipeline 中routing 到了其他的非LocalProxy，前端的流量控制就到此结束了。 Business Service 如果是JMS 等异步的方式，Biz 上的流量控制效果会差一些，因为本身的处理过程太短，消息实际上都被堆在了队列里。 ProxyService1ProxyService2LocalProxyBusinessService1BusinessService2系统Route通过不同的WorkManager控制并发执行的数量对一个系统的调用映射为多个不同的Business Service并赋予不同的并发控制、服务质量协议通过LocalProxy进入真正的OSB处理流程根据交易的性质路由到不同的逻辑通道对不同渠道的应用建立独立的交易通道如果是HTTP协议或者Wevservice调用，可以通过Weblogic 的Channel功能，为不同的前端开...