扩展 Spring Integration Web 应用程序

Question

我使用 Spring Integration API 编写并维护了这个无状态 REST 应用程序/API，其中包含以下基础概念：

1) 入站 HTTP 网关作为 RESTful 入口点 2) 一些服务激活器、路由器、通道和转换器 3) 一个拆分器（和一个聚合器），前者订阅了一个通道，而后者又连接了一个任务执行器，包括一个大小为 100 的线程池，用于并行执行 split(ted) 消息

到目前为止，该应用程序正在无缝执行 - 作为下一步，我尝试扩展该应用程序以处理更多请求，以适应池中所有 100 个线程同时被占用的最坏情况。

请注意，服务的行为始终是同步的（这是业务需求），有时服务可能会稍微长时间运行。 最坏情况往返约 15 秒，最好情况约 2 秒，这两者都在业务团队可接受的范围内。

手头的应用服务器是多实例集群环境中的 WebSphere 8.5，并且可以增加集群的大小以及每个实例在内存和处理器内核方面的能力。

也就是说，我正在探索解决在实现层中扩展应用程序问题的方法，这些是我能想到的几种方法：

1) 将任务执行器线程池的大小增加多次，例如，增加到 1000 或 10000 而不是 100，以容纳更多的并行请求。 2) 保持任务执行器线程池的大小不变，而是通过使用一些 Spring 代码将单个应用程序上下文转换为一个上下文池进行扩展，以便每个请求都可以获取可用的一个，并且每个上下文都具有完全访问权限到线程池。 示例：一个包含 250 个应用程序上下文的池，每个上下文有一个大小为 100 的线程池，总共有 250 × 100 = 25000 个并行线程。

第二种方法可能会导致高内存消耗，所以我在考虑是否应该从方法 1) 开始。 但是，我不确定的是，从长远来看，这两种方法中的任何一种是否可行。

任何人都可以发出一些光吗？ 在此先感谢您的时间。

真诚的，巴拉特

Answer 1

根据我的经验，在扩大规模时很容易遇到障碍。 相比之下，向外扩展更灵活，但会增加系统的复杂性。

手头的应用服务器是多实例集群环境中的 WebSphere 8.5，并且可以增加集群的大小以及每个实例在内存和处理器内核方面的能力。

我会继续朝这个方向发展（通过向集群添加实例来扩展），如果可能的话，我会在它前面添加一个负载平衡机制。 首先随机分配负载，然后通过“实例池中的空闲线程”分配负载来增强。

此外，确定系统中较重的部分，并评估将它们迁移到他们自己的专用服务是否会有所收获。

请注意，服务的行为始终是同步的（这是业务需求），有时服务可能会稍微长时间运行。

上面的陈述引起了一些人的注意。 我理解当业务说“只在一切都完成后才返回结果”时。 如果是这种情况，那么如果您可以将范式从同步请求/响应更改为观察者模式，则该系统将受益匪浅。