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