Java 扩展Spring集成web应用程序

有一个无状态REST应用程序/API，由我使用Spring集成API编写和维护，它与以下基础概念密切相关：

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

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

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

手边的应用服务器是多实例集群环境中的WebSphere8.5，并且有一个条款可以增加集群的大小以及每个实例在内存和处理器核心方面的能力

也就是说，我正在探索如何解决在实现层中扩展应用程序的问题，我可以考虑以下几种方法：

1） 将TaskExecutor线程池的大小增加很多倍，例如，从100增加到1000或10000，以适应更多的并行请求。 2） 保持TaskExecutor线程池的大小不变，而是通过使用一些Spring代码将单个应用程序上下文转换为上下文池来放大，这样每个请求都可以获取一个可用的线程池，并且每个上下文都可以完全访问线程池。 示例：一个包含250个应用程序上下文的池，其中每个上下文都有一个大小为100的线程池，这样总共可以并行处理250×100=25000个线程

第二种方法可能会导致高内存消耗，因此我想是否应该从方法1）开始。 然而，我不确定的是，从长远来看，这两种方法是否可行

谁能给我点光吗？提前感谢您抽出时间

真诚地，

---

Bharath

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

手头的应用服务器是多实例中的WebSphere8.5 群集环境，并且有一项增加 集群以及每个实例在内存和 处理器核心

我将继续这个方向（通过向集群添加实例来扩展），如果可能的话，我将在集群前面添加负载平衡机制。从随机分配负载开始，通过“实例池中的空闲线程”分配负载来增强

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

请注意，服务的行为始终意味着 同步（这是一种业务需求），有时 服务可以是稍微长时间运行的服务

---

上述声明引起了一些关注。我理解企业所说的“一切完成后才返回结果”。如果是这样的话，那么如果您可以将范式从同步请求/响应更改为观察者模式，那么这个系统将受益匪浅。

感谢这一点-事实证明，采取支持服务器端功能的方向比必须在代码级别解决问题要好得多