Upload
mathilde-martinez
View
147
Download
9
Embed Size (px)
DESCRIPTION
ARC314 消息传递 - 面向消息的中间件设计基础. 微软的中间件. 回归自然 – MSMQ Microsoft Message Queue. 日程. 应用集成技术的发展与回顾 消息传递基础 面向消息的集成中间件设计实践 展望 Indigo 与未来的集成. 应用集成技术的发展与回顾. RPC 与应用集成. 应用集成中间件设计的目标. 应用程序之间需要互相 “ 交谈 ” 不违反 “ Once and Only Once ” 规则 在计算的过程中需要集中处理以确保正确性 在计算的过程中需要分布处理以确保可缩放性 总之机器与机器需要进行 “ 交谈 ” - PowerPoint PPT Presentation
Citation preview
应用集成中间件设计的目标应用集成中间件设计的目标
应用程序之间需要互相“交谈”应用程序之间需要互相“交谈”不违反“不违反“ Once and Only Once”Once and Only Once” 规则规则在计算的过程中需要集中处理以确保正确性在计算的过程中需要集中处理以确保正确性在计算的过程中需要分布处理以确保可缩放性在计算的过程中需要分布处理以确保可缩放性总之机器与机器需要进行“交谈”总之机器与机器需要进行“交谈”
传统建议我们使用传统建议我们使用 RPCRPC 来解决这一问题来解决这一问题““ 让远程通信和本地调用一样容易让远程通信和本地调用一样容易 ""
定义一个接口定义一个接口编写服务器端实现编写服务器端实现工具生成两者之间需要的通信管道工具生成两者之间需要的通信管道
RPC RPC 编程模型编程模型
public long add(long l1,long l2);
编译器
method
stub
method
skeleton
响应消息
long I = add(5,10);
public long add(long l1, long l2) { return l1+l2; }
请求消息Method: addMethod: add
Params: 5(long),10(long)Params: 5(long),10(long)
Return: 15(long)Return: 15(long)
实现
接口
客户端
RPCRPC 存在的问题存在的问题
RPCRPC 方法忽略了方法忽略了 ::
延迟 延迟 (( 网络、应用程序网络、应用程序 ))
部分失败和并发部分失败和并发……
““Objects that interact in a distributed system need to be dealt with Objects that interact in a distributed system need to be dealt with in ways that are intrinsically different from objects that interact in in ways that are intrinsically different from objects that interact in a single address space.” a single address space.” Waldo et al, 1994
““95% transparent is not good enough. In fact, it is worse because 95% transparent is not good enough. In fact, it is worse because it deceives developers.” it deceives developers.” Werner Vogels
RPCRPC 存在的问题存在的问题
RPCRPC 让通信更容易,但代价是让通信更容易,但代价是 ::请求请求 // 响应通信响应通信
针对每一个请求,我们期望一个响应针对每一个请求,我们期望一个响应阻塞调用者线程直到接收到响应(或者响应超时)阻塞调用者线程直到接收到响应(或者响应超时)
代理和代理和 StubStub 强绑定强绑定强绑定和类型一致使得编程容易强绑定和类型一致使得编程容易但强绑定和类型一致使得变化非常困难但强绑定和类型一致使得变化非常困难
RPCRPC 暴露行为暴露行为
解决方案解决方案 : : 消息传递消息传递
系统间通过管道通信系统间通过管道通信管道有逻辑地址管道有逻辑地址发送应用程序将消息放到管道中,然后处理其它工作发送应用程序将消息放到管道中,然后处理其它工作 (“fire-and-(“fire-and-forget”)forget”)
管道将数据排队直到被接收应用程序使用(管道将数据排队直到被接收应用程序使用( FIFOFIFO ))
SystemB
系统A
MessageChannel(Queue)
解决方案解决方案 : : 消息传递消息传递
RPCRPC 的本质的本质RPC == RPC == 请求消息 请求消息 + + 响应消息响应消息把消息分开,独立处理把消息分开,独立处理允许不同的消息交换模式允许不同的消息交换模式
消息传递暴露数据消息传递暴露数据替代基于接口来创建约束 替代基于接口来创建约束 (RPC)…(RPC)…
基于消息类型来创建约定基于消息类型来创建约定 (messaging)(messaging)
上下文完整的通信上下文完整的通信
A Send
Rcv
BRcv
Send
是 RPC 还是 2 条消息 ?
面向消息的中间件面向消息的中间件Message-Oriented Middleware Message-Oriented Middleware (MOM)(MOM)消息 消息 = = 消息头 消息头 (( 路由信息路由信息 ) + ) + 消息正文消息正文
支持异步发送支持异步发送不指定格式不指定格式 (( 松散约束松散约束 ))
目的地 目的地 = = 命名的消息存储仓库命名的消息存储仓库解耦合消息的产生者与消费者解耦合消息的产生者与消费者便于重定向或者改变调用流程便于重定向或者改变调用流程
运行环境 运行环境 = = 多样化的发送方式多样化的发送方式服务质量服务质量 : Reliable, transacted, prioritized, : Reliable, transacted, prioritized, deadline-baseddeadline-based通信方式通信方式 : publish-and-subscribe: publish-and-subscribe 等等 ..
消息交换模式消息交换模式Request-response, fire-and-forget, Request-response, fire-and-forget, request-async responserequest-async response
消息传递架构模式消息传递架构模式
消息传递是一种架构模式,而不是一种技术消息传递是一种架构模式,而不是一种技术我们可以使用一个数据库来实现消息传递,但使用数据库我们可以使用一个数据库来实现消息传递,但使用数据库不地表我们使用的是消息传递不地表我们使用的是消息传递与与 SOA/Web ServicesSOA/Web Services 的争论对比的争论对比 ::
我们可以不使用我们可以不使用 Web ServicesWeb Services 来构建来构建 SOASOA
使用使用 Web ServicesWeb Services 并不能保证是并不能保证是 SOASOA
架构模式由一组词汇、结构和设计约束组成架构模式由一组词汇、结构和设计约束组成
消息传递系统举例消息传递系统举例文件传输文件传输
消息消息 : : 文件文件目的地目的地 : : 文件系统目录文件系统目录运行环境运行环境 : : 操作系统的文件系统操作系统的文件系统
数据库数据库消息消息 : : 数据集数据集目的地目的地 : : 数据库表数据库表运行环境运行环境 : : 数据库数据库
JMS/MSMQJMS/MSMQ消息消息 : byte, text, object, stream …: byte, text, object, stream …
目的地目的地 : : 队列 队列 (point-to-point), (point-to-point), 主题 主题 (publish-subscribe)(publish-subscribe)
运行环境运行环境 : MOM: MOM 环境支持环境支持SOAPSOAP
消息消息 : SOAP XML format: SOAP XML format
目的地目的地 : (: (取决于传送方式取决于传送方式 ))
运行环境运行环境 : WebLogic, WS-Reliable Messaging: WebLogic, WS-Reliable Messaging
为什么要使用消息传递为什么要使用消息传递 ??灵活性灵活性
更多的数据流选择更多的数据流选择Fire-and-forget, multicast, disconnected, load-Fire-and-forget, multicast, disconnected, load-balancing, balancing, flow control, priority routingflow control, priority routing 等等 ..
多粒度的处理逻辑多粒度的处理逻辑Routing SlipRouting SlipContent-Based RouterContent-Based Router
更容易维护和变化更容易维护和变化消息格式的变化不需要重新编译不相关的客户端消息格式的变化不需要重新编译不相关的客户端消息流的传递不需要修改中间结点消息流的传递不需要修改中间结点
避免并发死锁 避免并发死锁 (( 和和 RPCRPC 响应阻塞相比响应阻塞相比 ))
为什么要使用消息传递为什么要使用消息传递 ??可缩放性可缩放性竞争消费 竞争消费 – – 多个处理端可以读取同一队列多个处理端可以读取同一队列发送端不需要进行任何改变发送端不需要进行任何改变粗粒度消息可以使处理端成为“无状态”粗粒度消息可以使处理端成为“无状态”
发送端 消费者
消费者
消费者
1
消息
23
1
2
3 接收者
接收者
竞争消费模式
为什么要使用消息传递为什么要使用消息传递 ??高负载的平缓释放高负载的平缓释放
队列中存储的消息将会等待被处理队列中存储的消息将会等待被处理消息处理端或消费者会经可能快的取走消息消息处理端或消费者会经可能快的取走消息如果处理端阶段无法继续如果处理端阶段无法继续 ::
我们可以增加更多的处理端我们可以增加更多的处理端或者等待峰值负载被释放或者等待峰值负载被释放
Rate [Msgs/sec]
Queue Length
time
time
Producer
Consumer
Peak Load
Steady processing
rate
f’(x) constant
为什么要使用消息传递为什么要使用消息传递 ??集成性集成性
消息传递不需要一致的类型系统消息传递不需要一致的类型系统消息就是类型消息就是类型
消息传递可以连接多个系统消息传递可以连接多个系统 (.NET,J2EE,etc.)(.NET,J2EE,etc.)XMLXML 消息非常适合此类场景消息非常适合此类场景其它数据表现形式也可用 其它数据表现形式也可用 (CSV,(CSV, 文本文本 ))
消息传递的灵活性使得集成更容易消息传递的灵活性使得集成更容易
消息传递面临的挑战消息传递面临的挑战
使用队列来通信,而不是对象使用队列来通信,而不是对象双向通信需要至少双向通信需要至少 22 个队列:一个用于请求消息,另一个用于响个队列:一个用于请求消息,另一个用于响应应
不存在会话状态不存在会话状态时序 时序 – – 消息的到达可能是无序的消息的到达可能是无序的同步通信需要进行更多的设计同步通信需要进行更多的设计
不存在对象标识不存在对象标识消息进入队列,而不是对象消息进入队列,而不是对象不符合通常的客户不符合通常的客户 // 服务器模式服务器模式类似“生产者消费者类似“生产者消费者””,甚至于“点对点”通信,甚至于“点对点”通信
小结小结
消息传递提供了另一种通信手段消息传递提供了另一种通信手段消息传递具有灵活性消息传递具有灵活性消息传递具有可缩放性消息传递具有可缩放性消息传递可以在多个管道上操作消息传递可以在多个管道上操作消息传递需要程序员考虑的更多消息传递需要程序员考虑的更多在消息交换模式中,有很多不同的交换模式存在在消息交换模式中,有很多不同的交换模式存在
未来的挑战 未来的挑战 极大的简化分布式应用程序开发极大的简化分布式应用程序开发
不同的任务需要不同的编程模型不同的任务需要不同的编程模型我们需要安全和可靠的消息传递我们需要安全和可靠的消息传递应用程序需要与其它平台互操作应用程序需要与其它平台互操作我们需要更有效的面向服务的编程模型我们需要更有效的面向服务的编程模型
InteropInteropwith otherwith otherplatformsplatforms
ASMX
Attribute- Attribute- BasedBased
ProgrammingProgramming
Enterprise Services
WS-*WS-*ProtocolProtocolSupportSupport
WSE
Message-Message-OrientedOriented
ProgrammingProgramming
System.Messaging
ExtensibilityExtensibilityLocation Location
transparencytransparency
.NET Remoting
IndigoIndigo 统一的编程模型统一的编程模型
Basic WS-I 1.0 supportBased on the ASP.NET
StackAdapter for WSE 2.0
SQL-to-SQL data messaging
Binary protocol
Adapter for Indigo Indigo transport channel
BizTalk Server built natively on Indigo foundation
Service Broker uses Indigo transports for WS-* interoperability
集成技术的未来之路集成技术的未来之路