消息、队列和 ESB - 我知道我想去哪里，但不知道如何到达那里
长话短说，我正在开展一个项目，出于所有常见原因，我们正在重写一个大型 Web 应用程序。 重写的主要目的是将在单个服务器上运行的大型单一应用程序分成许多较小的解耦应用程序，这些应用程序可以在许多服务器上运行。
好的，这就是我想要的：
我希望 HTTP 成为主要的传输机制。 当一个应用程序（例如 CMS）更新时，它将通过 http 联系代理并说“我已更改”，然后代理将发回 200 OK 说“谢谢我收到消息”。
然后，代理将查看其想要了解 CMS 更改的其他应用程序的列表，并将消息传递到应用程序在告诉代理它想要了解该消息时留下的 URL。
其他应用程序在收到消息时将返回200 OK，如果没有，代理将保留该消息并将其排队以供下次有人尝试联系该应用程序时使用。
问题是我什至不知道从哪里开始或者我需要什么来实现它。 我一直在研究 XMPP、ActiveMQ、RabbitMQ、Mule ESB 等，并且可以看到我可以花费明年就用这些东西兜圈子。
任何人都可以根据个人经验提供任何建议，因为我很想避免以艰难的方式吸取教训。
To cut a long story short, I am working on a project where we are rewriting a large web application for all the usual reasons. The main aim of the rewrite is to separate this large single application running on single server into many smaller decoupled applications, which can be run on many servers.
Ok here's what I would like:
I would like HTTP to be the main transport mechanism. When one application for example the CMS has been updated it will contact the broker via http and say "I've changed", then the broker will send back a 200 OK to say "thanks I got the message".
The broker will then look on its list of other applications who wanted to hear about CMS changes and pass the message to the url that the application left when it told the broker it wanted to hear about the message.
The other applications will return 200 OK when they receive the message, if not the broker keeps the message and queues it up for the next time someone tries to contact that application.
The problem is I don't even know where to start or what I need to make it happen. I've been looking at XMPP, ActiveMQ, RabbitMQ, Mule ESB etc. and can see I could spend the next year going around in circles with this stuff.
Could anyone offer any advice from personal experience as I would quite like to avoid learning lessons the hard way.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（6）
自 2003 年左右以来，我一直在各种软件系统中使用 JMS 消息传递。我有一个 Web 应用程序，其中客户端实际上是 JMS 主题订阅者。 只需将消息发布到主题中，消息就会被服务器推送并传播到所有订阅的 Web 客户端。
Web 客户端是基于 Flex 的。 我们的中间层堆栈包括：
BlazeDS 能够配置为 JMS 的桥梁。 它是一个 Tomcat servlet，可响应 Flex 客户端远程调用，但也可以在其配置的 JMS 主题中出现新消息时向客户端推送消息。
BlazeDS 实现了用于服务器端消息推送的 Comet 模式：
异步 HTTP 和 Comet 架构
异步、非阻塞 HTTP 编程简介
Farata Systems 宣布他们已经修改了 BlazeDS，以便与 Jetty 延续方法一起实现 Comet 模式。 这使得单个物理服务器能够扩展到数千个 Comet 连接。
Farata Systems 借助 Adobe BlazeDS 实现性能突破
我们正在等待 Adobe 实现对BlazeDS 本身中的 Servlet 3.0 基本上我们相当热衷于组合使用 Tomcat 和 Spring。
实现大规模可扩展 Comet 模式的技术关键是结合使用 Java NIO HTTP 侦听器和线程池（例如 Java 5 并发库中的 Executor 类）。 Servlet 3.0 是 servlet 的异步事件驱动模型，可以与此类 HTTP 侦听器绑定在一起。 然后，单个物理服务器可以维持数千个（例如 10,000 到 20,000 个）并发 Comet 连接。
尽管在我们的案例中，我们使用 Adobe Flex 技术将 Web 客户端转变为事件驱动的消息订阅者，但对于任何通用 AJAX Web 应用程序也可以执行相同的操作。 在 AJAX 圈子中，进行服务器端消息推送的技术通常称为“反向 AJAX”。 您可能已经发现 Comet 是一个文字游戏，就像 Ajax（都是家庭清洁工）的对应词一样。 不过，对我们来说，好处是我们只需将各个部分连接起来即可出发。 通用 AJAX Web 程序员将有更多的编程工作要做。 （不过，即使是通用的 Web 应用程序也可以与 BlazeDS 一起使用 - 它只是对 BlazeDS 所具有的 AMF 编组功能没有任何用处。）
最后，Adobe 和 SpringSource 正在合作建立一个更流畅、更出色的- BlazeDS 与 Spring-Framework 的盒式集成：
Adobe 与 SpringSource 合作增强 Flash 和 SpringSource 平台之间的集成< /a>
I've worked with JMS messaging in various software systems since around 2003. I've got a web app where the clients are effectively JMS topic subscribers. By the mere act of publishing a message into a topic, the message gets server-pushed dissemenated to all the subscribing web clients.
The web client is Flex-based. Our middle-tier stack consist of:
BlazeDS has ability to be configured as a bridge to JMS. It's a Tomcat servlet that responds to Flex client remoting calls but can also do message push to the clients when new messages appear in the JMS topic that it is configured to.
BlazeDS implements the Comet Pattern for doing server-side message push:
Asynchronous HTTP and Comet architectures
An introduction to asynchronous, non-blocking HTTP programming
Farata Systems has announced that they have modified BlazeDS to work with the Jetty continuations approach to implementing the Comet Pattern. This enables scaling to thousands of Comet connections against a single physical server.
Farata Systems Achieves Performance Breakthrough with Adobe BlazeDS
We are waiting for Adobe to implement support of Servlet 3.0 in BlazeDS themselves as basically we're fairly wedded to using Tomcat and Spring in combo.
The key to the technique of doing massively scalable Comet pattern is to utilize Java NIO HTTP listeners in conjunction to a thread pool (such as the Executor class in Java 5 Concurrency library). The Servlet 3.0 is an async event-driven model for servlets that can be tied together with such a HTTP listener. Thousands (numbers like 10,000 to 20,000) concurrent Comet connections can then be sustained against a single physical server.
Though in our case we are using Adobe Flex technology to turn web clients into event-driven messaging subscribers, the same could be done for any generic AJAX web app. In AJAX circles the technique of doing server-side message push is often referred to as Reverse AJAX. You may have caught that Comet is a play on words, as in the counterpart to Ajax (both household cleaners). The nice thing for us, though, is we just wire together our pieces and away we go. Generic AJAX web coders will have a lot more programming work to do. (Even a generic web app could play with BlazeDS, though - it just wouldn't have any use for the AMF marshaling that BlazeDS is capable of.)
Finally, Adobe and SpringSource are cooperating on establishing a smoother, out-of-the-box integration of BlazeDS in conjunction to the Spring-Framework:
Adobe Collaborates with SpringSource for Enhanced Integration Between Flash and SpringSource Platforms
首先，不用担心 ESB。 您所描述的情况完全属于简单的面向消息的中间件的范围。 仅当您执行中介、基于内容的路由、协议转换等操作时，您才“需要”ESB； 中间件除了将消息路由到正确的位置之外，还对消息进行处理。
如果您有一组不同的目标应用程序需要相互通信 - 听起来您确实这样做 - 您是对的，通过与语言无关的协议（例如 XMPP，STOMP 或 HTTP）是一个巧妙的解决方案。 它基本上意味着您不必编写和运行大量 Java 守护进程来将消息转换为您最喜欢的 JMS 风格。
STOMP 越来越受到消息代理的支持，尤其是开源消息代理的支持，并且有许多不同的客户端库。 它是一种轻量级协议，专为消息传递而设计，因此您可以立即获得比 HTTP 更丰富的功能集。
对我来说，XMPP 是一个有点弱的选项，因为它在服务器端没有得到很好的支持，尽管能够向您的代理发送 IM 很有趣:)
如果您设置为 HTTP，OpenMQ 非常好，我个人用过它的通用消息服务 - 基本上是围绕 JMS 目标的 Web 应用程序包装器。 它提供了一个 REST-ful 接口，具有与 STOMP 提供的类似的动词集。
First of all, don't worry about ESBs. The situation you've described lies well within the bounds of straightforward message-oriented middleware. You only "need" an ESB if you're doing things like mediations, content-based routing, protocol transformations; things where the middleware does stuff to the message, on top of routing it to the right place.
If you have a diverse set of destination applications that need to speak to each other - and it sounds like you do - you're right that messaging over a language agnostic protocol (like XMPP, STOMP or HTTP) is a neat solution. It basically means you don't have to write and run loads of Java daemons to translate messages into your favourite flavour of JMS.
STOMP is increasingly supported by message brokers, especially by the open-source ones, and there's a number of different client libraries. It is a lightweight protocol, specifically designed for messaging so you get a much richer feature set out of the box than you would with HTTP.
For me, XMPP is a bit of a weak option as it's not so well supported on the server side, although it is fun to be able to IM your broker :)
If you are set on HTTP, OpenMQ is very good, and I've personally used its Universal Message Service - basically a webapp wrapper around JMS destinations. It provides a REST-ful interface, with a similar set of verbs as STOMP provides.
正如有人已经说过的，您所描述的基本上是发布者/订阅模型。 使用 ESB 或消息队列可以很容易地实现这一点。 我对 RabbitMQ 有一些经验。 这很好。 不会丢失任何内容，并且它可以很好地处理发布订阅模型。 我过去曾在小型系统上沿着通过 http 的定制协议开发自己的消息代理的路线。 我不建议这样做，原因是当你开始开发它时，你会不断思考如何扩展它。
RabbitMQ 是用 Erlang 开发的，但它有 java、net、python 等客户端，可以很容易地连接到它。 我使用过.net和python客户端，效果很好。 我选择它是因为 Erlang 在创建可靠的系统方面享有盛誉，可以很好地处理同时发生的多种事情。 我会把它们称为线程，但我认为它比线程更聪明，我想我记得演员模型和邮箱的嘀咕，我记得它们非常整洁。
我的处境与您类似，但其他消息系统（Biztalk 等）的体验非常糟糕，这些系统太过礼节，将您束缚在解决方案中。 如果您可以将消息与传输和传递机制分开，那么您就可以根据自己的喜好开发系统。 由于数据包很小，我最终使用了 JSON。 您可以使用任何您喜欢的东西，有些选择 SOAP 消息，但我觉得这些对于大多数东西来说都太重了，尽管它确实允许您很好地向外部人员提供 XSD 模式，以便他们可以开发与您的系统互操作的系统。未来的系统。
http://www.rabbitmq.com/tutorials/tutorial- Three-java.html ，这是有关发布/订阅模型以及如何使用消息队列系统实现它的教程的链接。 它适用于rabbitMQ，但说实话，它可以与ESB 和任何其他消息队列系统一起使用。
As someone has already said, what your describing is basically the Publisher/Subscribe Model. This is very easily achieved using either an ESB or a message queue. I have had some experience with RabbitMQ. Its very good. Nothing gets lost and it deals with the publish subscribe model very well. I have in the past gone down the route on small scale systems of developing my own Message broker with a bespoke protocol over http. I wouldn't advise this, reason being is that as you start to develop it you keep thinking of ways of how to extend it.
RabbitMQ is developed in Erlang but it has java,net,python etc clients that can hook into it very easily. I have used the .net and python clients, it works well. I chose it for Erlangs reputation for creating solid systems that can cope with multiple things going on at the same time, very well. I would call them threads but I think that its smarter than just threads, I think I remember mutterings of the Actor Model and mailboxes, which I recall were pretty neat.
I was in a similar position as yourself but with very bad experiences of other messaging systems (Biztalk et al.) that were too propriety that tied you into a solution. If you can keep the messages separate from the transport and delivery mechanisms, then you can develop your system to your hearts content. I used JSON in the end as the packet sizes are small. You could use anything you like, some opt for SOAP messages, but I feel that these are way too heavy for most stuff, although it does allow you to nicely give XSD schemas to outsiders so that they can/could develop systems that interop with your system in the future.
http://www.rabbitmq.com/tutorials/tutorial-three-java.html, this is a link to the tutorial on the Publish/Subscribe model and how you would achieve it using a message queue system. Its for rabbitMQ, but to be honest it will work with ESB and any other Messaging queue system out there.
ESB（企业串行总线）- 当您的应用程序与两个或多个外部/独立应用程序进行大量交互（其中每个应用程序不会以类似的数据格式进行通信）时，请考虑这一点。 例如：某些系统可能接受对象、XML、JSON、SMTP、TCP/IP、HTTP、HTTPS 等。ESB
具有许多功能，例如：
路由、寻址、消息传递样式、传输协议、服务消息传递模型。
如果生产者-消费者应用程序遵循相同类型的数据格式，请考虑队列系统。
如果一个应用程序需要另一应用程序来完成工作流程，则 Web 服务 (SOAP/REST) 是最佳选择。
如果应用程序需要异步数据传输，请使用队列。
ESB (Enterprise Serial Bus) - Consider this when your application have much interaction with two or more external/separate applications where each of these won't communicate in a similar data format. Ex: Some systems may accept objects, XML, JSON, SMTP, TCP/IP, HTTP, HTTPS etc.
ESB has many features like:
Routing,Addressing,Messaging styles,Transport protocols,Service messaging model.
Consider queue system if the producer - consumer applications follows the same type of data format.
Web services (SOAP / REST) is best if one application need the other application to complete the work flow.
Use Queues if the application need asynchronous data transfer.
您真正谈论的是有保证的发布和订阅。 大多数 MOM 软件应该可以轻松支持您的用例。
You're really talking about publish and subscribe with assured delivery. Most MOM software should easily support your use case.
正如前面已经说过的，在我看来，为您当前的情况提供 ESB 就像用锤子砸死苍蝇一样。
ESB 软件本身非常耗时并且需要维护。 如果您使用开源解决方案，它可能比使用许可解决方案（IBM、ORACLE...）更耗时。
当然，ESB 可以完成这项工作，而且开发解决方案确实很容易，但设置 ESB 比解决方案本身要困难得多。
如果您的问题仅限于所描述的情况，我强烈建议您通过 OpenMQ（或类似的）构建一个简单的架构，并通过 JMS 使用它
As it was already said earlier, having an ESB for you current case seems to me like to smash a fly with a hammer.
The ESB software itself will be time consuming and will require maintenance. If you go to open source solution, it might be more time consuming than using a licensed solution (IBM, ORACLE, ...).
Of course an ESB would do the job, and it would be really easy to develop a solution, but setting up an ESB would be way more difficult than doing the solution itself.
If your problem is limited to the case described, I would highly suggest you to build a simple architecture over OpenMQ (or similar), and using it through JMS