最近经常听到有人说数据总线的概念，因此今天做下对这个概念的进一步解释和说明。在我前面头条文章中可以看到，对于传统企业内部的应用集成，我一般只会用两个概念，一个是SOA集成平台，一个是ESB企业服务总线，基本不会用数据总线这个概念。

要谈数据总线，还是先回顾下企业内应用集成场景。

企业集成场景和服务实现

对于ESB服务总线，估计大家都清楚更多的是适合承载业务服务，而有业务服务的一个典型特点就是粗粒度，业务并发量可能很大，但是服务本身本次传递的数据量不大，而是调用时间快的话连接资源和内存资源都可以做到快速释放，因此不会对ESB总线本身造成太大的性能压力。

业务交互的实时性

如果ESB总线更多的是承载业务服务和应用集成的话，那么大部分服务都应该是实时调用和交互，其中又有两个场景，一个是业务单据在生效后实时分发到下游的业务系统（该情况下数据落地）；另外一个场景就是实时的查询其它业务系统的外部服务能力（在这种情况下数据不落地）。

对于实时交互的服务往往数据量都不应该太多，完全属于ESB服务总线采用WS服务能够解决的范畴，当然你既可以使用SOAP WS也可以使用Rest WS都可以。对于模糊查询数据不落地场景，则可能数据量大，在这种情况下往往采用分页服务的方式来解决性能问题。

对于没有业务实时性要求的场景，往往更多走的是数据集成和同步，类似传统的数据交换，因此这类服务更多的是走数据服务模式，不论是查询服务或者导入服务，都可以作为定时服务进行。这也是传统企业在业务系统间进行接口集成最常用的方式，但是带来最明显的问题就是业务实时性无法满足要求，并可能导致同一时点数据在多个系统间不一致的情况。

服务调用并发量和数据量

服务调用并发量也是我们衡量服务实现方式的一个关键考虑因素，对于大并发调用的服务虽然也可以采用类似ESB服务中的缓存机制提升性能。但是更多的仍然要考虑在大并发情况下对端目标系统本身的承载能力。对于并发量大的服务调用，如果数据量小往往响应时间容易控制。但是如果数据量很大，则整个服务连接保持时间长，同时JVM内存消耗巨大，这样很容易导致ESB JVM内存溢出的场景错误。

因此对于数据量大的服务调用往往并不推荐走ESB，而是走ESB+ETL结合的模式，即实际的数据传输走传统的ETL点对点传输完成，而ESB接入服务的只负责通过服务接口调用实时发起数据传输任务。

还有一种服务大并发调用，对于目标系统无法做到及时响应的场景，在这种情况下可以通过ESB的消息中间件进行服务调用流量控制和削峰处理。其实现本身又有两种方式，一种是走类似JMS消息中间件的基本处理，变同步服务为异步消息集成服务，另外一种就是仍然走同步WS服务，但是在出口端对ESB服务进行流量控制。

对于大文件传输，往往还有独立的文件传输平台产品，类似在Oracle SOA 12c版本中已经单独新增加了MFT文件传输模块来实现大文件传输，以及传输过程的端到端监控能力。当然MFT文件传输本身也是可以和ESB服务进行集成的，通过ESB服务来触发实时的文件传输，这和ESB服务和ETL传输是一个道理。

场景总结

通过前面描述可以看到对于ESB总线更多是对于大并发小报文的业务服务类API接口的集成，而对于大数据集成，大文件集成往往需要借助类似ETL工具，MFT文件传输平台来完成。但是对于SOA集成平台这个说法往往会同时包括了服务集成，消息集成，文件集成，大数据集成等各种集成能力。

对数据总线概念的进一步说明

在谈数据总线的时候，首先还是要说明下总线的概念。

总线英文名称为Bus，简单来说是一个类似Hub的集中点，总线（Bus）是指计算机组件间规范化的交换数据（data）的方式，即以一种通用的方式为各组件提供数据传送和控制逻辑。

也就是说总线核心作用是消息和数据的交换。

对于很多年前在ESB总线还没有大量应用的时候，经常会谈到数据交换平台这个概念，实际上数据交换平台很类似数据总线的概念。

这个交换可以是消息报文，也可以是大数据，也可以是文件等各种类型。但是不管是哪种类型，总线一个典型特征就是所有的数据都必须流经过总线这个Bus管道。也正是由于数据流通过了Bus，那么总线可以对所有的消息，数据进行统一的拦截。

这个拦截点可以进行一系列的安全，日志，审计，限流等各种管控操作。

那么对于ETL是否能够作为数据总线？

ETL大家都比较清楚，能够实现数据采集集成，清洗等各种数据集成能力。但是在传统的ETL概念里更多是配合BI系统或工具使用，对于采集的数据也是直接导入到BI目标系统。也就是ETL不是一个独立的平台或系统，仅仅是BI系统提供的一个数据采集和集成工具，同时ETL也不是完成业务系统间的数据集成，而是统一完成业务系统-》BI系统间的数据采集。

从这个意义上ETL还不能算严格意义上的数据总线。

其次，ETL工具一般只能够定时调度数据抽取，而无法通过接口服务实时调用进行数据采集，这个本身也是ETL工具本身的一个弱点。

在前面谈SOA集成平台的时候谈到，SOA集成平台一般会通过ESB总线+ETL共同来实现大数据集成能力。即ETL负责数据流，而ESB总线负责管控流，管控和数据流进行分离。类似Oracle产品中的ODI实现。

那么对于ESB+ETL结合的模式是否就是数据总线？

数据总线核心仍然是服务集成+大数据集成两个方面的能力，而这两个能力也正是通过ESB和ETL来提供。因此如果这两个内容融合的很好，那么可以理解为数据总线，如果融合的不好，那么会发现很多管控操作需要同时登陆两个产品去处理，那么实际和数据总线希望的目标还有差距。

综上，一个完整的数据总线应该具备如下能力。

最基本的ETL工具的能力，支撑各种DB数据库的适配

• 支撑当前主流的非结构化数据库集成
• 数据对象建模和对象定义
• 任务定时调度，规则调度和调度监控能力
• 和SOA服务进行集成，支持实时调度能力
• 数据安全和数据审计
• 数据质量管理能力
• 简单的数据转换，数据映射等能力

如果你是传统的ETL工具，那么需要剥离后形成一个独立的产品并提供面向开发者的管控治理平台，如果是ESB总线，那么就需要扩展大数据集成能力。不论是哪种方式，数据总线都需要做到对数据的记录，安全和日志审计。这是中心化架构带来的一个大好处，否则还不如完全去中心化点对点模式。