时间过得很快，ESB（数据集成平台）项目本月就要上线，之后转入运维。
现在总结一下,数据集成平台有以下特点：
1、高效稳定的消息处理
2、简单易用的数据管理
3、接口服务整体企业架构高可用
4、多协议的支持运行良好
1，高效稳定的消息处理，其实需要你去关注接口设计的合理，每一次接口的消息流动都在可控范围内，不会有某个巨无霸接口拖垮平台性能。平台要达到这个特点，需要我们关注生产订单发布接口，按照我上一个整车厂的实践经验（TermCenter的PLM、SAP的ERP、RockWell的MES 、SOA的ESB这些组件同这次项目完全一致），这个接口，就是所有接口中数据最大的接口，只有这个接口平稳了，整个ESB平台才能平稳。
上一个项目，这个接口我对它运维了2年，因为它设计不合理，每次ERP发出的订单数量较大时，ESB乃至下游系统接收都会不顺利。所以优化需求很快就被提出，ERP被要求重新设计接口数据量。我提供了整套包含下游系统校验的优化方案（ 其实在方案提出之前，我早早就在ERP系统中用ABAP测试了新的优化方案，并和ESB项目组一起对新方案做了完整的测试）。
OSB资深开发顾问因为没有这么相似的项目经历，一开始没有意识到这个接口必须用优化方案才能可行；事情往后发展，经过测试数据，大家很快发现，如果不优化这个接口，显然是不行的（ESB对生产订单全放一个包里，再对大报文XML做foreach运算。平台的上限只能处理150个订单，而我们工厂一天三班是800个订单）。还好，我得到了项目架构师的鼎立相助，最后我们使用了优化的方案。 准确的描述这个技术问题，是任何语言对海量的XML大文本数据做foreach运算总是很糟糕，而如果数据的载体不是XML文本，是内存变量，那才是正常的解决之道。现在回忆起来，有时候双方博弈的结果，其实也取决于你的决心。
优化方案完成后，我们对该接口做了压力测试。接口一次传输6000个生产订单，ESB、MOM、LES下游系统传递并接收，全部用时90分钟。并且一个订单没有丢。而上一个项目，这个接口传输100个订单，我也要去生产计划员那儿蹲守半个小时，以确保正常完成。
2、简单易用的数据管理，需要关注消息放数据库的大小
6000个订单的压力测试做完，很快又出现了新的问题，用来存放消息的数据库爆了。
我使用我自己的工具oracle space tool（工具说明详情见我blog和github） 一直在关注ESB数据库的大小。
一个订单的XML数据是2M,平台设计是保存到数据库里，消息的进出都被保存一次，广播到LES和MOM也被保存一次，最后就是这个接口服务的消息被保存了4份到数据库里。 压力测试当天，我们做了2次6000个订单的测试。数据库空间涨了100个GB。 按这个做法肯定是不行的，优化数据库消息存储的需求很快被提了出来。熊可也是很厉害的，很快找到了解决办法。只用了短短一周时间，在平台和数据库之间启用了压缩功能圆满解决了这个问题，压缩后的数据量缩小了100倍。这个数据量是我们平台运维可以接受的。
3、接口服务整体企业架构高可用，需要关注各服务器集群的连接架构
不但ESB内部的服务器集群是多个主机没有单点，包括连接到其它集群服务器的链路也是多连接的，我称为梦幻架构。详情请见blog
4、关注MSMQ消息客户端的代码使用
Oracle server bus的优势其实很大一块体现在它对多个协议的成熟组件的支持。单单在MQ这个协议上，它就支持JAVA的MQ客户端和.net的MQ客户端接入，这样JAVA和.NET2大世界都被OSB的MQ接入了。
LES微软项目组找到我们，每收5个数据包会掉2个，这个问题有点夸张。他们使用的是.net的MQ客户端接入，用的组件是oracle提供的标准的dll。
每一个CSDN的程序员可能都希望进入微软或有相关工作经历为耀，其实我也是；在微软项目组面前玩C#,无异于班门弄斧。
但是LES生产系统马上上线，这个问题需要快速解决。我用C#做了一个测试程序，模拟LES的场景使用oracle提供的标准dll库，程序跑了一上午，心跳+收发MQ包2000个，一个也没有掉。（详情请见blog）
我们很快锁定了问题，lance笑了，不是oracle server bus平台的问题。
To be continue........