甲方项目经理详细讲述整个项目的历程，内中包含大量企业级ESB的技术细节，抛砖引玉供大家分享。
金康汽车数据集成平台项目从2018年6月15日项目启动，通过项目组近6个月的努力，于2018年12月28日完成了项目建设阶段要求的各项工作顺利上线运行。
目前金康数字化工厂业务系统已经全面接入集成平台（产品研发PLM、企业管理ERP、生产制造MOM、物流管理LES、供应链管理SCM、泛营销CEO、总部财务NC等等）。6个月项目建设阶段完成了接口开发97个，数据服务35个，对于后面的持续需新增开发需求，项目在投产运维阶段继续提供支持，保证完成新增的开发需求。
第一个里程碑，总体设计方案
金康数字化工厂承载了全部小康人的希望，小康集团对金康数字化工厂也是不惜成本的投入，力图打造中国最现代化的汽车工厂。几天前，我经过生产车间，看到了焊装车间95%的机器人覆盖率，总装车间大量的AGV小车无人运送物料，这些在我参观过的宝马铁西工厂也不多见。这样的一个中国最现代化的工厂，在信息化上的要求也是非常之高。按刘总的高标准要求，我一版又一版的更新项目方案，每家供应商都派出来最好的顾问协助我。我记得就oracle一家，售前顾问就前后换了三波人。项目方案版本数字越来越大，但仍然不能达到要求。我当时的感觉，这个项目太难了。还好，赵部长全力来帮助我，Oracle也派出了中国的负责全亚太的顶级架构师李玉奇。经过夏秋冬三季，设计方案定稿的版本号是第25版。我们完成了数据集成平台项目的第一个里程碑，总体设计方案。
第二个里程碑，蓝图功能设计
RFC协议
项目伊始，我们的资深oracle原厂技术顾问昊哥进场，其实他还呆在成都家里，晚上就被我时常骚扰。在项目开始之前，我一直在要求并证实OSB采用RFC协议连接SAP系统的可行性。记得昊哥给我的原厂指南SAPIA，通读了十多遍，但是上面的例子都是IDOC的，不过昊哥拍着胸脯说，他就在前一个项目作过，没问题。
开发系统安装完成，我马上对这一功能进行了验证，SAP RFC adapter支持得很好。这就意味着同SAP的连接方式可以用强大的RFC协议实现，它有很多好处：1、长连接直接socket传递，可传递的数据量大；2、RFC JCO客户端也是SAP提供的原生组件，很稳定，也支持掉线重连；3、使用SAP端使用RFC开发是最普遍的方式，几乎没有ABAP不会RFC的，为后面的SAP接口运维提供诸多便利。 我为什么知道这些，因为我之前自己也基于RFC NCO开发有中间件(百度一下SAPsender)，对这个领域自认研究比较深入。当然我的中间件只实现了SAP同各种数据库的交换数据。作不了MQ，做不了XML映射，作不了众多的adatper数据协议适配器，甚至从根本来说都不是SOA的。
实施的方法论
SAPsender其实已经经历了4个小的项目，其中遭遇到一个项目的场景是这样：经销商的整车库存在DMS数据库中，工厂生产的整车库存在ERP系统中，潍柴总部GOS系统需要统计潍柴汽车子公司全部的整车数据，需要一个中间件程序到DMS取数，再到ERP系统中取数，最后按车型统计这些库存数放入GOS中。ps配图
SAPsender基于强大的linq,作点数据的匹配处理那是小菜一碟,这个功能也很快就上线了，程序每天凌晨自动到DMS取数，再到ERP取数，合并放入GOS。基于linq的强大，再加之并行计算的处理功能，计算量几亿次的字段对比匹配，程序只工作几分钟就完成了。程序定时作业运行起来也不需要人去作什么，一切都很完美。
但在某一天，GOS系统管理员程序突然告诉我，昨天的数据没有收到，这是要给老板看的报表数据，差一天的一年都不准，会导致老板看不到这个数据。因为这个程序就是我自己写得，我通过调试，很快就发现了问题，原来DMS系统表里的数据变了，比最初时测试的数据多了很多，我的程序处理新的某条数据出错了，导致当天数据没有收集到GOS中。当然，很快我更新了SAPsender,它在当天又正常工作，把缺失的数据传入了GOS系统。但是如果我当天不能纠正，因为库存数据每天时变化的，GOS就会查缺一天的库存数据或再也找不准那一天的数据了。
我发现这是一个死结，首先中间件程序测试的时候，业务给出的数据量都很小，你测试不到全部的数据。上线运行后，每天的业务数据越来越多，中间件程序去按负责的业务逻辑加工数据难以避免会出错，出错后这块数据就缺失了，这种机制下，中间件会很不稳定。
斯欧的于总在介绍他们的总线在吉利汽车的成功案例时说到，他们的ESB产品只是数据的搬运工，不加工数据。我想这就是他们在吉利能够成功快速完成800个接口集成的最佳实践的精髓。
基于前面的经验，我也要求在本次集成项目中，不到万不得已OSB不要去作业务功能和业务数据的加工，同业务相关的处理应该由业务域系统自己来作更好。
OSB架构的内
Oracle service bus简称OSB，在生产环境，我们部署了6台基于虚拟机的linux，上面安装OSB服务和OSB的容器weblogic服务。还部署了2台消息落地和数据展示的服务器。
一旦OSB服务器处理完一次数据消息传递，交换数据的SOAP XML报文，被OSB服务器作为MQ的客户端发送到了2台消息落地服务器上。这2台服务器上有消息落地的MQ队列。这样作的好处是避免直接落地带来的数据库磁盘IO负载，减少消息落地对服务性能影响。让6台OSB的一切消息传递工作都在高速内存中进行。
2台消息落地服务器MQ队列里的报文消息，再写入数据库。这样把消息报文高速传递（6台服务器）和消息报文落地（2台服务器）生生的解耦开了。 Ps配图
OSB架构的外
6台服务器的前端，有硬件负载网络均衡设备。基于HTTP协议的短链接协议被负载设备均匀的分配到6台服务器上。基于长连接的RFC协议，经过项目组攻坚，居然也被负载设备均匀分配了，SAP的服务器集群中每一个服务器，都有链路接到OSB上；这个项目之前的我经历的多个集成项目，SAP都只连接了一台服务器到ESB，如果这台服务器故障，SAP到ESB就断了，即使SAP服务器群的其它服务器还在提供服务，但作为数据孤岛，不能和其它系统交互，其实企业的业务处理也中断了。
这次，长连接的RFC协议被负载均衡设备，从OSB服务器集群中每一台连接到了SAP服务器集群中的每一台，这些链路构成了一张网。中间任何一个或多个点故障，只要OSB还有一台，SAP还有一台，都不会有任何传输问题。 Ps配图
第三个里程碑，试上线数据处理
数据集成平台业务查询
第四个里程碑，搬迁上线
未完成，待续。。。。