我正在编写一个 Java EE 应用程序，它应该使用 JCo 使用 SAP BAPI/RFC，并将它们作为 Web 服务公开给其他下游系统。该应用程序需要扩展到数以万计的同时用户的巨大容量。
我想对如何设计此应用程序以使其满足所需的容量提出建议。
【问题讨论】：
标签： spring design-patterns jakarta-ee scalability volume
您从设计阶段就开始考虑可扩展性，这很好。 Martin Abbott 和 Michael Fisher（PayPal/eBay 成名）设计了一个名为 AKF Scale 的框架，用于扩展 Web 应用程序。主要原则是在 3 轴上缩放您的应用。
X 轴：克隆服务/数据，以便可以轻松地跨实例分配工作。对于网络应用，这意味着能够添加更多网络服务器（集群）。
Y 轴：工作职责、操作或数据的分离。因此，例如在您的情况下，您可以在不同的服务器上进行不同的 API 调用。
Z 轴：客户或请求者的工作分离。在您的情况下，您可以说，来自区域 1 的请求者将访问服务器 1，来自区域 2 的请求者将访问服务器 2，等等。
设计您的系统，以便您可以在需要时遵循上述所有 3 点。但是当您最初部署时，您可能不需要使用所有三种方法。
您可以查看上述作者的《可扩展性的艺术》一书。 http://amzn.to/oSQGHb
【讨论】：
最终答案是不可能的，但根据您提供的信息，这似乎不是问题，只要您的应用程序是无状态的，因此它只会将请求转发到 SAP 并返回响应。在这种情况下，它根本不保持任何状态。如果涉及到例如异步消息处理、临时数据库存储或会话状态管理变得更加复杂。如果这是真的并且不需要维护状态，您可以轻松地将您的应用程序扩展到数十个应用程序服务器，而无需更改您的应用程序架构。
根据我的经验，当涉及到 SAP 集成时，情况不一定如此，请根据 SAP 中的可用产品考虑您想要填充的购物车。您可能希望在您的应用程序中维护此购物车，并且仅将最终购物车提交给 SAP。否则，您最终会在后端构建电子商务应用程序。
最重要的是降低应用程序中的 CPU 使用率，以避免集群“过大”，并尽可能减少各种 I/O，例如用于减少网络 I/O 的小型 SOAP 消息。
此外，我建议在 JCo 之上设计一个适当的抽象层，包括用于连接池的 JCO.PoolManager。如果您使用仅由一位技术用户管理的连接池，您可能还需要一个经过深思熟虑的授权概念。
只是一些（结构不完善）的想法......
【讨论】：