市场主流ESB的产品比较较全.docx
- 文档编号:7215750
- 上传时间:2023-01-21
- 格式:DOCX
- 页数:13
- 大小:222.11KB
市场主流ESB的产品比较较全.docx
《市场主流ESB的产品比较较全.docx》由会员分享,可在线阅读,更多相关《市场主流ESB的产品比较较全.docx(13页珍藏版)》请在冰豆网上搜索。
市场主流ESB的产品比较较全
述
介绍了主流商业和开源ESB的发展趋势、可借鉴的地方和其缺点:
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 普元ESB 国内非常成熟的ESB产品,在电信、金融领域大量应用,性能卓越。 真正意义上实现了服务从开发、部署、执行、监控、优化的全周期管理! •可靠的总线架构,可快速部署并支撑业务系统。 •业务化的服务注册与管理,并可实时监控接口服务调用情况。 •强大的环境融合与协议适配能力。 优点: 高性能: 根据具体业务,可实现个性化的流量控制、IP拦截、报文校验等特性。 在中国电信OIP集成平台中,支撑了以CRM、BOSS为核心的50多个应用系统。 在上海移动ESB集成平台中,目前日均交易量9000万笔,峰值TPS达到了6000。 高扩展: 开放的API接口,使得ESB产品更加容易和企业内部现有的系统有机的融合在一起,譬如: 与现有安全系统的融合、与现有IT网管系统的融合 业务化: 丰富的QoS质量指标,完备的日志信息和方便的进程管理机制,同时还可以依托服务运行的轨迹信息形成跨部门的业务流程的监控。 高可靠: 采用取了SEDA、NIO等业界先进的技术以及松散的集群部署方式来保障ESB整体基础设施以及关键服务的可靠性,从而提高了ESB的容错性 缺点: 对复杂报文处理的支持不佳。 采用SEDA支持高性能配置,但性能调优比较复杂,需要掌握专业的技能 采用Studio的服务开发、调优、部署方式,不能支持web浏览器
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 市场 主流 ESB 产品 比较
![提示](https://static.bdocx.com/images/bang_tan.gif)