各种ESB产品比较.docx

各种ESB产品比较.docx

《各种ESB产品比较.docx》由会员分享，可在线阅读，更多相关《各种ESB产品比较.docx（23页珍藏版）》请在冰豆网上搜索。

各种ESB产品比较

各种ESB产品比较

介绍了主流商业和开源ESB的发展趋势、可借鉴的地方和其缺点：

     主要介绍：

     OracleServiceBus

     WebSphere Message Broker

     Mule

     ServiceMix/FUSEESB

     Synapse/WSO2ESB

ESB产品一览表包括商业和开源：

类型

产品

公司

商业

OracleServiceBus（OSB）

Oracle

OracleEnterpriseServiceBus（ESB）

WebSphereEnterpriseServiceBus

IBM

WebSphere Message Broker

WebSphere DataPower

Sonic ESB

Progress

ActiveMatrix ServiceBus

TIBCO

开源

Mule

MuleSoft

ServiceMix/FUSEESB

Progress

Synapse/WSO2ESB

WSO2

甲骨文的OSB

OracleServiceBus（OSB）的架构图:

主要逻辑层：

底层消息服务总线的安全，消息Broker，服务管理。

优点：

▪易用性

开发工具从WebConsole迁移到Eclipse，支持图形化拖拽和便于调试

在studio上直接集成测试功能，比如studio能提供直接发送和接收SOAP,JMS消息的功能，无需借助第三方工具，如SoapUI和编写JMS客户端代码。

▪性能提升

嵌入OracleCoherence（企业级的内存数据网格）产品，在特定场景下为服务调用提供缓存，性能提升80%。

Cache机制为静态响应信息提升性能。

静态响应信息是指在一段时间内不会发生变化的信息，如天气预报，手机套餐，人民币汇率等，这些数据变化的周期通常是1天，1月。

实现手段：

采用比较成熟的开源Memcached或者轻量级的JCACHE

▪管控能力增强

采用自动化的生命周期服务治理，从服务设计、开发、部署和运行期的整个服务生命周期内和EnterpriseRepository产品进行自动同步，无需人工干预。

缺点：

▪依赖于Weblogic

▪重量级的统一消息格式：

通过反编译OSB的源码，可以看出OSB将各种协议（HTTP,WS,JMS…）接入的消息统一转换为SOAPMessage，再通过XqueryEngine对SOAPMessage进行XML操作。

以下场景其缺点可立即显现：

1.HTTP下的大数据包

2.JMSObject类型的大数据包（最新版本OSB才支持JMSObject类型，之前只支持JMSText类型

依据：

对大数据包进行XML操作比较耗CPU

将大的Object转换为XML是个繁重的操作

IBM的WMB

WebSphereMessageBroker（WMB）的优点和趋势：

ß简化开发/部署架构

 去掉configurationmanager，开发工具/应用可以直接和broker交互。

ß易管理

 为管理员提供专用的管理工具--WebSphereMessageBrokerExplorer，可以管理本地和远程的broker和queuemanager，同时提供了监控broker性能和消息流的功能。

ß简化开发流程

  将常用的消息流场景进行了模板化，推出了基于模式的开发方式，用户只需要配置相关参数即可。

提供的模式分为两类：

内置（built-in）和自定义（user-defined）。

WMB7.0架构：

WMB开发/部署架构的变迁:

▪去掉configurationmanager，开发工具/应用可以直接和broker交互。

▪Broker的配置信息保存在File中，可以不依赖于DB。

▪统一安全机制，queuemanagersandbrokers均采用MQqueue的授权机制。

V6中采用的安全机制是由ConfigurationManager提供的AccessControlLists（ACLs）来管理授权的。

▪统一publish/subscribe机制，MessageBrokerV7直接采用WebSphereMQV7的publish/subscribe机制，因此去掉了以前版本中使用publish/subscribe时所需的UserNameServer。

WMB提供了基于模式的开发，将常用的场景模式化，比如服务穿透场景。

不使用基于模式开发一个服务穿透的场景所需步骤：

1.创建并配置业务服务

2.创建并配置代理服务

3.在代理服务中关联业务服务

如果采用模式开发，其步骤：

1.创建服务穿透模式并配置业务服务和代理服务

优点：

▪开发方式模式化

简化开发方式，减低了使用门槛，减少了使用中出现的概率。

▪开发方式的转变

由自底向上转变为自上而下。

▪自底向上

根据使用场景，逐个一步一步地开发组件，最后进行组装。

▪自上而下

根据使用场景选择特定的模式，用户只需要配置参数（比如队列名称，WSDL地址等）即可。

缺点：

▪重量级的架构

传统的EAI架构，必须依赖于WMQ。

▪笨重的ESQL

ESQL是WMB用于处理消息流的一套特有的扩展SQL的语言，功能很丰富，语法比较多，但学习门槛较高。

相比直接通过java方法操作消息，显得格外笨重。

开源Mule

优点：

▪社区活跃度

在开源ESB中，活跃程度最高，用户量大，不断推出新版本。

▪易用性

“让一切变得更简单”是Mule的宗旨。

2次重构核心架构、推出接入云应用，消息流，基于模式的配置以及热部署；MuleIDE3.0，将支持图元拖拽，简化开发。

▪扩展性

增加一个新协议非常简单，只需实现5个接口类即可。

org.mule.api.transport.Connector

org.mule.api.transport.MessageReceiver

org.mule.api.transport.MessageDispatcher

org.mule.api.transport.MessageDispatcherFactory

org.mule.api.transport.MuleMessageFactory

▪异常处理框架

异常策略设置级别:

model和service

异常处理方式：

1.将异常路由到指定的目的地

2.根据异常类型过滤异常，并路由到指定目的地

3.设置重试次数

4.当采用了事务时，可以在异常处理策略中设置当发生异常时是继续提交还是回滚事务。

▪管理性

推出MuleManagementConsole（收费），管理、部署和监控应用。

▪文档

文档非常丰富，降低了使用门槛。

基于模式的配置

基于webserviceproxy模式的webservice的穿透场景的配置（配置非常简单，3个属性）

proxyname="muleWsProxy" 

inboundAddress="http:

//localhost:

8080" 

outboundAddress="

缺点：

▪集群非常弱

1.只能配置一个主实例和一个从实例

2.不支持flow和基于模式的配置

3.某些路由会丢失或者获得重复的消息

▪MuleIDE

目前的IDE只提供XML级别的编辑，还不能实现图元的拖拽

▪稳定性

开源项目的通病，需要在测试场景下进行验证

ServiceMix

优点：

▪无缝集成CXF,ActiveMQ,Camel和ODE

因为ServiceMix,ActiveMQ,CXF,Camel都是FUSE的开源产品

▪JBI的优势

组件BC,SE可以在任何JBI容器（比限于ServiceMix）中直接运行，复用性强

▪基于OSGi

具备OSGi的优势：

模块化，热部署，易扩展

▪基于Karaf

提供了非常丰富的命令，管理、部署和监控ServiceMix

▪

问题：

▪JBI2.0太复杂且规范发展缓慢

IT巨头Oracle,IBM投了反对票，目前只有几家小公司投支持票。

已被主流中间件厂商抛弃,没有受到业界的青睐

▪由于JBI的复杂性所致，其架构并非轻量级

缺少IDE的支持

必须手写大量的XML配置文件

缺少governor的支持

ServiceMix4只是借助Flex的webconsole管理OSGi的bundle

学习门槛高

用户文档和相关资料比较少

▪ServiceMix迁移到OSGi

JBI2.0中增加了对OSGi的支持；

ServiceMix4.x完全基于OSGi，

ServiceMix3.x继续前行

▪Apache孵化新项目

Camel

Karaf

Synapse/WSO2ESB

▪Synapse发展缓慢

发展缓慢，新版本中没有增加比较有亮点的功能特性

▪WSO2ESB发展迅速

对Synapse增加了企业级特征：

1.基于WSO2的Carbon平台（OSGi框架）

2.支持集群、负载均衡和failoverrouting

3.支持流量控制和数据缓存

还增加了外围产品：

1.WSO2GovernanceRegistry，服务注册产品

2.WSO2ESBmanagementconsole，ESB管理控制台

3.WSO2CarbonStudio，开发ESB的studio

▪基于Axis

借助于Axis的特性，能非常好的支持ws规范，ws-*。

因此非常适合WebService的场景。

▪基于WSO2的Carbon平台

Carbon是WSO2的基础平台，它是一个OSGi框架，几乎WSO2的都基于它。

▪支持集群

集群中节点间的通信框架基于ApacheTribes（组通信框架）

相关信息持久化在内嵌的Derby中

支持一个主节点和多个从节点failoverrouting

在集群环境中，所有的请求只能被主节点接收，从节点只能作为备份节点。

▪支持流量控制

在单个ESB实例或者集群中，可以在服务级别配置流量控制。

当请求数超过阀值时，ESB将被拒绝访问。

实现机制：

借助组件ThrottlingMediator

▪支持数据缓存

集群中的各个ESB实例共享缓存的数据。

当一个请求被ESB实例1处理完后返回响应信息，当再次向ESB实例1或者集群中其他的ESB实例发送该请求时，直接从缓存中取出原来的响应信息。

实现机制：

借助组件CachingMediator

▪WSO2GovernanceRegistry

开源中最优秀的服务注册项目

▪WSO2ESBmanagementconsole

创建和管理各组件（接入层、中介层和接出层）；

图形化地方式统计系统资源（CPU,内存）；

图像化统计ESB中各组件（接入层、中介层和接出层）接收发送消息的大小以及响应时间；

记录系统日志、SOAP日志；图形化显示消息的流向

▪文档丰富

WSO2提供了非常丰富的文档：

安装手册

开发手册

管理员手册

部署手册

…

大量的使用实例

缺点：

▪架构不够清晰

显得有点臃肿、不简洁、不够优雅

▪扩展性差

新增一个协议/transport非常困难

▪组件比较凌乱

对多种协议（HTTP,WebService，JMS,FTP,EMAIL）的支持，部分依赖于Axis2,部分依赖于synapse

企业集成对公司管理提出显著转变的需要，致力于一体化的努力通常对业务产生深远的影响，但是如果缺乏标准的集成方案，导致概念和技术学习难度增加。

集成定义：

将不同的计算机系统，公司或个人连接起来，企业集成是使不同的应用程序协同工作，产生一个统一的功能集的任务。

集成类型

▪信息门户

▪数据复制

▪共享业务功能

▪面向服务的体系结构

▪分布式业务流程

▪企业对企业集成

企业集成模式：

▪文件传输

▪共享数据库

▪远程过程调用

▪消息

基于消息的EAI:

消息集成分以下步骤实施：

▪construction消息构建

▪Channels通道

▪Endpoints端点

▪Routing路由

▪Transformation转换

▪Management管理

▪MessagingModels消息模型

▪Transactions事务

　　目前有SpringIntegration,MuleESB和ApacheCamel. 三种开源集成框架，它们都遵循企业集成模式EIP（EIP, ），各有细微的区别。

Construction消息构建

　　消息是一个数据单元格式，一个消息由一个头，属性和主体的组成发送方转换数据输出构造消息接收方重新从消息恢复成自己的数据模型。

（1）.Spring集成的消息模型如下：

特点：

▪一个基于模型的消息中最简单的形式

▪使用泛型规定消息体类型

▪无marshaling或un-marshaling需要

（2）.JBI（Java业务集成）的模型如下：

特点：

支持附件和XML以及安全。

　　（3）.ApacheCamel的消息模型：

消息交换模式（基于WSDL2.0messageexchangepatternsEXP）：

消息被封装到消息交换Exchange中。

Channels消息通道

　　信道是用于从发送者发送消息到接收器的网关，发送者和接收者不知道对方，实现最大化松耦合，也可以被称为管pipe

（1）.SpringIntegration的通道是一个纯POJO模型：

（2）.JavaBusinessIntegrationJBI是一个创建消息交换的工厂，支持同步或异步。

Endpoints消息端点

　　一个端点是一个消息传递应用程序，它能够发送和接收消息的客户端，消息端点封装了消息系统，并与应用程序分离，也是其一部分，自定义了为特定的应用程序和任务的一般消息处理API

（1）.SpringIntegration实现：

代码实现如下：

　　消息通道最大的问题是：

通道容纳消息总会有一个容量，如果有大量消息发送到，而接受者并没有来得及消费，那么需要很大的容量保留这些消息，这是因为传统通道是一个顺序处理的模型，使用SEDA:

StagedEvent-DrivenArchitecture阶段EDA能够解决这个问题。

通过引入线程池立即响应消息处理。

　　事件队列接受传入的事件，事件处理器EventHanlder处理传入的事件，线程池提供了线程功能的事件处理程序，该控制器调节资源分配和调度动态。

Routing消息路由

　　消息路由器会从一个消息通道消费消息，并根据一组条件将其重新发布到不同的消息渠道.

Spring集成框架实现路由代码如下：

消息转换Transformation

　　　消息转换是转换一个数据格式到另一种的过滤器。

在消息处理前可以使用各种过滤器：

系统管理

　　　下图中Controlbus控制总线使用由应用程序使用的数据相同的消息传递机制，参考工作流设计，分离不同的管道进行传递消息。

消息模型

　　　区分为Publish/Subscribe发布者/订阅者或点对点Point-to-PointModel，也就是1:

N或1:

1的模型。

存储消息

　　保证一次且仅一次的消息传递，使用透明的消息客户端。

消息的事务性

　　　生产者将在事务上下文中发送一个或多个消息，生产者提交事务；消费者收到的所有消息，消费者提交事务。

SOA描述了一系列创建松耦合，基于标准，保持业务一致服务的模式和最佳实践，因为在描述实现和绑定之间实现分离关注，SOA提供了更高层次的灵活性。

SOA项目案例源码下载

这个项目由下面技术组成：

▪Groovy

▪Gradle

▪Springframework

▪Camel

▪CXF

该应用的场景是：

一个娱乐提供商要分决定奖励他们最忠诚的客户。

需求故事如下：

显示客户可申请的奖金：

作为客户，我希望看到根据我的频道订阅得到的奖励。

账户部门需要检查客户基于忠诚和计费状态基础上的资格量化状态。

需要提供一个RewardsService。

该服务接受输入客户帐号和订阅的组合渠道。

如果客户正确，获奖励RewardsService应该返回一个根据组合的订阅的奖励列表。

下表描述了频道订阅和相关的奖励。

客户状态部门正在开发一个EligibilityService，接受账户号码，检查客户是否合格eligibility，rewardService和EligibilityService交互顺序图：

下面是EligibiityService 的预期输出和rewardService的相应结果：

这个系统中主要是两个服务，rewardService和EligibiityService，rewardService的结果依赖于EligibiityService，他们之间的整合关系如下图：

rewardService通过ApacheCxf作为Restful服务对外对客户端公开，其内部和帐号部门的EligibiityService通过ApacheCamel整合。

Camel相当于一个消息系统。