本文发表在 rolia.net 枫下论坛自70年代数据库出现以来，就一直作为计算机系统在后台的主要力量，提供数据的可靠存储，查询。这么过年过去了，情况基本上还是这样，只是数据库越来越复杂，数据量越来越大，运行数据库的机器越来越多。数据库就像是定海神针，支撑着企业的复杂系统。
随着越来越多的人从事程序员这一职业，越来越多的企业应用系统被开发出来（：D）。而这些系统创造了大量的有价值的数据，并被可靠地保存在自己的数据库里。企业管理人员看到这么多业务被计算机处理并保存起来，大家都很高兴，我们有最先进的系统！然后就想看一下究竟系统里有些什么内容，结果却发现还是需要打电话才行，应为信息分散在各个部门，很难汇总在一张纸上。
接下来的结果就是数据仓库的流行：所有的企业都在建一个超大的数据库，然后把所有的业务数据全都装进去。这同时造就了四方面的迅速发展：存储，数据仓库软件，ETL系统，BI。数据库供应商都在忙着加入数据仓库的特性，或者就像sybase直接买一个IQ作自己的数据仓库方案。ETL方面infomatica突然之间一夜走红，自己都没明白怎么回事。BI的几大巨头各自赚得盆满钵满。这就是我们看到的当前的企业后端的一些情况。
在上述的方案给各大多数企业解决了问题的同时，一些高端的企业却发现这些方案不适合自己。典型的基于ETL的data warehouse都是batch方式在运行，很多ETL job 都是晚上才load一天的数据。一天的delay太长了，长到不用考虑；5分钟也太长；1秒钟在某些情况下可以，20毫秒比较好，当然再快些更好... 1毫秒如何？
如果你已经熟悉了基于数据库的系统，看到上面的要求可能会头昏：Oh, No!
是的，我们要的是这样一个系统：假定我有必要的权限，我想要企业内的任何一个数据源的数据，我可以在数据源不知道的情况下，得到小于20毫秒延时的实时数据。这就是本文要讲道的企业信息总线（Message Bus）。比如我是银行的compliance部门，我想看到某个branch的当前所有业务操作，我就连到企业系统总线上，开始订阅这个branch的数据。接下来这个branch的所有的新交易活动就都会小于20毫秒的延时显示在我的桌面上。
问题是...Message Bus不是什么新鲜东西，它已经存在很久了。和Message Bus 关系很近的MQ在90年代中期就已经出现了，基于Java的Messaging Middle ware更是数都数不过来，JMS甚至在很多非Java的系统里都得到实现。那我们要讲的是什么呢?
应用！Message Bus的作用要得到充分的体现，所有的系统都要围绕Message Bus来设计，来运行；所有的数据都要在Message Bus上。是的，本文要讲的是未来的基于Message Bus的企业软件架构。这里要强调的是企业软件架构，连接到Message Bus的系统数量多，并且数目是变化的，如果只是几个系统交换数据而采用Message Bus，那不是本文讨论的内容。
这种企业软件架构是一种SOA架构，messaging部分运行在Message Bus上，每一个连接到Message Bus的系统都是这个架构下的一个service来发布message或消费message。通常我们提到SOA时，总会包括http, soap, wsdl. 但在这种基于message Bus的架构，我们不需要http和wsdl，soap可以继续作为一种message格式，但不是必须。后面会讲到，soap格式在这种架构下并不是最好的选择。
在采用这种企业软件架构时，首先遇到的挑战就是当企业所有数据都放到message Bus上的时候，Message Bus能力是否足够处理这么多数据。我们先要有一个估算，企业的每秒钟数据量会有多大。这个每秒钟是指峰值数据，如果没有准确数据，可以用平均数据乘十来估算。有了这个数据，就可以开始设计系统的能力。比如某公司一天8小时全部的数据量是10亿条，每秒平均3.4万条。我们的Message Bus就需要每秒钟处理34万条记录的能力。一般来说，普通数据库能力在每秒钟数千条的样子，直接硬盘读写在几万条的样子。每秒钟34万条远非很大的数，有很多交易系统需要每秒钟处理几百万条记录。
要达到这样的性能要求，高端硬件是必不可少的。比如针对java的系统，有java硬件虚拟机。少了软件虚拟机的性能问题，每个盒子里几百个这样的虚拟机CPU，性能相当可观。1G的网络带宽不够，核心部分都用10G的网络。
软件的实现同样重要。当前Message Bus的产品Tibco EMS在普通机器上在不写硬盘的情况下只能处理两万条记录，在8CPU的机器1G带宽可以达到15万条。但这远远不能满足要求。有的Message Bus软件采用旁路操作系统，直接读写内存的方式，并且直接在网络上交换内存。这样应用程序就不需要访问网络来通讯，以此来提高效率。这样的系统可以达到每秒钟五百万条的能力。
为了有更好的性能，有些公司，比如Tibco，还有一家Ottawa的公司Solace，直接把Message Bus用硬件来实现，可以达到每秒钟一千万条以上的能力，和极低的延时（ < 0.001 ms）。更多精彩文章及讨论，请光临枫下论坛 rolia.net
随着越来越多的人从事程序员这一职业，越来越多的企业应用系统被开发出来（：D）。而这些系统创造了大量的有价值的数据，并被可靠地保存在自己的数据库里。企业管理人员看到这么多业务被计算机处理并保存起来，大家都很高兴，我们有最先进的系统！然后就想看一下究竟系统里有些什么内容，结果却发现还是需要打电话才行，应为信息分散在各个部门，很难汇总在一张纸上。
接下来的结果就是数据仓库的流行：所有的企业都在建一个超大的数据库，然后把所有的业务数据全都装进去。这同时造就了四方面的迅速发展：存储，数据仓库软件，ETL系统，BI。数据库供应商都在忙着加入数据仓库的特性，或者就像sybase直接买一个IQ作自己的数据仓库方案。ETL方面infomatica突然之间一夜走红，自己都没明白怎么回事。BI的几大巨头各自赚得盆满钵满。这就是我们看到的当前的企业后端的一些情况。
在上述的方案给各大多数企业解决了问题的同时，一些高端的企业却发现这些方案不适合自己。典型的基于ETL的data warehouse都是batch方式在运行，很多ETL job 都是晚上才load一天的数据。一天的delay太长了，长到不用考虑；5分钟也太长；1秒钟在某些情况下可以，20毫秒比较好，当然再快些更好... 1毫秒如何？
如果你已经熟悉了基于数据库的系统，看到上面的要求可能会头昏：Oh, No!
是的，我们要的是这样一个系统：假定我有必要的权限，我想要企业内的任何一个数据源的数据，我可以在数据源不知道的情况下，得到小于20毫秒延时的实时数据。这就是本文要讲道的企业信息总线（Message Bus）。比如我是银行的compliance部门，我想看到某个branch的当前所有业务操作，我就连到企业系统总线上，开始订阅这个branch的数据。接下来这个branch的所有的新交易活动就都会小于20毫秒的延时显示在我的桌面上。
问题是...Message Bus不是什么新鲜东西，它已经存在很久了。和Message Bus 关系很近的MQ在90年代中期就已经出现了，基于Java的Messaging Middle ware更是数都数不过来，JMS甚至在很多非Java的系统里都得到实现。那我们要讲的是什么呢?
应用！Message Bus的作用要得到充分的体现，所有的系统都要围绕Message Bus来设计，来运行；所有的数据都要在Message Bus上。是的，本文要讲的是未来的基于Message Bus的企业软件架构。这里要强调的是企业软件架构，连接到Message Bus的系统数量多，并且数目是变化的，如果只是几个系统交换数据而采用Message Bus，那不是本文讨论的内容。
这种企业软件架构是一种SOA架构，messaging部分运行在Message Bus上，每一个连接到Message Bus的系统都是这个架构下的一个service来发布message或消费message。通常我们提到SOA时，总会包括http, soap, wsdl. 但在这种基于message Bus的架构，我们不需要http和wsdl，soap可以继续作为一种message格式，但不是必须。后面会讲到，soap格式在这种架构下并不是最好的选择。
在采用这种企业软件架构时，首先遇到的挑战就是当企业所有数据都放到message Bus上的时候，Message Bus能力是否足够处理这么多数据。我们先要有一个估算，企业的每秒钟数据量会有多大。这个每秒钟是指峰值数据，如果没有准确数据，可以用平均数据乘十来估算。有了这个数据，就可以开始设计系统的能力。比如某公司一天8小时全部的数据量是10亿条，每秒平均3.4万条。我们的Message Bus就需要每秒钟处理34万条记录的能力。一般来说，普通数据库能力在每秒钟数千条的样子，直接硬盘读写在几万条的样子。每秒钟34万条远非很大的数，有很多交易系统需要每秒钟处理几百万条记录。
要达到这样的性能要求，高端硬件是必不可少的。比如针对java的系统，有java硬件虚拟机。少了软件虚拟机的性能问题，每个盒子里几百个这样的虚拟机CPU，性能相当可观。1G的网络带宽不够，核心部分都用10G的网络。
软件的实现同样重要。当前Message Bus的产品Tibco EMS在普通机器上在不写硬盘的情况下只能处理两万条记录，在8CPU的机器1G带宽可以达到15万条。但这远远不能满足要求。有的Message Bus软件采用旁路操作系统，直接读写内存的方式，并且直接在网络上交换内存。这样应用程序就不需要访问网络来通讯，以此来提高效率。这样的系统可以达到每秒钟五百万条的能力。
为了有更好的性能，有些公司，比如Tibco，还有一家Ottawa的公司Solace，直接把Message Bus用硬件来实现，可以达到每秒钟一千万条以上的能力，和极低的延时（ < 0.001 ms）。更多精彩文章及讨论，请光临枫下论坛 rolia.net