我正在寻找关于面向消息的中间件，ESBtypes应用程序的负载平衡stream量的build议。 该应用程序是群集不知道的，不能在其内部分配负载。 因此，这是必须平衡的传入/传出消息stream量。
在我们的环境中，多个系统使用长时间的TCP连接连接到中央服务器，并在build立连接后使用MLLP交换消息。 中间件用于映射消息并将消息路由到多个其他连接的系统。
连接：
System A (via TCP) <-> Middleware App (via TCP) <-> System B (via TCP) System C (via TCP) <-> MLLP：
0x0B field.1|field.2|...|field.N 0x1C 0x0D
消息是用可变长度字段pipe道分隔的。 平衡会模仿一个粘滞的会话，但是不是使用客户端的IP，而是必须在每个消息中使用一个字段。 该字段将充当粘性会话“密钥”，以将整个消息转发到先前select的服务器，或者select新的服务器。
在研究这个话题的同时，我发现了一个类似F5的商业解决scheme： 基于消息的负载平衡
更新＃1
问题背后的总体思路是集成（主动/主动）集成引擎（面向消息的中间件）。 引擎维护大量长时间运行的TCP连接，以便在连接的系统之间以FIFO顺序路由MLLP消息。 连接专用于系统之间交换的不同消息types，即200多个连接。 来自系统A的消息通过已build立的TCP连接和遗忘方法发送到引擎。 引擎然后负责将消息路由到下游系统（系统B）。
只有在属于同一客户端ID（每个消息中的一个字段的值）的消息的上下文中，FIFO顺序才是关键的。 不同客户端的消息可以同时路由和传输。
目前，我们的集成引擎应用程序无法集群。 因此需要外部解决scheme。 而目前的一个节点负责路由和维护秩序。
我正在寻找一个平台build议，这将允许我们添加另一个集成引擎，并pipe理两个引擎之间的MLLP消息stream量。