消息传递-面向消息的中间件设计基础

ARC314消息传递-面向消息的中间件设计基础,微软的中间件,回归自然MSMQMicrosoftMessageQueue,日程,应用集成技术的发展与回顾消息传递基础面向消息的集成中间件设计实践展望Indigo与未来的集成,应用集成技术的发展与回顾,RPC与应用集成,应用集成中间件设计的目标,应用程序之间需要互相“交谈”不违反“OnceandOnlyOnce”规则在计算的过程中需要集中处理以确保正确性在计算的过程中需要分布处理以确保可缩放性总之机器与机器需要进行“交谈”传统建议我们使用RPC来解决这一问题“让远程通信和本地调用一样容易定义一个接口编写服务器端实现工具生成两者之间需要的通信管道,RPC编程模型,publiclongadd(longl1,longl2);,编译器,method,stub,method,skeleton,响应消息,longI=add(5,10);,publiclongadd(longl1,longl2)returnl1+l2;,请求消息,Method:addParams:5(long),10(long),Return:15(long),实现,接口,客户端,RPC存在的问题,RPC方法忽略了:延迟(网络、应用程序)部分失败和并发,“Objectsthatinteractinadistributedsystemneedtobedealtwithinwaysthatareintrinsicallydifferentfromobjectsthatinteractinasingleaddressspace.”Waldoetal,1994,“95%transparentisnotgoodenough.Infact,itisworsebecauseitdeceivesdevelopers.”WernerVogels,RPC存在的问题,RPC让通信更容易，但代价是:请求/响应通信针对每一个请求，我们期望一个响应阻塞调用者线程直到接收到响应（或者响应超时）代理和Stub强绑定强绑定和类型一致使得编程容易但强绑定和类型一致使得变化非常困难RPC暴露行为,解决方案:消息传递,系统间通过管道通信管道有逻辑地址发送应用程序将消息放到管道中，然后处理其它工作(“fire-and-forget”)管道将数据排队直到被接收应用程序使用（FIFO）,SystemB,系统A,Message,Channel(Queue),解决方案:消息传递,RPC的本质RPC=请求消息+响应消息把消息分开，独立处理允许不同的消息交换模式消息传递暴露数据替代基于接口来创建约束(RPC)基于消息类型来创建约定(messaging)上下文完整的通信,A,Send,Rcv,B,Rcv,Send,是RPC还是2条消息?,面向消息的中间件Message-OrientedMiddleware(MOM),消息=消息头(路由信息)+消息正文支持异步发送不指定格式(松散约束)目的地=命名的消息存储仓库解耦合消息的产生者与消费者便于重定向或者改变调用流程运行环境=多样化的发送方式服务质量:Reliable,transacted,prioritized,deadline-based通信方式:publish-and-subscribe等.消息交换模式Request-response,fire-and-forget,request-asyncresponse,消息传递架构模式,消息传递是一种架构模式，而不是一种技术我们可以使用一个数据库来实现消息传递，但使用数据库不地表我们使用的是消息传递与SOA/WebServices的争论对比:我们可以不使用WebServices来构建SOA使用WebServices并不能保证是SOA架构模式由一组词汇、结构和设计约束组成,消息传递系统举例,文件传输消息:文件目的地:文件系统目录运行环境:操作系统的文件系统数据库消息:数据集目的地:数据库表运行环境:数据库JMS/MSMQ消息:byte,text,object,stream目的地:队列(point-to-point),主题(publish-subscribe)运行环境:MOM环境支持SOAP消息:SOAPXMLformat目的地:(取决于传送方式)运行环境:WebLogic,WS-ReliableMessaging,为什么要使用消息传递,灵活性可缩放性高负载的平缓释放集成性,为什么要使用消息传递?灵活性,更多的数据流选择Fire-and-forget,multicast,disconnected,load-balancing,flowcontrol,priorityrouting等.多粒度的处理逻辑RoutingSlipContent-BasedRouter更容易维护和变化消息格式的变化不需要重新编译不相关的客户端消息流的传递不需要修改中间结点避免并发死锁(和RPC响应阻塞相比),为什么要使用消息传递?可缩放性,竞争消费多个处理端可以读取同一队列发送端不需要进行任何改变粗粒度消息可以使处理端成为“无状态”,发送端,消费者,消费者,消费者,1,消息,2,3,1,2,3,接收者,接收者,竞争消费模式,为什么要使用消息传递?高负载的平缓释放,队列中存储的消息将会等待被处理消息处理端或消费者会经可能快的取走消息如果处理端阶段无法继续:我们可以增加更多的处理端或者等待峰值负载被释放,RateMsgs/sec,QueueLength,time,time,Producer,Consumer,PeakLoad,Steadyprocessingrate,f(x)constant,为什么要使用消息传递?集成性,消息传递不需要一致的类型系统消息就是类型消息传递可以连接多个系统(.NET,J2EE,etc.)XML消息非常适合此类场景其它数据表现形式也可用(CSV,文本)消息传递的灵活性使得集成更容易,消息传递面临的挑战,使用队列来通信，而不是对象双向通信需要至少2个队列：一个用于请求消息，另一个用于响应不存在会话状态时序消息的到达可能是无序的同步通信需要进行更多的设计不存在对象标识消息进入队列，而不是对象不符合通常的客户/服务器模式类似“生产者消费者”，甚至于“点对点”通信,小结,消息传递提供了另一种通信手段消息传递具有灵活性消息传递具有可缩放性消息传递可以在多个管道上操作消息传递需要程序员考虑的更多在消息交换模式中，有很多不同的交换模式存在,面向消息的集成中间件设计实践,本节内容仅提供给现场听众,展望Indigo与未来的集成,未来的挑战极大的简化分布式应用程序开发,不同的任务需要不同的编程模型我们需要安全和可靠的消息传递应用程序需要与其它平台互操作我们需要更有效的面向服务的编程模型,今天的分布式技术,ASMX,WSE,.NETRemoting,System.Messaging,EnterpriseServices,Interopwithotherplatforms,ASMX,Attribute-BasedProgramming,EnterpriseServices,WS-*Protoc