转载

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的支持和扩展，但是前面谈到过，很多集成场景都需要通过实践经验后抽象，以达到可以灵活通过设计和配置的方式来完成服务集成的原因。

原文 http://blog.sina.com.cn/s/blog_493a84550102w8yl.html

正文到此结束