像 AMQP 这样的面向消息的中间件在哪些领域有用？

Question

MOM（面向消息的中间件）解决了什么问题？可扩展性？整合？

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

例如，Google 是否将此类解决方案用于其主要搜索引擎或为 GMail 提供支持？

Walmart、eBay、FedEx（几乎是 Java 商店）和 buy.com（几乎是 MS 商店）等大型网站呢？ MOM 能解决那里的需求吗？

当您编写一个 Web 应用程序时，您控制服务器端并在其中拥有同质环境（例如数十个 Amazon EC2 实例都运行 Linux + Java JVM）以及客户端所在的位置，这是否有意义？网络浏览器？

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

或者它“只”适用于大型企业的东西，您通常会快乐地混合无数不同的系统，这些系统需要以某种方式进行通信？

我对它们的用途有点困惑，我认为通过举例说明它们在哪里合适和不合适，我可以更好地理解它们的用途。

Answer 1

解决您的具体问题：

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

与数据库一样，消息传递系统随处可见。

例如，Google 是否将此类解决方案用于其主要搜索引擎或为 GMail 提供支持？

Google 使用了许多本土技术，但他们的许多开源贡献和已知用例表明消息传递是（或应该是）某些主要服务的核心。

Walmart、eBay、FedEx（几乎是 Java 商店）和 buy.com（几乎是 MS 商店）等大型网站呢？ MOM 能解决那里的需求吗？

非常喜欢。

一个示例用例是扩展网页请求。当用户发出 Web 请求时，Web 服务器会将其放入队列中以进行后台处理。这意味着 Web 服务器可以在处理请求时继续工作。这也意味着 Web 服务器不需要知道如何处理请求，使得系统维护、升级和回滚变得更加简单，因为主要部分是“解耦的”。

因此，无论如何，Web 请求都会由后端服务处理，或者可能由许多服务处理，例如“查找书名”、“绘制购物车”、“获取广告”、“检查用户帐户”。 . 最后，所有结果都被放到另一个队列中，准备好由 Web 服务器收集和用户响应。通常，系统将包含大约 100 毫秒的超时，以便任何迟到的请求都被丢弃。用户会看到在时间间隔内处理的任何内容。这就是为什么一些大型电子商务网站的页面似乎是分阶段加载的原因之一。

还有更多用例...

当您编写一个 Web 应用程序时，您控制服务器端并在其中拥有同质环境（例如数十个 Amazon EC2 实例都运行 Linux + Java JVM）以及客户端所在的位置，这是否有意义？网络浏览器？

当然。如果您的用户、服务器端实例和应用程序延迟的数量未知或无限，那么使用消息传递是有意义的，即使只是作为非阻塞 RPC 的可扩展基础。

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

在很多情况下。一种非常常见的情况是服务器将事件推送到桌面应用程序，例如游戏事件、推文、金融中的价格馈送、系统警报......

或者它“只”适用于大型企业的东西，您通常会快乐地混合无数不同的系统，这些系统需要以某种方式进行通信？

绝对不仅适用于那些“遗留集成”案例，而且它们也很重要。在 RabbitMQ，就纯规模或消息量而言，我们拥有的最大客户是云提供商和大型 Web 应用程序提供商。

Answer 2

这是一个很好的问题。

消息传递的主要用途是：扩展、卸载工作、集成、监控、事件处理、路由、网络、推送、移动性、缓冲、排队、任务共享、警报、管理、日志记录、批处理、数据传递、发布订阅、多播、审计、调度等。基本上：您需要数据但不想发出数据库请求的任何地方。 （缓存是另一个更长的故事）。

另一种看待这个问题的方式是注意到，过去许多应用程序是通过假设用户（人）将执行将通过在数据库上执行事务（包括读取、写入）来实现的操作来构建的。但是今天，许多动作都不是由用户发起的。相反，它们是应用程序启动的。例如“告诉我我想买的书什么时候有货”。解决此类问题的最佳方法是使用某种消息传递。无论您将其称为中间件、网络推送还是实时沙拉酱，都无关紧要。都是消息传递。

当您使应用程序能够启动或响应事件时，扩展起来会容易得多，因为您的架构可以基于松散耦合的组件。如果您的消息传递基于稳定、可扩展、可服务的工具，最好使用开放标准 API 和协议，那么集成这些组件也会容易得多。

我希望这会有所帮助。我们尝试维护有关消息传递的有用链接列表here

请就这方面的任何问题和 cmet 联系，我们很容易找到。

Answer 3

根据以前的经验，我将只回答一个答案 - 看看这里的大公司使用的 middle-ware - 中间件有一个目的 - 将断开连接的系统（用不同的语言编写）粘合在一起以便他们可以相互交互并简化业务流程 - Entera 我有经验，创建一个中间层，其中 unix 框使用用 C 编写的流程，通过前端与大型机系统（DB2，COBOL）交互-end 用 PowerBuilder 编写（我不是在命名公司！）。

根据我给出的描述，Entera 是一个中间件，它承载了许多东西——无论字节序格式如何，数据流的顺利集成，不同语言与中间件代理（a代理是CORBA 或DCE 类似的进程，它符合侦听特定端口的“开放组”）并由IDL 指定，这使得进程看起来是本地的 - 如果您了解术语在 Microsoft 的 .NET Framework 下的 Remoting 中使用，你就离题不远了！中间件生成在编译时链接的存根，并管理进程的创建，将其托管在端口外，在运行时进行多线程处理，以及现代前端（如 .NET、Java , PowerBuilder 甚至是无法形容的 VB6...ok...VB.NET 对于那里的纯粹主义者）可以通过打开与特定 IP 地址上指定端口的连接进行交互，并使用生成的存根直接与其交互。

显然，从所描述的内容中，您可以看到遗留系统如何为其注入新的活力，从而实现流程的可扩展性，其主要缺点是成本因素可能会达到数千美元。使用大型机作为其计费/发票的后端处理系统的大公司，他们产生巨额收入，显然可以负担得起如此昂贵的产品——对他们来说，这就像把便士扔进水池……因为使用延长业务流程并为其注入新活力的中间件可以将业务扩展到未来数年，而无需担心附加的“遗留”标签。

顺便说一句，我将其作为我的 BSc 论文的一部分进行。在涵盖此商业前端的信息系统中。 sourceforge 上有一个开源版本的中间件，名为 FreeDCE，但开发工作已经下降或停止。

编辑： @cocotwo：这正是中间件所做的，正如你所说的那样，它是一个管道工具......面向消息的中间件并没有真正听说过AFAIK，因为我想，进程（函数）需要被调用，好像它们在前端的应用程序域中是本地可见的，以使其易于交互。

使用消息可能比 RPC 调用有其优势，因为在发生网络断开连接的情况下，消息会在安全保存区域中排队 - 在该方面可能会进行一些数据缓存以允许前端无论如何都要继续......这在“更新特定账单/发票号码的状态”的情况下很有用 - 通过中间件向后端写入数据的单向方式。

好的，大公司将拥有先进的系统基础架构，因为技术人员全天候全天候确保数据流的顺利交付，因此必须考虑到这一点。与我合作的公司与 IBM 全球支持签订合同完成以确保最大正常运行时间 99%，小数点后有 6 个 9...使用热插拔/平衡集群/镜像系统...

而对于 RPC，如果发生断开连接，则必须重新启动前端或必须​​处理断开连接事件。这真的取决于消息队列中间件是否实时处理每条消息并立即将结果传回前端......

这是每个（消息队列和 RPC 相关的中间件）各有优缺点的地方......还有成本缓解因素，如支持、最长正常运行时间、开发工作和培训 - 这是一个大问题因为中间件是真正专有的（尽管遵循“The Open Group”布局/标准）并且设置复杂，并且通过脚本将整个事物粘合在一起。

Answer 4

这里有很好的答案和讨论。我们的咨询团队有两个首选的“消息传递”解决方案：RabittMQ 和 NXTera，一个高速 RPC 中间件，即上面提到的 Entera 的现代版本。我和我的合作伙伴已经使用 RabittMQ 开发了几种解决方案，它是目前该领域可用的最佳工具。此外，我碰巧在生产 NXTera/Entera 的公司工作。

根据经验，我可以清楚地说，这两种产品都满足了如上所述的可靠性和低维护需求。在某些情况下，像 RabittMQ 这样的消息传递服务是正确的选择——其中需要发布和订阅、认证交付、排队或存储转发。

在其他情况下，RPC（远程过程调用）是企业或基于云的应用程序的事务和分布式处理的最佳和最快的解决方案。当使用 RPC 是正确的，但 SOAP/.NET（是的，这些是 RPC 实现）太慢、太昂贵或太复杂时，像 NXTera/Entera 这样的轻量级高速 RPC 中间件是我们的正确选择。

在 RPC 中间件和面向消息的中间件之间存在一些用例重叠，并且您可以成功使用其中任何一个。但两者都是强大而可靠的选择。

与我合作的大公司同时使用 RPC 和 MoM。就互联网公司而言，Google（Protocol Buffers）和 Facebook（Thrift）表明 RPC 在现代 Web 和基于云的开发中大有可为。