MOM（面向消息的中间件）解决了什么问题？可扩展性？一体化？
它们通常在哪个域中使用，在哪些域中通常不使用？
例如，Google 是否将此类解决方案用于其主要搜索引擎或为 GMail 提供支持？
像沃尔玛、eBay、FedEx（几乎是 Java 商店）和 buy.com（几乎是 MS 商店）这样的大型网站呢？MOM 能解决那里的需求吗？
当您编写一个 Web 应用程序时，您控制服务器端并在那里拥有一个同质环境（例如数十个 Amazon EC2 实例都运行 Linux + Java JVM）以及客户端在哪里，嗯，Web 浏览器，这是否有意义？
对于需要与服务器通信的桌面应用程序是否有意义？
还是它“仅”适用于大型企业的东西，您通常拥有无数需要以某种方式进行通信的不同系统的快乐组合？
我对它们的用途有点困惑，我认为通过举例说明它们在哪里合适和在哪里不合适，我可以更好地理解它们的用途。
这是一个很好的问题。
消息传递的主要用途是：扩展、卸载工作、集成、监控、事件处理、路由、网络、推送、移动性、缓冲、排队、任务共享、警报、管理、日志记录、批处理、数据传递、发布订阅、多播、审计，日程安排，......等等。基本上：任何您需要数据但不想发出数据库请求的地方。（缓存是另一个更长的故事）。
另一种看待这个问题的方法是注意到，过去许多应用程序是通过假设用户（人）将执行将通过在数据库上执行事务（包括读取、写入）来实现的操作来构建的。但是今天，许多动作都不是由用户发起的。相反，它们是应用程序启动的。例如“告诉我我想买的书什么时候有货”。解决此类问题的最佳方法是使用某种消息传递。无论您将其称为中间件、网络推送还是实时沙拉酱，都无关紧要。都是消息传递。
当您使应用程序能够启动或响应事件时，扩展就容易得多，因为您的架构可以基于松散耦合的组件。如果您的消息传递基于稳定、可扩展、可服务的工具，最好使用开放标准 API 和协议，那么集成这些组件也容易得多。
我希望这有帮助。我们尝试在此处维护有关消息传递的有用链接列表
请与任何问题和评论联系，我们很容易找到。
要解决您的具体问题：
它们通常在哪个域中使用，在哪些域中通常不使用？
与数据库一样，消息传递系统随处可见。
例如，Google 是否将此类解决方案用于其主要搜索引擎或为 GMail 提供支持？
谷歌使用了很多本土技术，但他们的很多开源贡献和已知用例表明消息传递是（或应该是）一些主要服务的核心。
像沃尔玛、eBay、FedEx（几乎是 Java 商店）和 buy.com（几乎是 MS 商店）这样的大型网站呢？MOM 能解决那里的需求吗？
非常如此。
一个示例用例是扩展网页请求。当用户发出 Web 请求时，Web 服务器会将其放入队列中以进行后台处理。这意味着 Web 服务器可以在处理请求时继续工作。这也意味着 Web 服务器不需要知道如何处理请求，使得系统维护、升级和回滚变得更加简单，因为主要部分是“解耦的”。
因此，无论如何，Web 请求都会由后端服务或可能由许多服务处理，例如“查找书名”、“绘制购物车”、“获取广告”、“检查用户帐户”……最后所有结果被放到另一个队列中，准备好由网络服务器收集和用户响应。通常，系统将包含大约 100 毫秒的超时，以便任何迟到的请求都被丢弃。用户会看到在时间间隔内处理的任何内容。这就是为什么一些大型电子商务网站的页面似乎分阶段加载的原因之一。
还有很多用例...
当您编写一个 Web 应用程序时，您控制服务器端并在那里拥有一个同质环境（例如数十个 Amazon EC2 实例都运行 Linux + Java JVM）以及客户端在哪里，嗯，Web 浏览器，这是否有意义？
确实。如果您有未知或无限数量的用户、服务器端实例和应用程序延迟，那么使用消息传递是有意义的，即使只是作为非阻塞 RPC 的可扩展基础。
对于需要与服务器通信的桌面应用程序是否有意义？
在很多情况下。一种非常常见的情况是服务器将事件推送到桌面应用程序时，例如游戏事件、推文、金融价格馈送、系统警报......
或者它“只”适用于大型企业的东西，你通常拥有无数需要以某种方式进行通信的不同系统的快乐组合？
绝对不仅适用于那些“遗留集成”案例，而且它们也很重要。在 RabbitMQ，就纯规模或消息量而言，我们拥有的最大客户是云提供商和大型 Web 应用程序提供商。
根据之前的经验，我将只回答一个答案——看看这里大公司使用的中间件——中间件有一个目的——将断开连接的系统（用不同的语言编写）粘合在一起，以便它们可以相互交互并简化业务流程 - Entera 就像我所经历的那样，创建了一个中间层，其中 unix 盒子使用用 C 编写的流程，通过前端编写的与大型机系统（DB2、COBOL）交互在 PowerBuilder 中（我没有命名公司！）。
从我给出的描述来看，Entera 是一个中间件，它承载了许多东西——无论字节序格式如何，数据流的平滑集成，不同语言与中间件代理（代理是CORBA或DCE类进程，符合侦听特定端口的“开放组”）并由IDL指定这使得进程看起来是本地的 - 如果您了解 Microsoft .NET 框架下的远程处理中使用的术语，那么您就离题不远了！中间件生成在编译时链接的存根，并管理进程的创建，将其托管在端口外，在运行时进行多线程处理，以及现代前端（如 .NET、Java , PowerBuilder 甚至是无法形容的 VB6...好吧...VB.NET 对于纯粹主义者来说）可以通过打开与特定 IP 地址上指定端口的连接进行交互，并使用生成的存根直接与其交互。
显然，从所描述的内容中，您可以看到遗留系统如何为它注入新的活力，从而实现流程的可扩展性，其主要缺点是成本因素，可能会达到数千美元。使用大型机作为计费/发票的后端处理系统的大公司，他们产生巨额收入显然可以买得起如此昂贵的产品——对他们来说，这就像把硬币扔进水池……因为使用延长业务流程并为其注入新活力的中间件可以将业务扩展到未来数年，而无需担心附加的“遗留”标签。
顺便说一句，我将其作为我的 BSc 论文的一部分进行。在涵盖此商业前端的信息系统中。sourceforge 上有一个名为FreeDCE的中间件开源版本，但开发工作已经下降或停止。
编辑： @cocotwo：这正是中间件所做的，正如你所说的它是一个管道工具......面向消息的中间件并没有真正听说过 AFAIK，因为我想，需要调用进程（函数）就好像它们在前端的应用程序域中是本地可见的，以便于交互。
与 RPC 调用相比，使用消息可能具有其优势，因为在发生网络断开连接的情况下，消息会在安全保存区域中排队 - 在该方面可能会进行一些数据缓存，以允许前端继续进行...它在“更新特定账单/发票号码的状态”的情况下很有用 - 通过中间件向后端写入数据的单向方式。
好的，大公司将拥有先进的系统基础设施，因为技术人员会全天候不间断地确保数据流的顺利交付，因此必须考虑到这一点。与我合作的公司有 IBM 全球支持合同以按顺序履行以确保在小数点后有 6 个 9 的最大正常运行时间为 99%...使用热插拔/平衡集群/镜像系统...
而对于 RPC，如果发生断开连接，则必须重新启动前端或必须处理断开连接事件。这真的取决于消息队列中间件是否实时处理每条消息并将结果立即传递回前端......
这就是每个（消息队列和 RPC 相关的中间件）都有其优点和缺点的地方......以及成本降低因素，如支持、最长正常运行时间、开发工作和培训 - 这是中间件的一个大问题 - ware 确实是专有的（尽管遵循“The Open Group”布局/标准）并且设置复杂，并且通过脚本将整个事物粘合在一起。
好的答案和讨论在这里。我们的咨询团队有两个首选的“消息传递”解决方案：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 和基于云的开发中发挥着重要作用。