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