神刀安全网

ESB研究总结

今年工作的一个重点就是要完成新规划的ESB产品的研发,在V1版本中完全是自己从头做起,重点是实现服务代理和服务全生命周期管控。而对于V2版本将重新研发,重点是基于ServiceMix引擎底层进行常见服务封装的快速配置和定制,实现引擎部分和管控平台的分离。之所以选择ServiceMix做为底层,主要还是考虑到Karaf和Camel两个核心组件。通过Karaf开放的OSGI框架使得整个底层引擎更加组件化和服务化,同时通过Camel来实现对多种业务场景的适配和扩展开发。

在第一个阶段重点还是需要实现基本的代理服务,路由服务,数据库适配下的查询和导入服务,消息发布订阅。所有服务场景应该都支持SOAP Webservice和Http Rest Service。在整个实现过程中会使用到CXF, CXFRS两个核心组件,而对于数据库适配通过JDBC和SQL组件进行。对于消息发布订阅则通过ActiveMQ消息中间件进行。在整个实现过程中由于考虑到引擎和管控平台本身的拆分,即所有消息日志信息都先持久化到本地日志文件,但是消息日志也可以写入到ActiveMQ中,通过ActiveMQ再异步写入到管控平台服务运行实例库。

对于日志的记录,一方面是在Route设计的时候增加Log组件节点,一方面是考虑通过对CXF的拦截器进行扩展和定制,以获取到我们需要的服务消息的输入和输出信息。每一次服务的运行都应该有独立的服务实例号,为了减少本身对WSDL服务契约的影响,考虑是在消息头中增加服务运行实例号的返回,服务实例号则通过UUID来生成保证其唯一性。

由于ServiceMix的底层本身是Karaf组件框架,因此对于整体架构中的集群处理则采用Karaf本身的解决方案,即通过Apache Karaf集群(Cellar)来实现集群。通过集群一方面是实现整体的高可用性,一方面是实现在集群中一点部署可以多点同步回复分发。

对于定时服务的调用,如果简单的可以直接通过配置Timer节点来实现服务的定时触发和运行。而对于较为复杂的场景,我们可以使用Quartz调度组件来实现,即需要对Quartz组件进扩展,来灵活的配置各自定时服务的调度任务,同时还需要扩展调度组件运行监控能力。在linux下可以看到chronos是一个常用的作业调度和监控平台,而对于Quartz调度组件则需要扩展来具备chronos作业调度的基础能力。

对于Apache Camel的设计,由于Blueprint配置文件模式下存在较大的局限性不容易扩展,因此在整个平台中的服务设计我们采用Spring XML文件+Java类的方式来实现。即每一个服务设计完成后都为生成相应的配置文件和Java类文件,然后再自动打包为Jar包,该Jar可以直接放到SeriveMix中间件中进行部署和发布。

Camel具备足够的扩展性以支持大量的组件,在基本服务集成能力完成后,需要考虑的适配包括:

1)通过Netty,ZeroMQ或RabbitMQ来实现对TCP消息的接入和适配。

2)通过FTP和File组件来实现对文件传输的服务集成。

3)通过我们自己的大数据采集工具,将其作为JavaBean或通过exec组件调用来进行大数据集成能力。

4)通过Bean组件来灵活定制我们新增加的Java集成类,可以做为Route节点引入。

5)通过Dozer组件或通过XSLT组件来实现消息流之间的转换和映射,这本身是camel比较欠缺的功能。

6)通过开源的Hyperic HQ或者开源的Nagios来实现对整个Servicemix集群,Camel节点的实时监控。

由于Camel本身足够的可扩展性可以看到,以上内容都较为容易通过定制后扩展,当前Camel最新版本是2.17,对于2.18版本也正在研发中,也可以看到Apache本身对该开源项目的重视。同时可以看到当前的Fuse中间件本身也是基于ServiceMix和Camel进行的商业化扩展,同时Fuse本身也偏重,在Jboss中的设计器灵活可配置性也较弱。真正感觉做的比较好的还是Talend对Camel的支持和扩展,但是前面谈到过,很多集成场景都需要通过实践经验后抽象,以达到可以灵活通过设计和配置的方式来完成服务集成的原因。

转载本站任何文章请注明:转载至神刀安全网,谢谢神刀安全网 » ESB研究总结

分享到:更多 ()

评论 抢沙发

  • 昵称 (必填)
  • 邮箱 (必填)
  • 网址