1 / 28

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

ARC314 消息传递 - 面向消息的中间件设计基础. 微软的中间件. 回归自然 – MSMQ Microsoft Message Queue. 日程. 应用集成技术的发展与回顾 消息传递基础 面向消息的集成中间件设计实践 展望 Indigo 与未来的集成. 应用集成技术的发展与回顾. RPC 与应用集成. 应用集成中间件设计的目标. 应用程序之间需要互相 “ 交谈 ” 不违反 “ Once and Only Once ” 规则 在计算的过程中需要集中处理以确保正确性 在计算的过程中需要分布处理以确保可缩放性 总之机器与机器需要进行 “ 交谈 ”

mathilde-martinez
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. 微软的中间件 回归自然 – MSMQ Microsoft Message Queue

  3. 日程 • 应用集成技术的发展与回顾 • 消息传递基础 • 面向消息的集成中间件设计实践 • 展望Indigo与未来的集成

  4. 应用集成技术的发展与回顾 RPC与应用集成

  5. 应用集成中间件设计的目标 • 应用程序之间需要互相“交谈” • 不违反“Once and Only Once”规则 • 在计算的过程中需要集中处理以确保正确性 • 在计算的过程中需要分布处理以确保可缩放性 • 总之机器与机器需要进行“交谈” • 传统建议我们使用RPC来解决这一问题 • “让远程通信和本地调用一样容易" • 定义一个接口 • 编写服务器端实现 • 工具生成两者之间需要的通信管道

  6. RPC 编程模型 接口 public long add(long l1,long l2); 实现 编译器 客户端 public long add(long l1, long l2) { return l1+l2; } long I = add(5,10); 请求消息 Method: add Params: 5(long),10(long) method method stub skeleton Return: 15(long) 响应消息

  7. RPC存在的问题 • RPC方法忽略了: • 延迟 (网络、应用程序) • 部分失败和并发 • … “Objects that interact in a distributed system need to be dealt with in ways that are intrinsically different from objects that interact in a single address space.” Waldo et al, 1994 “95% transparent is not good enough. In fact, it is worse because it deceives developers.” Werner Vogels

  8. RPC存在的问题 • RPC让通信更容易，但代价是: • 请求/响应通信 • 针对每一个请求，我们期望一个响应 • 阻塞调用者线程直到接收到响应（或者响应超时） • 代理和Stub强绑定 • 强绑定和类型一致使得编程容易 • 但强绑定和类型一致使得变化非常困难 • RPC暴露行为

  9. 解决方案: 消息传递 • 系统间通过管道通信 • 管道有逻辑地址 • 发送应用程序将消息放到管道中，然后处理其它工作(“fire-and-forget”) • 管道将数据排队直到被接收应用程序使用（FIFO） 系统 A System B Channel (Queue) Message

  10. 解决方案: 消息传递 • RPC的本质 • RPC == 请求消息 + 响应消息 • 把消息分开，独立处理 • 允许不同的消息交换模式 • 消息传递暴露数据 • 替代基于接口来创建约束 (RPC)… • 基于消息类型来创建约定 (messaging) • 上下文完整的通信 A B Send Rcv Rcv Send 是RPC还是2条消息?

  11. 面向消息的中间件Message-Oriented Middleware (MOM) • 消息 = 消息头 (路由信息) + 消息正文 • 支持异步发送 • 不指定格式(松散约束) • 目的地 = 命名的消息存储仓库 • 解耦合消息的产生者与消费者 • 便于重定向或者改变调用流程 • 运行环境 = 多样化的发送方式 • 服务质量: Reliable, transacted, prioritized, deadline-based • 通信方式: publish-and-subscribe等. • 消息交换模式 • Request-response, fire-and-forget, request-async response

  12. 消息传递架构模式 • 消息传递是一种架构模式，而不是一种技术 • 我们可以使用一个数据库来实现消息传递，但使用数据库不地表我们使用的是消息传递 • 与SOA/Web Services的争论对比: • 我们可以不使用Web Services来构建SOA • 使用Web Services并不能保证是SOA • 架构模式由一组词汇、结构和设计约束组成

  13. 消息传递系统举例 • 文件传输 • 消息: 文件 • 目的地: 文件系统目录 • 运行环境: 操作系统的文件系统 • 数据库 • 消息: 数据集 • 目的地: 数据库表 • 运行环境: 数据库 • JMS/MSMQ • 消息: byte, text, object, stream … • 目的地: 队列 (point-to-point), 主题 (publish-subscribe) • 运行环境: MOM环境支持 • SOAP • 消息: SOAP XML format • 目的地: (取决于传送方式) • 运行环境: WebLogic, WS-Reliable Messaging

  14. 为什么要使用消息传递 • 灵活性 • 可缩放性 • 高负载的平缓释放 • 集成性

  15. 为什么要使用消息传递?灵活性 • 更多的数据流选择 • Fire-and-forget, multicast, disconnected, load-balancing, flow control, priority routing等. • 多粒度的处理逻辑 • Routing Slip • Content-Based Router • 更容易维护和变化 • 消息格式的变化不需要重新编译不相关的客户端 • 消息流的传递不需要修改中间结点 • 避免并发死锁 (和RPC响应阻塞相比)

  16. 为什么要使用消息传递?可缩放性 • 竞争消费 – 多个处理端可以读取同一队列 • 发送端不需要进行任何改变 • 粗粒度消息可以使处理端成为“无状态” 1 消费者 接收者 3 2 1 2 消费者 发送端 消息 接收者 3 竞争消费模式 消费者

  17. 为什么要使用消息传递?高负载的平缓释放 • 队列中存储的消息将会等待被处理 • 消息处理端或消费者会经可能快的取走消息 • 如果处理端阶段无法继续: • 我们可以增加更多的处理端 • 或者等待峰值负载被释放 Peak Load Rate [Msgs/sec] Steady processing rate Producer Consumer time Queue Length f’(x) constant time

  18. 为什么要使用消息传递?集成性 • 消息传递不需要一致的类型系统 • 消息就是类型 • 消息传递可以连接多个系统(.NET,J2EE,etc.) • XML消息非常适合此类场景 • 其它数据表现形式也可用 (CSV,文本) • 消息传递的灵活性使得集成更容易

  19. 消息传递面临的挑战 • 使用队列来通信，而不是对象 • 双向通信需要至少2个队列：一个用于请求消息，另一个用于响应 • 不存在会话状态 • 时序 – 消息的到达可能是无序的 • 同步通信需要进行更多的设计 • 不存在对象标识 • 消息进入队列，而不是对象 • 不符合通常的客户/服务器模式 • 类似“生产者消费者”，甚至于“点对点”通信

  20. 小结 • 消息传递提供了另一种通信手段 • 消息传递具有灵活性 • 消息传递具有可缩放性 • 消息传递可以在多个管道上操作 • 消息传递需要程序员考虑的更多 • 在消息交换模式中，有很多不同的交换模式存在

  21. 面向消息的集成中间件设计实践

  22. 本节内容仅提供给现场听众

  23. 展望Indigo与未来的集成

  24. 未来的挑战 极大的简化分布式应用程序开发 不同的任务需要不同的编程模型 我们需要安全和可靠的消息传递 应用程序需要与其它平台互操作 我们需要更有效的面向服务的编程模型

  25. .NET Remoting System. Messaging Enterprise Services ASMX WSE 今天的分布式技术

  26. Indigo统一的编程模型 .NET Remoting ASMX Interop with other platforms Extensibility Location transparency Attribute- Based Programming Message- Oriented Programming WS-* Protocol Support Enterprise Services System.Messaging WSE

  27. Basic WS-I 1.0 support Based on the ASP.NET Stack Adapter for WSE 2.0 SQL-to-SQL data messaging Binary protocol Adapter for Indigo Indigo transport channel Service Broker uses Indigo transports for WS-* interoperability BizTalk Server built natively on Indigo foundation 集成技术的未来之路

  28. 您的反馈对我们很重要! 非常感谢您参加今天的交流

More Related