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