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

Presentation on theme: "ARC314 消息传递 -面向消息的中间件设计基础"— Presentation transcript:

1 ARC314 消息传递 -面向消息的中间件设计基础
2018年12月2日6时5分 ARC314 消息传递 -面向消息的中间件设计基础 © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

2 Microsoft Message Queue
2018年12月2日6时5分 微软的中间件 回归自然 – MSMQ Microsoft Message Queue © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

3 日程 应用集成技术的发展与回顾 消息传递基础 面向消息的集成中间件设计实践 展望Indigo与未来的集成 2018年12月2日6时5分
© 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

4 应用集成技术的发展与回顾 RPC与应用集成 2018年12月2日6时5分
© 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

5 应用集成中间件设计的目标 应用程序之间需要互相“交谈” 传统建议我们使用RPC来解决这一问题
2018年12月2日6时5分 应用集成中间件设计的目标 应用程序之间需要互相“交谈” 不违反“Once and Only Once”规则 在计算的过程中需要集中处理以确保正确性 在计算的过程中需要分布处理以确保可缩放性 总之机器与机器需要进行“交谈” 传统建议我们使用RPC来解决这一问题 “让远程通信和本地调用一样容易" 定义一个接口 编写服务器端实现 工具生成两者之间需要的通信管道 © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

6 public long add(long l1,long l2); public long add (long l1, long l2)
2018年12月2日6时5分 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 Return: 15(long) skeleton 响应消息 © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

7 RPC存在的问题 RPC方法忽略了: 延迟 (网络、应用程序) 部分失败和并发 …
2018年12月2日6时5分 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 © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

8 RPC存在的问题 RPC让通信更容易，但代价是: RPC暴露行为 请求/响应通信 代理和Stub强绑定 针对每一个请求，我们期望一个响应
2018年12月2日6时5分 RPC存在的问题 RPC让通信更容易，但代价是: 请求/响应通信 针对每一个请求，我们期望一个响应 阻塞调用者线程直到接收到响应（或者响应超时） 代理和Stub强绑定 强绑定和类型一致使得编程容易 但强绑定和类型一致使得变化非常困难 RPC暴露行为 © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

9 解决方案: 消息传递 系统间通过管道通信 管道有逻辑地址
2018年12月2日6时5分 解决方案: 消息传递 系统 A System B Channel (Queue) Message 系统间通过管道通信 管道有逻辑地址 发送应用程序将消息放到管道中，然后处理其它工作(“fire-and-forget”) 管道将数据排队直到被接收应用程序使用（FIFO） © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

10 解决方案: 消息传递 A B 是RPC还是2条消息? RPC的本质 消息传递暴露数据 RPC == 请求消息 + 响应消息
2018年12月2日6时5分 解决方案: 消息传递 RPC的本质 RPC == 请求消息 + 响应消息 把消息分开，独立处理 允许不同的消息交换模式 消息传递暴露数据 替代基于接口来创建约束 (RPC)… 基于消息类型来创建约定 (messaging) 上下文完整的通信 A B Send Rcv Rcv Send 是RPC还是2条消息? © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

11 面向消息的中间件 Message-Oriented Middleware (MOM)
2018年12月2日6时5分 面向消息的中间件 Message-Oriented Middleware (MOM) 消息 = 消息头 (路由信息) + 消息正文 支持异步发送 不指定格式(松散约束) 目的地 = 命名的消息存储仓库 解耦合消息的产生者与消费者 便于重定向或者改变调用流程 运行环境 = 多样化的发送方式 服务质量: Reliable, transacted, prioritized, deadline-based 通信方式: publish-and-subscribe等. 消息交换模式 Request-response, fire-and-forget, request-async response © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

12 消息传递架构模式 消息传递是一种架构模式，而不是一种技术 我们可以使用一个数据库来实现消息传递，但使用数据库不地表我们使用的是消息传递
2018年12月2日6时5分 消息传递架构模式 消息传递是一种架构模式，而不是一种技术 我们可以使用一个数据库来实现消息传递，但使用数据库不地表我们使用的是消息传递 与SOA/Web Services的争论对比: 我们可以不使用Web Services来构建SOA 使用Web Services并不能保证是SOA 架构模式由一组词汇、结构和设计约束组成 © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

13 消息传递系统举例 文件传输 数据库 JMS/MSMQ SOAP 消息: 文件 目的地: 文件系统目录 运行环境: 操作系统的文件系统
2018年12月2日6时5分 消息传递系统举例 文件传输 消息: 文件 目的地: 文件系统目录 运行环境: 操作系统的文件系统 数据库 消息: 数据集 目的地: 数据库表 运行环境: 数据库 JMS/MSMQ 消息: byte, text, object, stream … 目的地: 队列 (point-to-point), 主题 (publish-subscribe) 运行环境: MOM环境支持 SOAP 消息: SOAP XML format 目的地: (取决于传送方式) 运行环境: WebLogic, WS-Reliable Messaging © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

14 为什么要使用消息传递 灵活性 可缩放性 高负载的平缓释放 集成性 2018年12月2日6时5分
© 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

15 为什么要使用消息传递? 灵活性 更多的数据流选择 多粒度的处理逻辑 更容易维护和变化 避免并发死锁 (和RPC响应阻塞相比)
2018年12月2日6时5分 为什么要使用消息传递? 灵活性 更多的数据流选择 Fire-and-forget, multicast, disconnected, load-balancing, flow control, priority routing等. 多粒度的处理逻辑 Routing Slip Content-Based Router 更容易维护和变化 消息格式的变化不需要重新编译不相关的客户端 消息流的传递不需要修改中间结点 避免并发死锁 (和RPC响应阻塞相比) © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

16 为什么要使用消息传递? 可缩放性 竞争消费 – 多个处理端可以读取同一队列 发送端不需要进行任何改变 粗粒度消息可以使处理端成为“无状态”
2018年12月2日6时5分 为什么要使用消息传递? 可缩放性 竞争消费 – 多个处理端可以读取同一队列 发送端不需要进行任何改变 粗粒度消息可以使处理端成为“无状态” 1 消费者 接收者 3 2 1 2 发送端 消息 消费者 接收者 3 竞争消费模式 消费者 © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

17 Steady processing rate
2018年12月2日6时5分 为什么要使用消息传递? 高负载的平缓释放 队列中存储的消息将会等待被处理 消息处理端或消费者会经可能快的取走消息 如果处理端阶段无法继续: 我们可以增加更多的处理端 或者等待峰值负载被释放 Peak Load Rate [Msgs/sec] Steady processing rate Producer Consumer time Queue Length f’(x) constant time © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

18 为什么要使用消息传递? 集成性 消息传递不需要一致的类型系统 消息传递可以连接多个系统(.NET,J2EE,etc.)
2018年12月2日6时5分 为什么要使用消息传递? 集成性 消息传递不需要一致的类型系统 消息就是类型 消息传递可以连接多个系统(.NET,J2EE,etc.) XML消息非常适合此类场景 其它数据表现形式也可用 (CSV,文本) 消息传递的灵活性使得集成更容易 © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

19 消息传递面临的挑战 使用队列来通信，而不是对象 不存在会话状态 不存在对象标识 双向通信需要至少2个队列：一个用于请求消息，另一个用于响应
2018年12月2日6时5分 消息传递面临的挑战 使用队列来通信，而不是对象 双向通信需要至少2个队列：一个用于请求消息，另一个用于响应 不存在会话状态 时序 – 消息的到达可能是无序的 同步通信需要进行更多的设计 不存在对象标识 消息进入队列，而不是对象 不符合通常的客户/服务器模式 类似“生产者消费者”，甚至于“点对点”通信 © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

20 小结 消息传递提供了另一种通信手段 消息传递具有灵活性 消息传递具有可缩放性 消息传递可以在多个管道上操作 消息传递需要程序员考虑的更多
2018年12月2日6时5分 小结 消息传递提供了另一种通信手段 消息传递具有灵活性 消息传递具有可缩放性 消息传递可以在多个管道上操作 消息传递需要程序员考虑的更多 在消息交换模式中，有很多不同的交换模式存在 © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

21 2018年12月2日6时5分 面向消息的集成中间件 设计实践 © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

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

23 2018年12月2日6时5分 展望Indigo与未来的集成 © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

24 未来的挑战 极大的简化分布式应用程序开发 不同的任务需要不同的编程模型 我们需要安全和可靠的消息传递 应用程序需要与其它平台互操作
2018年12月2日6时5分 未来的挑战 极大的简化分布式应用程序开发 不同的任务需要不同的编程模型 我们需要安全和可靠的消息传递 应用程序需要与其它平台互操作 我们需要更有效的面向服务的编程模型 Speaker Notes The next challenge we face is actually something we’ve been doing for quite some time now – building distributed applications. As developers, we’ve been building distributed applications for years now. However, I’ll assert that it’s never been as easy as it should be, or could be. While our ability to build distributed applications has certainly changed over the past few years, it hasn’t necessarily gotten any easier. In fact, additional capabilities and options for building distributed applications have brought with them additional complexity! Security is critical for applications, but often complicated to implement. Standards-based interoperability needs to be taken into account for communication across heterogeneous systems. We have different programming models with different capabilities that are focused on different application scenarios: Web services, distributed objects, and message queuing all helped address development needs, but again, they’ve added more complexity to our lives. They require us to learn different programming paradigms and often contain functionality and features that don’t compose (combine) well with one another. With the resurgence of service orientation and service-oriented architectures (SOA), we also need to design our applications for flexibility in the face of change. It was these types of development challenges in building distributed applications that drove the Indigo product design goals. Transition to next slide: So at a high level, the goal of Indigo is to radically simplify the development of distributed applications. We can summarize Indigo’s design goals in three key concepts… © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

25 今天的分布式技术 System. .NET Messaging Remoting Enterprise Services ASMX WSE
2018年12月2日6时5分 今天的分布式技术 System. Messaging .NET Remoting ASMX Enterprise Services WSE Speaker Notes Today, when we build distributed applications, we have a choice of programming models. Each programming model has a different set of APIs, different feature sets, and a different core set of scenarios: ASP.NET Web Services (ASMX) – Our current Web services stack provides basic Web services support and interoperability with Web services running on non-Microsoft platforms. Web Services Enhancements (WSE) – A supported extension to the .NET Framework that provides end-to-end standards-based security for Web services. System.Messaging – This namespace in the .NET Framework provides managed APIs to MSMQ, enabling developers to build asynchronous reliable distributed applications. Enterprise Services – Provided through the System.EnterpriseServices namespace in the .NET Framework, Enterprise Services (or “ES”) provides managed APIs to COM+. COM+ provides component-based programming for doing enterprise critical functionality such as transactions. Remoting – Provided through the System.Remoting namespace in the .NET Framework, .NET Remoting exposes the CLR type system remotely and provides location transparency for objects. While these technologies provide a wide range of functionality, they exist in silos – isolated from one another. This creates an impedance mismatch across the technologies hindering our ability as developers to “compose” or combine functionality across them. For example: You want to use .NET Remoting for it's rich extensibility model, but you want a ES-style transaction to flow. How do you do this? You want to use ASMX for its interoperability, but you want to provide direct reliable messaging guarantees. How is this accomplished? Today, scenarios like these that involve the combination of functionality across these technologies are more of a challenge than it should be. They often involve hundreds and sometimes thousands of lines of code to accomplish. Transition to next slide: With Indigo, the challenges of silo programming models becomes a thing of the past… © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

26 Location transparency
2018年12月2日6时5分 Indigo统一的编程模型 ASMX .NET Remoting Interop with other platforms Extensibility Location transparency Speaker Notes Indigo provides you with a unified programming model that brings together the best aspects of existing Microsoft technologies. What this means is that, with Indigo, you will no longer need to wonder “which technology do I use (ASMX, Remoting, etc)” when building a connected system. All of the application-to-application and intra-application communication for your connected will be handled by Indigo. This unified programming model is exposed to you through the System.ServiceModel namespace. Since Indigo provides all of the features of these existing Microsoft technologies, Indigo supports all of the scenarios currently supported by these technologies. In addition, Indigo enables new scenarios that are currently not possible or very hard to implement with existing technologies because Indigo allows you to compose functionality across these existing technologies. For example, this means that you’ll be able to achieve secure, reliable, transacted Web services by combining/composing the functionality that previously existed in silos. On a related note, we’re also doing a lot of work to preserve your existing investments in ASMX, ES, and other existing technologies shown on this slide. We do this through a number of mechanisms including the ability to communicate between Indigo services and existing ES-based applications for example. We’ll talk about this more later in the presentation. Transition to next slide: …but how do we accomplish the union of these various technologies? The secret is in architecture… Attribute- Based Programming Message- Oriented Programming WS-* Protocol Support Enterprise Services System.Messaging WSE © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

27 集成技术的未来之路 Basic WS-I 1.0 support Based on the ASP.NET Stack
2018年12月2日6时5分 集成技术的未来之路 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 (Need to add speaker notes) BizTalk Server built natively on Indigo foundation Service Broker uses Indigo transports for WS-* interoperability © 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.

28 您的反馈对我们很重要! 非常感谢您参加今天的交流 2018年12月2日6时5分
© 2005 Microsoft Corporation. All rights reserved. This presentation is for informational purposes only. Microsoft makes no warranties, express or implied, in this summary.