Spring javaee应用程序设计

我正在编写一个JavaEE应用程序，该应用程序应该使用JCo使用SAP BAPI/RFC，并将它们作为web服务公开给其他下游系统。该应用程序需要以数万和数千同时用户的规模扩展到巨大的容量

---

我想就如何设计此应用程序提供一些建议，使其能够满足所需的容量。

很好，您从设计阶段就开始考虑可扩展性。Martin Abbott和Michael Fisher（PayPal/eBay fame）设计了一个称为AKF Scale的框架，用于扩展web应用程序。主要原则是在3轴上缩放应用程序

X轴：克隆服务/数据，以便可以轻松地跨实例分发工作。对于web应用程序，这意味着能够添加更多web服务器（集群）

Y轴：工作职责、行动或数据的分离。例如，在您的例子中，您可以在不同的服务器上调用不同的API

Z轴：客户或请求者的工作分离。在您的案例中，您可以说，来自区域1的请求者将访问服务器1，来自区域2的请求者将访问服务器2，等等

设计您的系统，以便您可以在需要时遵循以上三点。但在最初部署时，可能不需要全部使用这三种方法

---

您可以查阅上述作者的《可伸缩性的艺术》一书

最终答案是不可能的，但根据您提供的信息，只要您的应用程序是无状态的，因此它只将请求转发给SAP并返回响应，这似乎不是问题。在这种情况下，它根本不保持任何状态。如果涉及到异步消息处理、临时数据库存储或会话状态管理，则会变得更加复杂。如果这是真的，并且不需要维护状态，那么您可以轻松地将应用程序扩展到几十个应用程序服务器，而无需更改应用程序体系结构

根据我的经验，在涉及SAP集成时，情况未必如此，请考虑您希望根据SAP中提供的产品填充的购物车。您可能希望在应用程序中维护此购物车，并且只将最终购物车提交给SAP。否则，您最终将在后端内部构建一个电子商务应用程序

最重要的是减少应用程序中的CPU利用率，以避免“过大”群集，并尽可能减少各种I/O，例如，减少网络I/O的小SOAP消息

此外，我建议在JCo之上设计一个适当的抽象层，包括用于连接池的JCo.PoolManager。如果您使用的是仅由一个技术用户管理的连接池，那么您可能还需要一个经过深思熟虑的授权概念

---

只是一些（结构不好的）想法…

由于响应中需要一些自定义翻译，我没有使用内置SAP的expose BAPI/RFC as web service功能。最重要的是，您的SAP基础架构本身可以处理负载吗？假设SAP基础架构将按负载进行扩展。。。