Java 关于此用例的架构/设计的一些问题？

我的应用程序需要作为中间件工作，它可以从不同的应用程序获取订单（以xml的形式） 包含供应商id的客户。一旦收到订单，它需要发送订单请求 以xml的形式发送给不同的供应商。我对它的三个方面持双重观点。这是：-

问题:

我在高层计划的是，一旦请求到来，就把它放到jms队列中（现在我不确定） 我应该为每个供应商创建队列还是一个队列就足够了。我认为一个队列就足够了。 因为维护大量队列会增加开销。）。每个供应商保持单独队列的优点是，消息可以更快地处理，因为每个队列上将有单独的生产者

在将对象放入队列之前 我需要做一些业务验证。另外，我接收的输入xml和我需要发送给供应商的输出xml的结构也不同。为此，我计划将输入xml转换为java对象，然后放入队列 因此，验证可以在消费者端轻松完成。另一个想法是不要将xml转换为java对象，只获取所有元素 通过xpath/xstream api进行赋值，并验证它们，并将xml字符串按原样放在队列中，因为。然后在用户端将xml转换为java对象，然后再转换为不同的xml格式。有办法吗

现在，我的要求是队列上的消费者每5小时处理一次队列上的消息，然后发送xml请求 给供应商。我计划在这里使用石英调度器，它将一个接一个地选择作业并发送给相应的用户 基于供应商ID的供应商。我的问题是，我的工作是否会一个接一个地挑选信息，然后将其发送给供应商。 太慢了。我计划在quartz job创建线程池的地方处理它，比如说一次创建10个线程 它会同时处理来自队列的消息（因此队列中将有多个使用者。我认为这对队列无效。我是否需要此处的主题而不是队列？）。第二种方法更好还是有更好的方法

---

我预计每小时有50k个请求，这意味着每秒大约有15个请求

因为您是中间件，所以您应该在联系点快速处理数据，以便腾出双手处理更多的传入请求。因此，您必须找到一种方法，以尽可能快的速度和低的内存分离传入数据。将数据处理留给针对问题更具体的模块。接待员只是把客人引导到正确的地点

如果您以后真的需要阅读和理解专业工作者中接收到的数据，请使用线程池。通过这种方式，您可以并行处理数据，而不用太担心outofmem。只需巧妙地选择您的池大小，并只使用一个。您可以使用侦听器模式向工作者multiton发送新传入数据的信号。如果可能的话，您应该避免jaxb或更好地完成数据的反序列化。它像地狱一样吞噬记忆

我不会使用jmx，因为您的“消息”只与一个侦听器相关

---

如果可能的话，在工人完成工作后尽快发送邮件。如果没有，请使用存储器。通过这种方式，您可以在以后验证您是否处理了数据，如果出现问题或您必须更新软件，您就不必担心不稳定的数据。

您的基本要求是

以XML形式从客户处获取订单（您尚未告知如何接收）

进行基本的业务验证

将订单发送给供应商

您将不接受50k请求（您尚未提供大致的订单大小）。 假设您的平均订单大小为10K，仅将其保留在队列中（不考虑队列数量）大约需要500MB。我不确定您正在运行哪个环境

关于第1点 我会选择单队列而不是多队列 -选择适当的持久存储。 我假设您将使用分布式队列，以便在添加集群时可以轻松地进行扩展

第2点 我将转换为POJO（您自己的格式）并执行业务验证。因此，如果以后您想将业务验证扩展到ruler或任何其他转换，那么很容易维护。 -基本上，获取任何形式的输入（XML/POJO/JSON…）并转换为中间格式（您可以在中间fomart之上编写custome验证程序/转换实用程序）。并保持公共格式与输入和输出之间的映射。这样您就可以编写格式化程序并使用它们。在将来更改任何特定供应商的格式时不会产生影响。尝试将格式映射外部化

关于第3点 在您的情况下，订单只需处理一次。所以我要排队。您可以有多个消息侦听器。消息侦听器以异步方式传递顺序。因此，一个队列可以有多个侦听器。每个侦听器将运行单独的线程。

---

收到订单后立即发送有问题吗？在特定时间避免重载对您和供应商都有好处。

您没有提供，负载是多少。metrics@Mani如果在最短时间（4:59小时）内提供load metricSo，您将排除队列中的25000个对象。发送回供应商时是否需要修改XMl格式。因此，在这种情况下，没有必要将其存储在XML中。除非中间层与供应商之间没有合同，否则每个供应商可以使用不同的格式supplier@Mani你是对的，我需要修改xml的格式，然后发送回供应商。Mani我根据你最后的评论编辑了我的第二点。问得好。你能和我一起快速聊天吗？让我试试。会给它一个简短的聊天。你在聊天中收到我的留言了吗？你在吗？我加入了聊天室你有skyp吗