我是个不怎么喜欢把自己一些积累的东西放在博客上的人,一般是放在自己的知识库中,好吧,你们或许说我自私...
最近公司高层提出做"智慧XX"项目,经公司资深架构师了解,需要用到SOA思想.基于以上,我着手了解SOA思想,公司没有资料提供,也没有人具体用过.都是些虚的理念.
据我为期一个星期的了解,了解ESB这样一个重要概念,我理解的:举个简单的例子,SOA就像一个画布,ESB就是画笔,最终绘制出一幅美妙的山水画.(或许每个人理解的都不同,中要的实践.)
ESB框架
类型 | 产品 | 公司 |
商业
| Oracle Service Bus (OSB) |
Oracle
|
Oracle Enterprise Service Bus (ESB) | ||
WebSphere Enterprise Service Bus |
IBM
| |
WebSphere Message Broker | ||
WebSphere DataPower | ||
Sonic ESB | Progress | |
ActiveMatrix Service Bus | TIBCO | |
开源
| Mule | MuleSoft |
ServiceMix/FUSE ESB | Progress | |
Synapse/WSO2 ESB | WSO2 |
开源Mule
优点:
- 社区活跃度
在开源ESB中,活跃程度最高,用户量大,不断推出新版本。
- 易用性
“让一切变得更简单”是Mule的宗旨。2次重构核心架构、推出接入云应用,消息流,基于模式的配置以及热部署;Mule IDE3.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.当采用了事务时,可以在异常处理策略中设置当发生异常时是继续提交还是回滚事务。
- 管理性
推出Mule Management Console(收费),管理、部署和监控应用。 - 文档
文档非常丰富,降低了使用门槛。
缺点:
- 集群非常弱
1.只能配置一个主实例和一个从实例
2.不支持flow和基于模式的配置
3.某些路由会丢失或者获得重复的消息
- Mule IDE
目前的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的web console管理OSGi的bundle
学习门槛高
用户文档和相关资料比较少
- ServiceMix迁移到OSGi
JBI2.0中增加了对OSGi的支持;
ServiceMix4.x完全基于OSGi,
ServiceMix3.x继续前行
- Apache孵化新项目
Camel
Karaf
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
- 基于Axis
借助于Axis的特性,能非常好的支持ws规范,ws-*。因此非常适合WebService的场景。
- 基于WSO2的Carbon平台
Carbon是WSO2的基础平台,它是一个OSGi框架,几乎WSO2的都基于它。
- 支持集群
集群中节点间的通信框架基于Apache Tribes(组通信框架)
相关信息持久化在内嵌的Derby中
支持一个主节点和多个从节点failover routing
在集群环境中,所有的请求只能被主节点接收,从节点只能作为备份节点。
- 支持流量控制
在单个ESB实例或者集群中,可以在服务级别配置流量控制。当请求数超过阀值时,ESB将被拒绝访问。 实现机制:借助组件Throttling Mediator
- 支持数据缓存
集群中的各个ESB实例共享缓存的数据。
当一个请求被ESB实例1处理完后返回响应信息,当再次向ESB实例1或者集群中其他的ESB实例发送该请求时,直接从缓存中取出原来的响应信息。
实现机制:借助组件Caching Mediator
- WSO2 Governance Registry
开源中最优秀的服务注册项目 - WSO2 ESB management console
创建和管理各组件(接入层、中介层和接出层);
图形化地方式统计系统资源(CPU,内存);
图像化统计ESB中各组件(接入层、中介层和接出层)接收发送消息的大小以及响应时间;
记录系统日志、SOAP日志;图形化显示消息的流向
- 文档丰富
WSO2提供了非常丰富的文档:
安装手册
开发手册
管理员手册
部署手册
大量的使用实例
缺点:
- 架构不够清晰
显得有点臃肿、不简洁、不够优雅
- 扩展性差
新增一个协议/transport非常困难
- 组件比较凌乱
对多种协议(HTTP,WebService,JMS,FTP,EMAIL)的支持,部分依赖于Axis2,部分依赖于synapse
目前针对ESB只是浅尝辄止,还需要深入研究.目前处于选择纠结中,不知道用Mule好,还是用WSO2,各有各的优势,WSO2有服务管理配置界面,不够都是英文版的,中文版资料好少好少.(每次看英文资料都特别,,,无奈,,,)
- 无缝集成CXF,ActiveMQ,Camel和ODE