浅析主流商业和开源ESB产品.ppt

浅析主流商业和开源 ESB 陈 义 nereus.chen@gmail.com 概述 ß 主要内容： 介绍了主流商业和开源 ESB的发展趋势、可 借鉴的地方和其缺点。 主要介绍： Oracle Service Bus WebSphere Message Broker Mule ServiceMix/FUSE ESB Synapse/WSO2 ESB 主流商业和开源 ESB一览 类 型 产 品 公司 商 业 Oracle Service Bus (OSB) OracleOracle Enterprise Service Bus (ESB) WebSphere Enterprise Service Bus IBMWebSphere Message Broker WebSphere DataPower Sonic ESB Progress ActiveMatrix Service Bus TIBCO 开源 Mule MuleSoft ServiceMix/FUSE ESB Progress Synapse/WSO2 ESB WSO2 Oracle Service Bus (OSB)的架构图 OSB的发展趋势 ß 易用性增强 开发工具从 Web Console迁移到 Eclipse，支持图形化拖拽和便于调试 ß 性能提升 嵌入 Oracle Coherence(企业级的内存数据网格）产品，在特定场景 下为服务调用提供缓存，性能提升 80%。 ß 管控能力增强 采用自动化的生命周期服务治理，从服务设计、开发、部署和 运行期的整个服务生命周期内和 Enterprise Repository产品进 行自动同步，无需人工干预。 OSB可借鉴之处 ß 易用性 在 studio上直接集成测试功能，比如 studio能提供直接发送和接收 SOAP,JMS消息的功能，无需借助第三方工具，如 SoapUI和编写 JMS客户端代码。 ß 性能 采用 Cache机制，为静态响应信息提升性能。静态响应信息是指在一 段时间内不会发生变化的信息，如天气预报，手机套餐，人民币汇率 等，这些数据变化的周期通常是 1天， 1月。 实现手段：采用比较成熟的开源 Memcached或者轻量级的 JCACHE。 OSB的缺点 ß 依赖于 Weblogic ß 重量级的统一消息格式： 通过反编译 OSB的源码，可以看出 OSB将各种协议（ HTTP,WS,JMS… ）接入的消息统一转换为 SOAP Message，再通过 Xquery Engine对 SOAP Message进行 XML操作。 以下场景其缺点可立即显现： 1.HTTP下的大数据包 2.JMS Object类型的大数据包（最新版本 OSB才支持 JMS Object类型 ，之前只支持 JMS Text类型 依据： 对大数据包进行 XML操作比较耗 CPU 将大的 Object转换为 XML是个繁重的操作 WebSphere Message Broker（ WMB ） 的发展趋势 ß 简化开发 /部署架构 去掉 configuration manager，开发工具 /应用可以直接和 broker 交互。 ß 易管理 为管理员提供专用的管理工具 --WebSphere Message Broker Explorer，可以管理本地和远程的 broker和 queue manager， 同时提供了监控 broker性能和消息流的功能。 ß 简化开发流程 将常用的消息流场景进行了模板化，推出了基于模式的开发方 式，用户只需要配置相关参数即可。提供的模式分为两类：内 置（ built-in）和自定义（ user-defined）。 WMB开发 /部署架构的变迁 (V6.0) WMB开发 /部署架构的变迁 (V7.0) WMB开发 /部署架构的变迁 ß 去掉 configuration manager，开发工具 /应用可以直 接和 broker交互。 ß Broker的配置信息保存在 File中，可以 不依赖于 DB 。 ß 统一安全机制， queue managers and brokers均采 用 MQ queue的授权机制。 V6中采用的安全机制是 由 Configuration Manager提供的 Access Control Lists (ACLs)来管理授权的。 ß 统一 publish/subscribe机制， Message Broker V7 直接采用 WebSphere MQ V7的 publish/subscribe机 制 ，因此去掉了以前版本中使用 publish/subscribe 时所需的 User Name Server。 基于模式的开发方式 ß WMB提供的开发模式 将常用场景模式化 ，比如服务穿透 ,studio自动生成配置文件，自动完成 服务开发和服务组装的所有工作，用户只需填入参数。 http://publib.boulder.ibm.com/infocenter/wmbhelp/v7r0m0/index.jsp?topic=/com.ibm.etools.mft.doc/ac68260_. htm 基于模式开发方式的优势 ß 开发方式模式化 简化开发方式，减低了使用门槛，减少了使用中出现的概率。 ß 开发方式的转变 由自底向上转变为自上而下。 ß 自底向上 根据使用场景，逐个一步一步地开发组件，最后进行组装。 ß 自上而下 根据使用场景选择特定的模式，用户只需要配置参数（比如队 列名称， WSDL地址等）即可。 WMB可借鉴之处 ß 基于模式的开发 将常用的场景模式化，比如服务穿透场景。 现在开发一个服务穿透的场景所需步骤： 1.创建并配置业务服务 2.创建并配置代理服务 3.在代理服务中关联业务服务 如果采用模式开发，其步骤： 1.创建服务穿透模式并配置业务服务和代理服务 也许可以将步骤减少到一步。 WMB的缺点 ß 重量级的架构 传统的 EAI架构，必须依赖于 WMQ。 ß 笨重的 ESQL ESQL是 WMB用于处理消息流的一套特有的扩展 SQL的语言，功能很 丰富，语法比较多，但学习门槛较高。 相比直接通过 java方法操作消息，显得格外笨重。 Mule的架构图 Mule的发展趋势 ß 社区活跃度 在开源 ESB中， 活跃程度最高 ，用户量大，不断推出新版本。 ß 易用性 “ 让一切变得更简单 ” 是 Mule的宗旨。 2次重构核心架构、推出接入云 应用，消息流，基于模式的配置以及热部署； Mule IDE3.0，将支持 图元拖拽，简化开发。 ß 扩展性 增加一个新协议非常简单，只需实现 5个接口类即可。 ß 管理性 推出 Mule Management Console（ 收费 ），管理、部署和监控应用。 ß 文档 文档非常丰富 ，降低了使用门槛。 Mule可借鉴之处 ß 基于模式的配置 基于 web service proxy模式的 web service的穿透场景的配置（ 配置非常简单， 3个属性 ） Mule可借鉴之处 ß 易扩展 新增一个协议 /transport只需实现 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 Mule可借鉴之处 ß 异常处理框架 异常策略设置级别 : model和 service 异常处理方式： 1.将异常路由到指定的目的地 2.根据异常类型过滤异常，并路由到指定目的地 3.设置重试次数 4.当采用了事务时，可以在异常处理策略中设置当发生异常时是继续 提交还是回滚事务。 Mule的缺点 ß 集群非常弱 1.只能配置一个主实例和一个从实例 2.不支持 flow和基于模式的配置 3.某些路由会丢失或者获得重复的消息 ß Mule IDE 目前的 IDE只提供 XML级别的编辑，还不能实现图元的拖拽 ß 稳定性 开源项目的通病，需要在测试场景下进行验证 ServiceMix的架构图 ServiceMix的发展趋势 ß JBI2.0规范发展缓慢 IT巨头 Oracle,IBM投了反对票，目前只有几家小公司投支持票 ß ServiceMix迁移到 OSGi JBI2.0中增加了对 OSGi的支持； ServiceMix4.x完全基于 OSGi， ServiceMix3.x继续前行 ß 孵化新项目 Camel Karaf ServiceMix的优势 ß 无缝集成 CXF,ActiveMQ,Camel和 ODE 因为 ServiceMix,ActiveMQ,CXF,Camel都是 FUSE的开源产品 ß JBI的优势 组件 BC,SE可以在任何 JBI容器（比限于 ServiceMix）中直接运行， 复用性强 ß 基于 OSGi 具备 OSGi的优势：模块化，热部署，易扩展 ß 基于 Karaf 提供了非常丰富的命令，管理、部署和监控 ServiceMix ServiceMix的缺点 ß JBI规范太复杂 已被主流中间件厂商抛弃 ,没有受到业界的青睐 ß 架构复杂 由于 JBI的复杂性所致，其架构并非轻量级 ß 缺少 IDE的支持 必须手写大量的 XML配置文件 ß 缺少 governor的支持 ServiceMix4只是借助 Flex的 web console管理 OSGi的 bundle ß 学习门槛高 用户文档和相关资料比较少 Synapse/WSO2 ESB运行期架构图 WSO2 ESB=Synapse+Monitoring+Management+Governance Registry Synapse/WSO2 ESB的发展趋势 ß Synapse发展缓慢 发展缓慢，新版本中没有增加比较有亮点的功能特性 ß WSO2 ESB发展迅速 对 Synapse增加了 企业级特征 ： 1.基于 WSO2的 Carbon平台（ OSGi框架） 2.支持集群、负载均衡和 failover routing 3.支持流量控制和数据缓存 还增加了 外围产品 ： 1. WSO2 Governance Registry，服务注册产品 2. WSO2 ESB management console， ESB管理控制台 3. WSO2 Carbon Studio，开发 ESB的 studio WSO2 ESB的优势 ß 基于 Axis 借助于 Axis的特性，能非常好的支持 ws规范， ws-*。因此非常适合 WebService的场景。 ß 基于 WSO2的 Carbon平台 Carbon是 WSO2的基础平台，它是一个 OSGi框架，几乎 WSO2的都基 于它。 WSO2 ESB的优势 ß 支持集群 集群中节点间的通信框架基于 Apache Tribes（组通信框架） 相关信息持久化在内嵌的 Derby中 支持一个主节点和多个从节点 ß failover routing 在集群环境中， 所有的请求只能被主节点接收 ，从节点只能作为备份 节点。 WSO2 ESB的优势 ß 支持流量控制 在单个 ESB实例或者集群中， 可以在服务级别配置流量控制 。 当请求数超过阀值时， ESB将被拒绝访问。 实现机制：借助组件 Throttling Mediator ß 支持数据缓存 集群中的各个 ESB实例共享缓存的数据。 当一个请求被 ESB实例 1处理完后返回响应信息， 当再次向 ESB实例 1 或者集群中其他的 ESB实例发送该请求时，直接从缓存中取出原来的 响应信息。 实现机制：借助组件 Caching Mediator