森.林木

架构设计:分布式应用架构风格

说明:本文内容大部分整理自网络

分布式对象( Distributed Objects ,简称 DO )

这里说的对象不仅仅是数据,还包括操作,整体上是面向对象的概念。本质就是代理对象机制。

CORBA

简介

CORBA is the acronym for Common Object Request Broker Architecture™, OMG®’s open, vendor-independent architecture and infrastructure that computer applications use to work together over networks. Using the standard protocol IIOP, a CORBA-based program from any vendor, on almost any computer, operating system, programming language, and network, can interoperate with a CORBA-based program from the same or another vendor, on almost any other computer, operating system, programming language, and network.

enter description here

Figure shows how everything fits together, at least within a single process: You compile your IDL into client stubs and object skeletons, and write your object (shown on the right) and a client for it (on the left). Stubs and skeletons serve as proxies for clients and servers, respectively. Because IDL defines interfaces so strictly, the stub on the client side has no trouble meshing perfectly with the skeleton on the server side, even if the two are compiled into different programming languages, or even running on different ORBs from different vendors.

enter description here

Figure diagrams a remote invocation. In order to invoke the remote object instance, the client first obtains its object reference. (There are many ways to do this, but we won’t detail any of them here. Easy ways include the Naming Service and the Trader Service.) To make the remote invocation, the client uses the same code that it used in the local invocation we just described, substituting the object reference for the remote instance. When the ORB examines the object reference and discovers that the target object is remote, it routes the invocation out over the network to the remote object’s ORB. (Again we point out: for load balanced servers, this is an oversimplification.)

http://www.corba.org/faq.htm
http://blog.csdn.net/drykilllogic/article/details/25971915

特点

  • 跨平台,通过IDL向具体语言映射实现
  • 跨语言,通过IDL向具体语言映射实现
  • 适合复杂异构系统

COM & DCOM & MTS & COM+

简介

enter description here

COM :着眼点于同计算机上不同应用程序之间的通讯需求

DCOM:着眼于在COM基础上,实现不同计算机上不同应用程序之间的通讯需求。

MTS:的COM和DCOM基础上,进一步为开发、构建、部署、管理等工具。Microsoft Transaction Server is a component-based transaction processing system that allows developers to build, deploy, and administer robust network applications. In being component based, Microsoft Transaction Server (MTS) uses standard COM components to encapsulate business logic that forms applications. MTS provides a development framework so that components can be easily created that can participate in transactions. MTS also provides the environment of execution for these objects, along with a set of administrator tools to manage the deployment of the objects that make up these applications.

COM+:一种新的设计概念。把COM组件提升到应用层,把底层细节留给操作系统,使COM+与操作系统的结合更加紧密。COM+的底层结构仍然以COM为基础,但在应用方式上则更多地继承了MTS(Microsoft Transaction Server)的处理机制,包括MTS的对象环境、安全模型、配置管理等。COM+把COM、DCOM和MTS三者有机地统一起来,同时也新增了一些服务,如负载平衡、内存数据库、事件模型、队列服务等,形成一个概念新、功能强的组件体系结构,使得COM+形成真正适合于企业应用的组件技术。

http://blog.sina.com.cn/s/blog_59c804b60101all2.html
http://www.cnblogs.com/mytechblog/articles/1867278.html

特点

  • Windows平台专用,依赖注册表
  • 跨语言

.NET Remoting

简介

.NET Remoting技术是通过通道来实现两个应用程序之间对象的通信的。首先,客户端通过Remoting技术,访问通道来获得服务器端对象,再通过代理解析为客户端对象,也称作透明代理,此时获得客户端对象只是服务器对象的一个引用。这既保证了客户端和服务端有关对象的松散耦合,同时优化了通信的性能。在这个过程中,当客户端通过透明代理来调用远程对象的方法时,此时会将调用封装到一个消息对象中,该消息对象包括远程对象信息,被调用的方法名和参数,然后透明代理会将调用委托给真实代理(RealProxy对象)的Invoke方法来生成一个IMethodCallMessage,接着通过序列化把这个消息对象序列化成数据流发送到通道,通道会把数据流传送到服务器端。当服务器接收到经过格式化的数据之后,首先从中通过反序列化来还原消息对象,之后在服务器端来激活远程对象,并调用对应的方法,而方法的返回结果过程则是按照之前的方法反向重复一遍,具体的实现原理图如下所示:

enter description here

.NET Remoting中涉及的几个重要概念:

1、远程对象:是运行在服务器端的对象,客户端不能直接调用,由于.NET Remoting传递的对象是以引用的方式,因此所传递的远程对象必须继承MarshalByRefObject类,这个类可以使远程对象在.NET Remoting应用通信中使用,支持对象的跨域边界访问。

2、远程对象的激活方式:在访问服务器端的一个对象实例之前,必须通过一个名为Activation的进程创建它并进行初始化。这种客户端通过通道来创建远程对象的方式称为对象的激活。在.NET Remoting中,远程对象的激活分为两大类:服务器端激活和客户端激活。
服务器端激活,又叫做WellKnow(知名对象)激活模式,为什么称为知名对象激活模式呢?是因为服务应用程序在激活对象实例之前会在一个众所周知的统一资源标示符(URI)上发布这个类型,然后该服务器进行会为此类型配置一个WellKnow对象,并根据指定的端口或地址来发布对象。.NET Remoting把服务器端激活又分为SingleTon模式和SingleCall模式两种。
  SingleTon模式:此为有状态模式。如果设置为SingleTon激活模式,则.NET Remoting将为所有客户端建立同一个对象实例。当对象处于活动状态时,SingleTon实例会处理所有后来的客户端访问请求,而不管它们是同一个客户端,还是其他客户端。SingleTon实例将在方法调用中一直维护其状态,类似static成员的概念

  SingleCall模式:是一种无状态模式。一旦设置为SingleCall模式,则当客户端调用远程对象的方法时,Remoting会为每一个客户端建立一个远程对象实例,对象实例的销毁则是由GC自动管理。类似实例成员的概念。

客户端激活:与Wellknow模式不同,。NET Remoting在激活每个对象实例的时候,会给每个客户端激活的类型指派一个URI。客户端激活模式一旦获得客户端的请求,将为每一个客户端都建立一个实例引用。SingleCall模式与客户端激活模式的区别有:首先,对象实例创建的时间不同。客户端激活方式是客户一旦发出调用请求就实例化,而SingleCall则要等到调用对象方法时再创建。其次,SingleCall模式激活的对象是无状态的,对象声明周期由GC管理,而客户端激活的对象是有状态的,其生命周期可自定义。第三,两种激活模式在服务器端和客户端实现的方法不一样,尤其是在客户端,SingleCall模式由GetObject()来激活,它调用对象默认的构造函数,而客户端激活模式,则通过CreateInstance()来激活,它可以传递参数,所以可以调用自定义的构造函数来创建实例。

3、 通道:在.NET Remoting中时通过通道来实现两个应用程序域之间对象的通信。.NET Remoting中包括4中通道类型:

TcpChannel:Tcp通道使用Tcp协议来跨越.Net Remoting边界来传输序列化的消息流,TcpChannel默认使用二进制格式序列化消息对象,因此具有更高的传输性能,但不提供任何内置的安全功能。
HttpChannel:Http通道使用Http协议在客户端和服务器之间发生消息,使其在Internet上穿越防火墙来传输序列化的消息流(这里准确讲不能说穿越,主要是因为防火墙都开放了80端口,所以使用Http协议可以穿过防火墙进行数据的传输,如果防火墙限制了80端口,Http协议也照样不能穿越防火墙)。默认情况下,HttpChannel使用Soap格式序列化消息对象,因此它具有更好的互操作性,并且可以使用Http协议中的加密机制来对消息进行加密来保证安全性。因此,通常在局域网内,我们更多地使用TcpChannel,如果要穿越防火墙,则使用HttpChannel。
IpcChannel:进程间通信,只使用同一个系统进程之间的通信,不需要主机名和端口号。而使用Http通道和Tcp通道都要指定主机名和端口号。
自定义通道:自定义的传输通道可以使用任何基本的传输协议来进行通信,如UDP协议、SMTP协议等。

http://www.cnblogs.com/xia520pi/archive/2011/11/02/2233371.html
http://www.cnblogs.com/zhili/p/NETRemoting.html

特点

enter description here

Web Service

简介

Web Service也叫XML Web Service WebService是一种可以接收从Internet或者Intranet上的其它系统中传递过来的请求,轻量级的独立的通讯技术。是:通过SOAP在Web上提供的软件服务,使用WSDL文件进行说明,并通过UDDI进行注册。

XML:(Extensible Markup Language)扩展型可标记语言。面向短期的临时数据处理、面向万维网络,是Soap的基础。

Soap:(Simple Object Access Protocol)简单对象存取协议。是XML Web Service 的通信协议。当用户通过UDDI找到你的WSDL描述文档后,他通过可以SOAP调用你建立的Web服务中的一个或多个操作。SOAP是XML文档形式的调用方法的规范,它可以支持不同的底层接口,像HTTP(S)或者SMTP。

WSDL:(Web Services Description Language) WSDL 文件是一个 XML 文档,用于说明一组 SOAP 消息以及如何交换这些消息。大多数情况下由软件自动生成和使用。

UDDI (Universal Description, Discovery, and Integration) 是一个主要针对Web服务供应商和使用者的新项目。在用户能够调用Web服务之前,必须确定这个服务内包含哪些商务方法,找到被调用的接口定义,还要在服务端来编制软件,UDDI是一种根据描述文档来引导系统查找相应服务的机制。UDDI利用SOAP消息机制(标准的XML/HTTP)来发布,编辑,浏览以及查找注册信息。它采用XML格式来封装各种不同类型的数据,并且发送到注册中心或者由注册中心来返回需要的数据。

调用原理

enter description here

实现一个完整的Web服务包括以下步骤:

◆ Web服务提供者设计实现Web服务,并将调试正确后的Web服务通过Web服务中介者发布,并在UDDI注册中心注册; (发布)

◆ Web服务请求者向Web服务中介者请求特定的服务,中介者根据请求查询UDDI注册中心,为请求者寻找满足请求的服务; (发现)

◆ Web服务中介者向Web服务请求者返回满足条件的Web服务描述信息,该描述信息用WSDL写成,各种支持Web服务的机器都能阅读;(发现)

◆ 利用从Web服务中介者返回的描述信息生成相应的SOAP消息,发送给Web服务提供者,以实现Web服务的调用;(绑定)

◆ Web服务提供者按SOAP消息执行相应的Web服务,并将服务结果返回给Web服务请求者。(绑定)

http://blog.csdn.net/yangwenxue_admin/article/details/51059125

特点

  • 标准协议,而不仅仅是技术方案
  • 跨语言
  • 跨平台
  • 相对简单
  • 基于XML,Soap
  • 性能不佳

WCF

简介

Windows Communication Foundation(WCF)是由微软开发的一系列支持数据通信的应用程序框架,可以翻译为Windows 通讯开发平台。

整合了原有的windows通讯的 .net Remoting,WebService,Socket的机制,并融合有Http和Ftp的相关技术。WCF是对这些技术的统一

enter description here

根据MSDN上的定义:WCF为.NetFramework 提供了一个基础,使其能够编写代码,以在组件、应用程序、系统之间进行通信。WCF的设计遵循的是面向服务的原则。服务是指可以通过消息与之进行交互的一段代码。服务是被动的。它们等待传入消息之后才开始工作。客户端是发起者,客户端将消息发送给服务来请求工作。是Windows平台上开发分布式应用最佳的实践方式。

enter description here

http://www.cnblogs.com/jiekzou/p/5325310.html

特点

  • 统一
  • 集成
  • 互操作
  • Windows平台首先方案

RMI

简介

 远程方法调用(RMI)顾名思义是一台机器上的程序调用另一台机器上的方法。这样可以大致知道RMI是用来干什么的,但是这种理解还不太确切。RMI是Java支撑分布式系统的基石,例如著名的EJB组件。RMI是远程过程调用(RPC)的一种面向对象实现,RMI底层是通过socket通信和对象序列化技术来实现的。这里引用Wikipedia对RMI的介绍:

The Java Remote Method Invocation (Java RMI) is a Java API that performs remote method invocation, the object-oriented equivalent of remote procedure calls (RPC), with support for direct transfer of serialized Java classes and distributed garbage collection.

RMI 构建三个抽象层, 高层覆盖低层, 分别负责Socket通信, 参数和结果的序列化和反序列化等工作。存根( Stub) 和骨架( Skeleton) 合在一起形成了 RMI 构架协议。下面的引用层被用来寻找各自的通信伙伴, 在这一层还有一个提供名字服务的部分, 称为注册表( registry) 。最下一层是传输层, 是依赖于 TCP/IP 协议实现客户机与服务器的互联。

  enter description here

http://www.cnblogs.com/wxisme/p/5296441.html
http://www.cnblogs.com/yeahwell/p/4684492.html

特点

  • Java平台专用
  • 可传输数据流(文件)
  • 性能好

EJB

J2EE的体系结构

enter description here

其中EJB属于J2EE体系结构中的业务逻辑部分

EJB构成

enter description here

EJB容器中有三种类也称为组件,分别是

Session bean(逻辑)
EntityBean(数据)
messageDrivenbean(消息)

上图中可以看到

1 组件是在容器中的。容器提供了组件的环境并对其进行管理。
2 调用组件的被称为ejb客户端。客户端可以运行在web容器中。如jsp,servlet,jndi,web service等

实现逻辑

实现逻辑组件中有各种抽象的方式。这样通过客户端的调用实现了业务的封装

实现分布式

首先要认识到RMI技术(远程调用),EJB的基础是RMI,通过RMI,J2EE将EJB组件创建为远程对象,EJB虽然用到了RMI,但是只需要定义远程接口无需实现,这样就将RMI技术细节屏蔽了。
这种将需要特定执行的类,放在Ejb中并打包发送到服务器上,,客户端通过RMI技术到服务器上进行调用,这样就实现了分布式调用。

所谓的服务器群

既然已经知道了,RMI是将各种任务与功能的类放到不同的服务器上,然后通过各个服务器间建立的调用规则实现分布式的运算,也就明白EJB所谓的”服务群集”的概念。就是将原来在一个计算机上运算的几个类,分别放到其他计算机上去运行,以便分担运行这几个类所需要占用的CPU和内存资源。同时,也可以将不同的软件功能模块放到不同的服务器上,当需要修改某些功能的时候直接修改这些服务器上的类就行了,修改以后所有客户端的软件都被修改了

一个简单的分布式群图

enter description here

小结:

EJB实现原理:就是把原来放到客户端实现的代码放到服务器端,并依靠RMI进行通信。
服务器集群:就是通过RMI的通信,连接不同功能模块的服务器,以实现一个完整的功能。
EJB规范定义了EJB组件在何时如何与它们的容器进行交互作用。容器负责提供公用的服务,例如目录服务、事务管理、安全性、资源缓冲池以及容错性。但这里值得注意的是,EJB并不是实现J2EE的唯一途径。

http://blog.csdn.net/han_yankun2009/article/details/22784559

特点

  • 一套解决方案
  • 以RMI为基础
  • 分布式

Thrift

简介

Thrift是一款由Fackbook开发的可伸缩、跨语言的服务开发框架,该框架已经开源并且加入的Apache项目。Thrift主要功能是:通过自定义的Interface Definition Language(IDL),可以创建基于RPC的客户端和服务端的服务代码。数据和服务代码的生成是通过Thrift内置的代码生成器来实现的。Thrift 的跨语言性体现在,它可以生成C++, Java, Python, PHP, Ruby, Erlang, Perl, Haskell, C#, Cocoa, JavaScript, Node.js, Smalltalk, OCaml , Delphi等语言的代码,且它们之间可以进行透明的通信。

hrift 包含一个完整的堆栈结构用于构建客户端和服务器端。下图描绘了 Thrift 的整体架构。

enter description here

如图所示,图中黄色部分是用户实现的业务逻辑,褐色部分是根据 Thrift 定义的服务接口描述文件生成的客户端和服务器端代码框架,红色部分是根据 Thrift 文件生成代码实现数据的读写操作。红色部分以下是 Thrift 的传输体系、协议以及底层 I/O 通信,使用 Thrift 可以很方便的定义一个服务并且选择不同的传输协议和传输层而不用重新生成代码。

Thrift 服务器包含用于绑定协议和传输层的基础架构,它提供阻塞、非阻塞、单线程和多线程的模式运行在服务器上,但是由于C#语言的限制,C#实现的服务端没有非阻塞模式,可以配合winform/webform调用。

服务端和客户端具体的调用流程如下:

enter description here

该图所示是HelloServiceServer启动的过程以及服务被客户端调用时,服务器的响应过程。从图中我们可以看到,程序调用了TThreadPoolServer的server方法后,server进入阻塞监听状态,其阻塞在TServerSocket的accept方法上。当接收到来自客户端的消息后,服务器发起一个新线程处理这个消息请求,原线程再次进入阻塞状态。在新线程中,服务器通过TBinaryProtocol协议读取消息内容,调用HelloServiceImpl的helloVoid方法,并将结果写入helloVoid_result中传回客户端。

enter description here

该图所示是HelloServiceClient调用服务的过程以及接收到服务器端的返回值后处理结果的过程。从图中我们可以看到,程序调用了Hello.Client的helloVoid方法,在helloVoid方法中,通过send_helloVoid方法发送对服务的调用请求,通过recv_helloVoid方法接收服务处理请求后返回的结果。

特点

  • 跨平台
  • 跨语言
  • 性能
  • 静态的,不能动态部署

远程过程调用( Remote Procedure Call ,简称 RPC ):

本质是基于通用协议的数据交换,非代理。

SOAP

简介

简单对象访问协议(SOAP)是一种轻量的、简单的、基于XML的协议,是交换数据的一种协议规范,是一种轻量的、简单的、基于XML(标准通用标记语言下的一个子集)的协议,它被设计成在WEB上交换结构化的和固化的信息。

enter description here

特点

  • 跨平台,跨语言
  • 基于XML
  • Web Service的基础协议

XML-RPC

简介

XML-RPC的全称是XML Remote Procedure Call,即XML(标准通用标记语言下的一个子集)远程过程调用。它是一套允许运行在不同操作系统、不同环境的程序实现基于Internet过程调用的规范和一系列的实现。这种远程过程调用使用http作为传输协议,XML作为传送信息的编码格式。Xml-Rpc的定义尽可能的保持了简单,但同时能够传送、处理、返回复杂的数据结构。

特点

  • 跨平台,跨语言
  • 基于XML
  • Soap可以取代之

Hessian

简介

Hessian是一个轻量级的remotingonhttp工具,使用简单的方法提供了RMI的功能。相比Webservice,Hessian更简单、快捷。采用的是二进制RPC协议,因为采用的是二进制协议,所以它很适合发送二进制数据。

特点

  • 简单
  • 基于二进制

DWR

简介

和JavaBean有点类似,但是配合AJAX使用,直接在Javascript中调用远程Java对象。

DWR will generate the JavaScript to allow web browsers to securely call into Java code almost as if it was running locally. It can marshal virtually any data including collections, POJOs, XML and binary data like images and PDF files. All that is required is a security policy that defines what is allowed.

With Reverse Ajax, DWR allows Java code running on a server to use client side APIs to publish updates to arbitrary groups of browsers. This allows interaction 2 ways - browser calling server and server calling browser. DWR supports Comet, Polling and Piggyback (sending data in with normal requests) as ways to publish to browsers.

特点

  • 配合Ajax
  • Java平台专用

Dobbo

Dubbo |ˈdʌbəʊ| 是一个分布式服务框架,致力于提供高性能和透明化的RPC远程服务调用方案,以及SOA服务治理方案。 其核心部分包含:

远程通讯: 提供对多种基于长连接的NIO框架抽象封装,包括多种线程模型,序列化,以及“请求-响应”模式的信息交换方式。
集群容错: 提供基于接口方法的透明远程过程调用,包括多协议支持,以及软负载均衡,失败容错,地址路由,动态配置等集群支持
自动发现: 基于注册中心目录服务,使服务消费方能动态的查找服务提供方,使地址透明,使服务提供方可以平滑增加或减少机器。

Dubbo能做什么?

透明化的远程方法调用,就像调用本地方法一样调用远程方法,只需简单配置,没有任何API侵入。
软负载均衡及容错机制,可在内网替代F5等硬件负载均衡器,降低成本,减少单点。
服务自动注册与发现,不再需要写死服务提供方地址,注册中心基于接口名查询服务提供者的IP地址,并且能够平滑添加或删除服务提供者。

enter description here

节点角色说明:
Provider: 暴露服务的服务提供方
Consumer: 调用远程服务的服务消费方。
Registry: 服务注册与发现的注册中心。
Monitor: 统计服务的调用次调和调用时间的监控中心。
Container: 服务运行容器。

调用关系说明:
服务容器负责启动,加载,运行服务提供者。
服务提供者在启动时,向注册中心注册自己提供的服务。
服务消费者在启动时,向注册中心订阅自己所需的服务。
注册中心返回服务提供者地址列表给消费者,如果有变更,注册中心将基于长连接推送变更数据给消费者。
服务消费者,从提供者地址列表中,基于软负载均衡算法,选一台提供者进行调用,如果调用失败,再选另一台调用。
服务消费者和提供者,在内存中累计调用次数和调用时间,定时每分钟发送一次统计数据到监控中心。

enter description here

Deployer: 自动部署服务的本地代理。
Repository: 仓库用于存储服务应用发布包。
Scheduler: 调度中心基于访问压力自动增减服务提供者。
Admin: 统一管理控制台。

WebApi

Http

WebApi的本质就是面向数据的Http请求。可以使用一些框架,如MVC简化和统一API配置

Rest

Rest使用Http,只是在其基础上定义了一套风格