ESB总线架构图（借用）

 根据近期对开源ESB产品的研究，已经对Oracle和Tibco的ESB总线产品的实施经验积累，对ESB总线的核心产品架构有了进一步的清晰认识，将ESB的核心架构整理为上图，上图中看到的内容也是做为一款完整的ESB服务总线产品所必须要具备的功能。

首先整个架构体系里面分为三个组件或子系统，即偏开发态的设计器，偏运行态的ESB核心引擎和SOA治理管控平台三个方面的内容。以上三者组合和集成形成一款完整的ESB服务总线产品。对于三者之间的关系可以简单的描述为：

首先对于ESB总线引擎是一个完全相对独立的内容，即常说的ESB的Server端，一个完整的ESB引擎一般都会集成消息中间件的能力。类似ServiceMix的ESB可以看到核心是基于OSGI运行框架下的ActiveMQ+CXF组件来实现基础核心功能。没有设计器和管控平台，引擎也可以独立部署和运行，即可以自己写代码或写配置文件，将开发好的服务包部署到ESB引擎环境里面。

一个ESB引擎本身也需要部署在application server里面，即引擎可以部署在类似weblogic,jboss或tomcat等各种中间件容器中。而对于很多开源的ESB可以看到引擎本身已经集成了更加轻量的Jetty做为服务运行容器。其次对于单独的引擎应该是不需要DB数据库的，即ESB服务运行的log日志审计可以存储在服务端的log日志文件中，只有当安装了管控平台后，我们可以在server上部署代理，准实时的将运行日志信息采集和存储或db数据库。

其次是ESB设计器，设计器是属于开发和设计态的一个内容，重点则是对http，rest，已经服务+DB，消息等各种内容进行集成。当前类似talend和mule等都提供了很强大的服务设计器能力。即我们常说的服务代理，http和soap服务集成，数据库适配，路由，消息集成和适配，分支和条件判断，异常处理，任务作业，组合服务等都是设计器需要支撑的核心能力。

设计器设计完成后的内容可以导出为部署包，对于部署包则可以部署到ESB服务引擎中。当前的做法主要有两种，一种是在设计器中本身就提供连接到服务器进行远程和自动部署的能力，另外一种做法则是在SOA管控平台里面提供服务部署和管控的能力。

设计器往往是给服务开发和设计人员使用，目的是为了简化服务的开发和封装，提升开发效率，一个开放的架构模式最好的方式就是脱离了设计器仍然可以通过其他手工方式进行服务的开发和封装，而不是被设计器绑定。而对于设计器本身的输出，一种是转化为了普通的java代码，还有一种方式是设计器的输出为xml配置文件。可以看到对于xml配置文件这种方式更加方便和解耦，在设计器产生部署包或测试运行的时候，设计器端首先是读取xml配置文件的内容再动态生成和部署服务。

最后一个内容是SOA管控平台，主要的作用是实现服务的全生命周期管理，包括服务的元数据管理，服务目录库，服务的申请，服务的开通和鉴权，服务运行日志审计和监控，服务运行分析，服务预警，服务SLA等各种功能。即SOA管控平台提升了对ESB引擎本身的管控和治理能力。

管控平台本身也是相对独立的内容，可以看到对于管控平台和ESB引擎本身是彻底解耦的，即如果实施了管控平台，则只需要在ESB引擎上启动管控代理和相关的配置参数，在这种模式下ESB引擎本身运行态的运行信息即可以准实时的采集到管控平台中进行存储和统计分析。

当然，对于管控平台产品的服务权限管控，服务动态路由设置，服务流量控制等内容，也会影响到ESB引擎在运行态的运行。而通常ESB总线的做法则是对于log日志，安全，流量控制等都是ESB总线的inbound和outbound上的可插拔式的拦截器，通过这种组件动态装载和配置启用的模式来彻底实现管控平台和ESB引擎的解耦。

对于ESB总线产品本身也应该是符合SOA架构的，即需要实现组件化和服务化，实现服务组件本身的动态加载和热部署，当前类似servicemix在这点上的做法是值得借鉴的，即基于karaf+osgi模式来实现一个组件化的运行框架和环境，极大的方便后了整个运行态的动态管控能力。