传统的企业数据总线(ESB)和目前的分布式消息系统有什么区别？两者的关系是？

传统的企业数据总线(ESB):Oracle SOA Suites,Apache ServiceMIX,JBOSS EBS,等

分布式消息系统：kafka,RabbitMQ、Apache ActiveMQ,MetaQ等

首先我们看到ESB是用于系统间集成的，那么分布式消息系统能否用于系统间集成，答案是当然也可以，但是只支持通过消息方式进行集成，而系统间集成的场景包括了很多，比如http，ftp，文件，socket，数据库，消息，其它商业中间件等，这些复杂场景就需要用到ESB去集成。

其次分布式消息系统重点往往并不在系统间集成，我们看到其核心使用场景已经变化到一个系统内部的多个组件之间的集成和消息协同，类似我们看到的openstack, cloudstack包括了消息中间件。也看到在大数据hadoop框架下，也经常用kafka去做和flume, storm等的消息集成。消息集成优势是彻底异步解耦，预防消息丢失，其次消息中间件由于内部有MQ机制，可以通过缓冲实现对大并发访问的支持。

再来看ESB和分布式消息系统间是一种相交关系，即一般ESB本身也会带消息中间件来实现消息集成，比如对于Java ESB一般会带JMS消息中间件。但是互联网大并发场景下衍生了更多的分布式消息系统，包括前面说的kafka，已经支持AMPQ具备更高性能和吞吐能力的ZeroMQ和RabbitMQ，而这些消息系统在ESB中往往不包含，但是当前一些新的ESB产品已经增加适配器能够更好的和这些消息系统进行适配。

最后看下具体的场景，如果是在一个业务系统内部使用有一些消息要进行分布式处理，采用消息系统就足够了。但是如果场景变化来你需要外部其它系统产生数据给你，然后你再通过处理推送到自己的消息系统里面，那么你暴露给外表的接口一般就不适合暴露消息系统本身的API给对方的了，比如我们需要暴露http rest的服务给对方调用等，这个时候往往就需要自己再来开放对应的Service服务，如果你用ESB你可以看到这些内容往往并不再需要写代码开发，而只需要在ESB上进行相应的适配即可将底层能力保留位服务并发布出去。

https://www.zhihu.com/question/35905864?sort=created