像AMQP这样的面向消息的中间件在哪些领域有用? [英] In which domains are message oriented middleware like AMQP useful?

问题描述

MOM(面向消息的中间件)解决什么问题?可扩展性?整合吗?

What problem do MOM (Message Oriented Middleware) solve? Scalability? Integration?

它们通常在哪个域中使用，不通常在哪些域中使用?

In which domain are they typically used and in which domains are they typically not used?

例如，谷歌是在为其主要搜索引擎使用这种解决方案还是为GMail提供动力?

For example, say, is Google using such solution for it's main search engine or to power GMail?

关于大型网站，如沃尔玛，eBay，FedEx(几乎是Java商店)和buy.com(几乎是MS商店)呢? MOM在那里解决了需求吗?

What about big websites like Walmart, eBay, FedEx (pretty much a Java shop) and buy.com (pretty much an MS shop)? Does MOM solve a need there?

当您编写一个Webapp来控制服务器端并在那里有一个同质环境(例如数十个都运行Linux + Java JVM的Amazon EC2实例)并且客户端在哪里时，这有意义吗? Web浏览器?

Does it make any sense when you're writing a Webapp where you control the server-side and have an homogenous environment (say tens of Amazon EC2 instances all running Linux + Java JVMs) there and where the clients are, well, Web browsers?

需要与服务器通信的桌面应用有意义吗?

Does it make sense for desktop apps that need to communicate with a server?

还是仅对于大型企业而言，您通常将无数种需要以某种方式进行通信的不同系统混合在一起?

Or is it 'only' for big enterprise stuff where you typically have a happy mix of countless of different systems that needs to communicate in a way or another?

对于它们的用途，我有点困惑，我认为通过举例说明它们合适和不适合的地方，我可以更好地理解它们的用法.

I'm a bit confused as to what they're useful for and I think that with example of where they're appropriate and where they're not appropriate I could better understand their use.

推荐答案

这是一个很好的问题.

消息传递的主要用途是:扩展，卸载工作，集成，监视，事件处理，路由，联网，推送，移动性，缓冲，队列，任务共享，警报，管理，日志记录，批处理，数据传递，pubsub，多播，审核，调度等.基本上:任何需要数据但又不想发出数据库请求的地方. (缓存是另外一个较长的故事).

The main uses of messaging are: scaling, offloading work, integration, monitoring, event handling, routing, networking, push, mobility, buffering, queueing, task sharing, alerts, management, logging, batch, data delivery, pubsub, multicast, audit, scheduling, ... and more. Basically: anything where you need data but don't want to make a database request. (Caching is another, longer story).

查看此问题的另一种方法是注意到，过去通常通过假设用户(人员)执行将通过在数据库上执行事务(包括读取，写入)来实现的操作来构建许多应用程序.但是今天，许多动作不是用户发起的.而是由应用程序启动.例如，当我要购买的书有货时告诉我".解决此类问题的最佳方法是使用某种形式的消息传递.无论您称其为中间件，Web推送还是实时沙拉酱，都没有关系.都是消息.

Another way of looking at this is to notice that many applications used to be built by assuming that users (people) would perform actions that would be fulfilled by executing a transaction on a database (including reads, writes). But today, many actions are not user-initiated. Instead they are application-initiated. For example "tell me when the book that I want to buy is in stock". The best way to solve this class of problems is with messaging of some sort. Whether you call it middleware or web push or real time salad dressing does not matter. It's all messaging.

启用应用程序以启动事件或对事件做出反应时，由于架构可以基于松散耦合的组件，因此扩展起来要容易得多.如果您的消息传递基于稳定，可扩展，可维护的工具，并且最好使用开放标准API和协议，则集成这些组件也容易得多.

When you enable applications to initiate or react to events, then it is much easier to scale because your architecture can be based on loosely coupled components. It is also much easier to integrate those components if your messaging is based on a stable, scalable, serviceable tool, preferably using open standard APIs and protocols.

我希望这会有所帮助.我们尝试在此处

I hope this helps. We try to maintain a list of useful links about messaging here

请就任何一个问题和评论取得联系，我们非常容易找到.

Please get in touch with questions and comments on any of this, we are dead easy to find.

这篇关于像AMQP这样的面向消息的中间件在哪些领域有用?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！