MOM（消息导向中间件）解决了什么问题？扩展性？集成？
它们通常用于哪些领域，哪些领域通常不使用它们？
例如，Google是否在其主要搜索引擎或为Gmail提供动力时使用这种解决方案？
像沃尔玛、eBay、联邦快递（基本上是Java商店）和buy.com（基本上是MS商店）这样的大型网站是否需要MOM来解决问题？
当编写Web应用程序并控制服务器端并具有同质环境（例如数十个运行Linux + Java JVMs的Amazon EC2实例）时，在此种情况下，客户端是Web浏览器，这是否有意义？
桌面应用程序需要与服务器通信时是否有意义？
还是“仅”针对大型企业，其中通常有无数不同的系统需要以某种方式进行通信？
我有点困惑它们有什么用处，我认为如果有适当的示例，我就可以更好地理解它们的用途。
这是一个很好的问题。
消息传递的主要用途包括：扩展、卸载工作、集成、监控、事件处理、路由、网络、推送、移动性、缓冲、排队、任务共享、警报、管理、日志记录、批量处理、数据传递、发布/订阅、多播、审计、调度...等等。基本上，对于任何需要数据但不想发出数据库请求的情况都可以使用消息传递。（缓存是另外一个更长的故事）
从另一个角度来看，许多应用程序过去是通过假设用户（人）执行的操作将通过在数据库上执行事务（包括读取、写入）来实现的。但今天，许多操作不是由用户发起的，而是由应用程序发起的。例如，“告诉我我想买的书何时有库存”。解决这类问题的最佳方式是使用某种形式的消息传递。无论您将其称为中间件、Web 推送还是实时沙拉酱，都无关紧要。这都是消息传递。
当您使应用程序能够启动或响应事件时，那么基于松耦合组件的架构就会变得更容易扩展。如果您的消息传递基于稳定、可扩展、可服务的工具，并且最好使用开放标准的 API 和协议，那么将这些组件集成起来也会更容易。
希望这有所帮助。我们试图维护有关消息传递的有用链接列表此处
如有疑问和评论，请与我们联系，我们很容易找到。
回答您的具体问题：
它们通常在哪些领域中使用，哪些领域通常不使用？
和数据库一样，消息系统在各个领域都有应用。
例如，谷歌是否在其主要搜索引擎或Gmail上使用此类解决方案？
谷歌使用很多自家开发的技术，但是他们的开源贡献和公开的使用案例表明，消息传递对于一些主要服务来说非常重要（或者应该是重要的）。
那像沃尔玛、eBay、联邦快递（几乎是Java商店）和buy.com（几乎是MS商店）这样的大型网站呢？ MOM 在那里解决了需要吗？
非常需要。
一个示例用例是扩展网页请求。当用户发出网页请求时，Web服务器将其放入后台处理队列中。这意味着Web服务器可以继续工作，而请求正在处理。这也意味着Web服务器不需要知道如何处理请求，使得系统维护、升级和回滚更加简单，因为主要部分是“解耦”的。
因此，网页请求最终将由后端服务处理，或者可能由许多服务处理，例如“查找书名”、“绘制购物车”、“获取广告”、“检查用户帐户”... 最终所有结果都被放入另一个队列中，等待Web服务器收集和用户响应。通常，系统会设置约100ms的超时时间，以便任何晚到的请求都被丢弃。用户在时间间隔内看到任何已经被处理的内容。这就是为什么一些大型电子商务网站出现了看似分阶段加载的页面的原因之一。
还有很多其他用例...
如果您编写的Web应用程序是在您控制的服务器端运行并具有同质化环境（例如运行Linux + Java JVM的数十个Amazon EC2实例），而客户端是Web浏览器，那么使用MOM是否有意义？
当你有一个未知或无限的用户数量、服务器端实例和应用延迟时，使用消息传递是有意义的，即使只是作为可扩展的非阻塞RPC的基础。
对于需要与服务器通信的桌面应用程序来说，这是否有意义？
在许多情况下有意义。一个非常常见的情况是当服务器将事件推送到桌面应用程序时，例如游戏事件、推文、金融中的价格提醒和系统警报等。
还是仅适用于大型企业，通常需要各种不同的系统进行某种方式的通信?
绝对不仅适用于那些“遗留集成”案例，但它们也很重要。在RabbitMQ中，我们最大的客户就是纯规模或消息量方面的云提供商和大型Web应用程序提供商。
编辑： @cocotwo：正如你所说，中间件就像是一种管道工具...根据我所知，消息导向的中间件并不常见，因为我想象这些进程（函数）需要被调用，就像它们在前端应用程序域内本地可见一样，以便于易于互动。
使用消息可能比RPC调用更具有优势，因为消息会排队在一个安全保持区中，在网络断开连接时进行数据缓存，以允许前端继续运行...这对于“更新特定计费/发票编号的状态”等实例非常有用-通过中间件的单向写入数据到后端。
好的，大公司将拥有先进的系统基础设施，技术人员将全天候负责确保数据流顺畅，因此必须考虑到这一点。我曾经与IBM Global Support合同合作的公司合作，以确保最大的98.999999％的正常运行时间，同时采用热插拔/平衡集群/镜像系统...
而对于RPC，如果发生断开连接，则必须重新启动前端或处理断开事件。这确实取决于消息排队中间件是否实时处理每个消息，并立即将结果传递回前端...
这就是每个（消息排队和RPC相关的中间件）各自拥有其优点和缺点的地方...还有成本控制因素，如支持、最大正常运行时间、开发工作量和培训-这在这里非常重要，因为中间件实际上是私有的（尽管遵循“开放组”布局/标准），并且通过脚本将整个事物粘合在一起非常复杂。
