在本次的整车工厂项目中，我们部署了SAP S4HANA的服务器集群，Oracle service bus的服务器集群，
ERP系统服务依然还是各系统的核心，本次总线项目共100个接口，ERP系统占了一半。
在蓝图阶段，我们实现了OSB集群服务器同SAP服务器的连接：
OSB同SAP连接的协议是传统的SAP-RFC，作一些配置后，我们实现上面的架构。它实现了SAP RFC的负载均衡，详情请见我之前的blog专题描述。这里有一个问题，SAP服务器是双机集群，ESB的6台服务器全部接在SAP的1号机上。当2号机的用户，使用接口传出数据时，会无法传出，这个缺陷在之前项目中并不少见。更要命的是，如果1号机停机了，2号机虽然还在持续提供ERP的服务，但是接口相关的数据是无法传到ESB中间件上。
项目组开始攻坚，尝试多种解决办法未果。最后我们把注意力集中在负载均衡设备上，这个设备是可以解决这个问题的，但是这个设备大家都不懂，所以很难把我们的需求同这个设备联系起来。 网络管理员可能是懂这个设备的，但他们不了解我们这些个服务器复杂架构的需求，即使给了他们环境说明，毕竟已经隔行，估计短时间也难有突破。 我认为我们ESB项目组应该掌握这个设备，并解决我们面临的问题。我们开始尝试去理解负载均衡设备的工作方式，我发现它并不难，而且可以说很简单。
简单的说，你可以把你想要平均分布的服务器，在这个负载均衡设备里组成一个组，然后这个设备暴露你一个访问的IP，最后你只需访问这个IP，负载均衡设备自动到服务器组里去挑服务器来满足你的使用。
我们在负载均衡设备里，把SAP 2台服务器分成了一个组；
OSB的6台服务器通过负载均衡设备 把 基于RFC协议的6条链路依次的连接到了2台SAP服务器上。
经过测试，我们实现了如下架构：
我把它叫做梦幻架构，可能是我这些天睡觉都在想要实现的功能都有了。
1、基于RFC协议的负载均衡。
2、SAP双机都有多条长连接链路同ESB通讯。
整个架构中没有单点，我能想到的，它目前没有任何缺陷。
集成项目中难免会出现一些问题，后面我会陆续的总结。