Java 独立应用程序的可扩展性和高可用性
我们目前正在 Linux 机器上运行 Java 集成应用程序。 首先是应用程序的概述。
Java 应用程序是一个独立的应用程序（未部署在任何 Java EE 应用程序服务器上，如 OracleAS、WebLogic、JBOSS 等）。 我所说的“独立”是指它不是桌面应用程序。 然而，它是从主类的命令行运行的。 用户根本不直接与该应用程序交互。 使用 API 将消息转储到队列中，然后由 24/7 持续运行的应用程序读出该消息。 我不会将其视为桌面应用程序，因为用户与它没有直接交互。（不确定这是否是符合桌面应用程序资格的正确推理）。
它使用 Spring 并连接到 WebSphere MQ 和 Oracle 数据库 我们使用 Spring Listener（Spring Message Driven POJO）来监听 WebSphere MQ 上的队列。 一旦队列中有消息，应用程序就会从 MQ 读取消息并将其转储（插入/更新）到数据库中。
现在的问题是：
- 我们如何水平扩展这个应用程序？ 我的意思是仅仅放置更多的盒子并运行同一应用程序的多个实例，这是一种可行的方法吗？
- 我们是否应该考虑从 Spring MDP 迁移到 EJB MDB？ 从而将其部署到应用服务器上。 这样做有什么额外的好处吗？
- 是否有使应用程序高可用 (HA) 的请求？ 可以采用哪些建议的方法或策略来实现独立应用程序高可用性？
We are currently running a Java integration application on a Linux box. First an overview of the application.
The Java application is a standalone application (not deployed on any Java EE application server like OracleAS,WebLogic,JBOSS etc).
By Stand Alone I mean its NOT a DESKTOP application. However it is run from the command line from a Main class. The user does not directly interact with this application at all. Messages are dumped into the queue using an API which is then read out by my Application which is constantly running 24/7. I wouldn't qualify this as a desktop app since the user has no direct interaction with it.(Not sure if this is the correct reasoning to qualify as one).
It uses Spring and connects to WebSphere MQ and Oracle Database
We use a Spring Listener(Spring Message Driven POJOs) which listens to a queue on WebSphere MQ. Once there is a message in the queue, the application read the message from the MQ and dumps(insert/update) it into the database.
Now the question is:
- How can we horizontally scale this application? I mean just putting more boxes and running multiple instances of this same application, is that a viable approach?
- Should we consider moving from Spring MDPs to EJB MDBs? Thereby deploying it on the Application Server. Is there any added benefit by doing so?
- There is a request to make the application High Available(HA)? What are the suggested methodologies or strategies that can be put in place to make a standalone application HA?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
另一个选择是 Terracotta，一个可以完全满足您需求的框架； 同时在多台机器上运行您的应用程序并平衡它们之间的负载。
Another option is Terracotta, a framework that does precisely what you want; running your app on several machines simultaneously and balancing the load among them.
随着数据需求的增加，任何应用程序的水平扩展最终都会遇到限制。 这些限制由负载和服务器/数据库性能决定。 在某些时候，如果需求和负载随着扩展而增加，服务器/数据库的数量也必须增加。 根据存储的数据，服务器/数据库要么必须复制和同步，要么需要采用某种哈希算法将数据分割到多个服务器上。 随着同步数据源数量的增加，复制/同步这些服务器的成本也会增加。 这就是为什么散列方法可能更有吸引力以最小化成本。
真正的高可用性解决方案的实施成本非常昂贵。 我也见过不同程度的高可用性，但根据定义，它意味着绝对最小或没有停机时间，或者无法访问数据源。 为了实现这一目标，需要大量冗余硬件、网络和软件，这些硬件、网络和软件能够在其中一个数据源发生故障时利用冗余硬件，而不会失去获取数据的能力。 硬件故障是不可避免的，它也会发生，还有停电等随机的自然行为。 根据这些数据的重要性，HA 解决方案还需要多个独立电网上的多个数据中心。 这显然会非常昂贵，因此这完全取决于这些数据对最终用户的重要性。
所以，HA是一个极端的场景，需要昂贵的架构。 我发现大多数时候人们只关心最小化停机时间，并且根据数据源的大小，通过添加数据源的热备件可以相当便宜地实现这一点。
Horizontal scaling for any application will eventually run into limits as demand for the data increases. Those limits are determined by load and server/database performance. At some point, if demand and load increase with scaling, the number of servers/databases will have to increase as well. Depending on the data that is being stored, the servers/databases will either have to be duplicated and synchronized, or some sort of hashing algorithm will need to be employed to split data across multiple servers. As you increase the number of synchronized data sources the cost of replicating/synchronizing those servers increases as well. That is why the hashed approach may be more appealing to minimize cost.
True High Availability solutions are very expensive to implement. I've seen various degrees of HA as well, but by definition it means absolute minimal or no downtime of, or lose of access to the data source. To achieve this requires a lot of redundant hardware, networking, and software that is able to utilize redundant hardware without losing the ability to get to the data when one of the data sources fails. Hardware failure is inevitable, it will happen, as well as power outages and other random acts of nature. Depending on how critical this data is an HA solution will also require multiple data centers on multiple independent power grids. Which is obviously going to be very expensive, so it all depends on how critical this data is to the end-user.
So, HA is an extreme scenario requiring an expensive architecture. I find that most of the time people are interested in just minimizing downtime, and depending on the size of the data source this can be achieved fairly inexpensively with adding hot-spares of the data sources.
对于HA，您需要明确要求。 对于基于队列的应用程序来说，“高可用性”是一个有趣的问题。 如果您的应用程序宕机了几分钟，消息就会堆积在队列中。 只要您可以让应用程序恢复并运行，这些消息仍然会得到处理，只是延迟会多一些。 可能值得问的是，“消息可接受的最大延迟是多少？”
可能存在一些有关硬件故障、数据中心丢失等问题的担忧。这些问题无法通过同一位置的水平扩展来解决。 您需要复制每一层的所有组件：队列本身、处理器、后端数据库以及连接它们的所有网络硬件。
这是一个昂贵的提议，因此也值得一问：“HA 场景和非 HA 场景之间停机的年化损失预期损失是多少？” ALE 包含直接损失和监管或法律成本，因此它是捕获停机成本的好方法。
For HA, you need to clarify the requirements. "High availability" is an interesting question for a queue-based app. If your app goes down for a few minutes, messages pile up in the queue. As long as you can get your app back up and running, those messages will still get processed, just with a bit more latency. It's probably worth asking, "What is the maximum acceptable latency for a message?"
There's probably some component of concern about hardware failures, loss of a datacenter, etc. These won't be addressed by horizontal scaling in the same location. You'll need to replicate all components at every layer: the queue itself, the processors, the backend database, and all network hardware connecting them.
It's an expensive proposition, so it's also worth asking, "What's the delta in annualized loss expectancy of downtime between an HA scenario and a non-HA scenario?" ALE incorporates both direct losses and regulatory or legal costs, so it's a good way to capture the cost of downtime.
“独立”==“桌面”吗？
用户如何与拥有消息驱动 bean 的控制器进行交互？
我对您的问题的看法：
Does "standalone" == "desktop"?
How do users interact with the controller that owns the message-driven beans?
My opinions on your questions:
.1. 在队列上创建更多侦听器可以扩展消费者的数量。 当一个消费者死亡时，剩余的消费者可以继续运行。 注意：您的 MQ 和数据库也需要具有高可用性解决方案。
.2. 不确定应用程序服务器会对您的情况产生什么影响。 也许您可以解释一下您打算使用哪些功能？
.3. 请参阅我对 1. 对于 HA 的回答。
.1. Creating more listeners on the queue can scale the number of consumers. As a consumer dies, the remaining consumers can keep running. Note: Your MQ and database need to have high availability solutions as well.
.2. Not sure what difference an application server would make in your case. Perhaps you could explain which features you intend to use?
.3. See my answer to 1. for HA.
你尝试过制作多个盒子吗？
我想你可以看看你的 MQ 的文档吗？
运行多个盒子可能需要在 MQ 中进行一些配置，但它将运行 ISA
Did you try to make multiple boxes ?
I think you may see the doc of your MQ ?
running multiple boxes may need some configuartion in your MQ but it will run ISA