有一个系统可以访问各种效率不高的服务。这些服务是由于处理某些消息而调用的。 由于这种低效率，系统被限制为每个节点 1 个消息消费者 - 以避免重载特定服务“A”。处理的消息各不相同，可能会同时处理多条消息，所有消息都需要调用服务“A”——因此存在限制。假设服务“A”可以处理 3 个并发连接，系统有 3 个节点，因此每个节点允许的最大消费者数为 1。
其他服务也有它们的容量，从所说的 3 个到基本无限制不等。
问题是 - 引入此类限制的最佳方式是什么？如果只有一个节点，那么引入一个服务客户端池就很容易了。当然，在客户端可用之前，它会阻塞消息消费者，但人们可以接受它。但这也意味着每个节点的池大小为 1(因为所有 3 个节点都可以开始调用服务“A”)。 对于多个节点，将需要某种分布式客户端池。有这样的吗？
(我知道如果单个消息处理被拆分成更小的消息，每个服务调用 1 个，它只允许使用例如 JMS 队列来做到这一点，但它是不可行的，例如由于消息处理的事务性质)。
最佳答案
我看到了两种可能的解决方案。两者都基于解决问题的中间件方法，其中简单的解决方案可以解决您的特定问题，而更高级的解决方案需要更大的投资才能获得更大的灵 active 和额外的好处。
简单的代理解决方案
在效率不高的服务前面创建您自己的中间件代理。代理将维护到后端服务的有限连接池。然后当到后端服务的出站连接被阻塞时，简单地阻止或拒绝(而不是排队)。否则只需将请求从入站系统节点转发到后端服务，然后用服务的响应响应系统节点。这样后端服务永远不会重载。它允许您的节点由于其交易性质而需要的同步通信。
系统架构师解决方案
使用功能齐全的 ESB(企业服务总线)。一种允许您对特定端点的并发连接设置限制，并允许异步和同步消息处理。然后 ESB 成为您的环境范围内的流量 Controller ，可以将其配置为在效率不高的端点阻塞时阻止或拒绝消息。为获得额外的好处，寻找允许服务质量配置的 ESB，以防止系统节点在使用有限资源时出现饥饿，或自动重试与不稳定端点的连接尝试。
关于java - 大小有限的分布式池，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/24501048/