Java EE 应用程序设计
我正在编写一个 Java EE 应用程序，该应用程序应该使用 JCo 来使用 SAP BAPI/RFC，并将它们作为 Web 服务公开给其他下游系统。该应用程序需要扩展到数以万计的并发用户规模。
我想就如何设计这个应用程序以使其满足所需的数量提出建议。
I am writing a Java EE application which is supposed to consume SAP BAPIs/RFC using JCo and expose them as web-services to other downstream systems. The application needs to scale to huge volumes in scale of tens of thousands and thousands of simultaneous users.
I would like to have suggestions on how to design this application so that it can meet the required volume.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
从设计阶段就考虑可扩展性是件好事。 Martin Abbott 和 Michael Fisher（PayPal/eBay 名人）设计了一个名为 AKF Scale 的框架，用于扩展 Web 应用程序。主要原则是在 3 轴上扩展您的应用程序。
X 轴：克隆服务/数据，以便可以轻松地跨实例分配工作。对于 Web 应用程序，这意味着能够添加更多 Web 服务器（集群）。
Y 轴：工作职责、操作或数据的分离。例如，在您的情况下，您可以在不同的服务器上进行不同的 API 调用。
Z 轴：客户或请求者的工作分离。在您的情况下，您可以说，来自区域 1 的请求者将访问服务器 1，来自区域 2 的请求者将访问服务器 2，等等。
设计您的系统，以便您可以在需要时遵循上述所有 3 个步骤。但当您最初部署时，您可能不需要使用所有三种方法。
您可以查看上述作者的《The Art of Scalability》一书。 http://amzn.to/oSQGHb
Its good that you are thinking of scalability right from the design phase. Martin Abbott and Michael Fisher (PayPal/eBay fame) layout a framework called AKF Scale for scaling web apps. The main principle is to scale your app in 3 axis.
X-axis: Cloning of services/ data such that work can be easily distributed across instances. For a web app, this implies ability to add more web servers (clustering).
Y-axis: separation of work responsibility, action or data. So for example in your case, you could have different API calls on different servers.
Z-Axis: separation of work by customer or requester. In your case you could say, requesters from region 1 will access Server 1, requesters from region 2 will access Server 2, etc.
Design your system so that you can follow all 3 above if you need to. But when you initially deploy, you may not need to use all three methods.
You can checkout the book "The Art of Scalability" by the above authors. http://amzn.to/oSQGHb
最终答案是不可能的，但根据您提供的信息，只要您的应用程序是无状态的，以便它仅将请求转发到 SAP 并返回响应，这似乎就不是问题。在这种情况下，它根本不保持任何状态。如果涉及到异步消息处理、临时数据库存储或会话状态管理等，它就会变得更加复杂。如果这是真的并且不需要维护状态，您可以轻松地将应用程序扩展到数十个应用程序服务器，而无需更改应用程序架构。
根据我的经验，在 SAP 集成方面，情况不一定如此，想象一下您想要根据 SAP 中可用的产品填充的购物车。您可能希望在应用程序中维护此购物车，并且仅将最终购物车提交给 SAP。否则，您最终会在后端构建电子商务应用程序。
最重要的是，减少应用程序中的 CPU 使用率，以避免“太大”的集群，并尽可能减少各种 I/O，例如，减少网络 I/O 的小型 SOAP 消息。
此外，我建议在 JCo 之上设计一个适当的抽象层，包括用于连接池的 JCO.PoolManager。如果您使用仅由一名技术用户管理的连接池，您可能还需要一个深思熟虑的授权概念。
只是一些（结构不清晰）的想法......
A final answer is not possible, but based on the information you provided this does not seem to be a problem as long as your application is stateless so that it only forwards requests to SAP and returns the responses. In this case it does not maintain any state at all. If it comes to e.g. asynchronous message handling, temporary database storage or session state management it becomes more complex. If this is true and there is no need to maintain state you can easily scale-out your application to dozens of application servers without changing your application architecture.
In my experience this is not necessarily the case when it comes to SAP integration, think of a shopping cart you want to fill based on products available in SAP. You may want to maintain this cart in your application and only submit the final cart to SAP. Otherwise you end up building an e-commerce application inside your backend.
Most important is that you reduce CPU utilization in your application to avoid a 'too-large' cluster and to reduce all kinds of I/O wherever possible, e.g. small SOAP messages to reduce network I/O.
Furthermore, I recommend to design a proper abstraction layer on top of JCo including the JCO.PoolManager for connection pooling. You may also need a well-thought-out authorization concept if you work with a connection pool managed by only one technical user.
Just some (not well structured) thoughts...