SOA,SOAP,RPC,以及 RPC协议与 REST 协议之间的关系(搜狗)

1. web service顾名思义这是一种提供service的形式，并且只能经过http（web）来提供service(web service三要素：SOAP、WSDL(WebServicesDescriptionLanguage)、UDDI(UniversalDescriptionDiscovery andIntegration))

SOA也就是面向服务的架构，那么这个架构如何提供服务，他不是web service,但Web Service是目前最适合实现SOA的技术,Web Service.目前有三种主流的Web服务实现方式：

　　REST：Representational State transfer 表征状态转变 (基于HTTP协议）面向资源的；
　　SOAP：简单对象访问协议(基于任何传输协议，TCP,HTTP,SMTP,MSMQ)
　　XML-RPC：远程过程调用协议 （已经慢慢被SOAP取代）RPC(跨越了传输层和应用层，基于HTTP和TCP)

三种方案的简单比较 

效率和易用性上：REST更胜一筹（REST效率更高的缘由在于，仅仅是建议的Http协议之上的一种协议。而SOAP则须要对数据、xml封装信息头，解封装等）

安全性上：SOAP安全性高于REST，由于REST更关注的是效率和性能问题

分布式能力：REST更适合在分布式环境中使用、由于REST是基于原生Http协议的，而http协议是无状态的。大型分布式环境都可以对无状态支持良好，无状态加强了整个系统的扩展性。这也是为何愈来愈多的云计算，分布式项目选择REST。  

整体上，由于REST模式的Web服务与复杂的SOAP和XML-RPC对比来说明显的更加简洁，愈来愈多的web服务开始采用REST风格设计和实现。例如，Amazon.com提供接近REST风格的Web服务进行图书查找；雅虎提供的Web服务也是REST风格的。REST对于资源型服务接口来讲很合适，同时特别适合对于效率要求很高，可是对于安全要求不高的场景。而SOAP的成熟性能够给须要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。因此我以为纯粹说什么设计模式将会占据主导地位没有什么意义，关键仍是看应用场景，正是那句老话：适合的才是最好的 

一、SOA

SOA（面向服务的软件架构、Service Oriented Architecture），是一种软件设计模式，主要应用于不一样应用组件之间经过某种协议来互操做。例如典型的  通讯网络协议。所以SOA是独立于任何厂商、产品、技术的。 

SOA有两个层面的定义： 

• 从应用的角度定义：SOA是一种应用框架，它着眼于平常的业务应用，并将他们划分为单独的业务功能和流程，及所谓的服务。
• 从软件的基本原理定义：SOA是一个组件模型，它将应用程序的不一样功能单元(服务)经过这些服务之间定义良好的接口和契约联系起来。 

SOA对于实现企业资源共享，打破 “信息孤岛” 的步骤以下：

1. 把引用和资源转换为对象；
2. 把这些服务编程标准的服务，造成资源的共享； 

基于SOA的解决方案，SOA架构可分为五层水平：

• 用户界面层 ---- 这些GUI的最终用户或应用程序访问的应用程序/服务接口；
• 业务流程层 ---- 在应用方面的业务用例服务；
  
• 服务层 ---- 服务合并在一块儿，提供统一的实时服务；
• 服务组件层 ---- 用来建造服务的组件，如功能库、技术库、技术接口等；
• 操做系统 ---- 这层包含数据模型，企业数据仓库，技术平台等；

由于SOA不依赖于任何技术，所以SOAP、RPC、REST是对SOA的不一样实现。

二、SOAP 

简单对象访问协议是交换数据的一种协议规范，

1. SOAP,简单对象访问协议，是一种轻量的、简单的、基于XML（标准通用标记语言下的一个子集）的协议，它被设计成在WEB上交换结构化的和固化的信息。可在任何传输协议（诸如 TCP、HTTP、SMTP，甚至是 MSMQ）上使用

扩展：SOAP普遍使用的是基于HTTP和xml协议的实现（SOAP=RPC+HTTP+XML），也就是你们常提的Web Service使用的通讯协议。一个SOAP方法能够简单地看做遵循SOAP编码规则的HTTP请求和响应。

比较：XML－RPC是启动web服务最容易的方法，在不少方面比SOAP更简单易用，但不一样于SOAP的是，XML－RPC没有相应的服务描述语法，这妨碍了XML－RPC服务的自动调用。

是一种标准化的通信规范，主要用于Web服务（web service）中。用一个简单的例子来讲明 SOAP 使用过程，一个 SOAP 消息能够发送到一个具备 Web Service 功能的 Web 站点，例如，一个含有房价信息的数据库，消息的参数中标明这是一个查询消息，此站点将返回一个 XML 格式的信息，其中包含了查询结果（价格，位置，特色，或者其余信息）。因为数据是用一种标准化的可分析的结构来传递的，因此能够直接被第三方站点所利用。

XML-RPC：一个远程过程调用（remote procedure call，RPC)的分布式计算协议，经过XML将调用函数封装，并使用HTTP协议做为传送机制。

 在某种传输协议（TCP\HTTP等)上携带信息数据，经过网络从远程计算机程序上请求服务

后来在新的功能不断被引入下，这个标准慢慢演变成为今日的SOAP协定。XML-RPC协定是已登记的专利项目。XML-RPC透过向装置了这个协定的服务器发出HTTP请求。发出请求的用户端通常都是须要向远端系统要求呼叫的软件。 

三、REST

表征状态转移（Representional State Transfer）。采用Web 服务使用标准的 HTTP 方法 (GET/PUT/POST/DELETE) 将全部 Web 系统的服务抽象为资源，REST 不是一种协议,它是一种架构, 一种 Web Service 可以若是知足 REST 的几个条件, 一般就称这个系统是 Restful 的.，REST从资源的角度来观察整个网络，分布在各处的资源由URI肯定，而客户端的应用经过URI来获取资源的表征。Http协议所抽象的get,post,put,delete就比如数据库中最基本的增删改查，而互联网上的各类资源就比如数据库中的记录（可能这么比喻不是很好），对于各类资源的操做最后老是能抽象成为这四种基本操做，在定义了定位资源的规则之后，对于资源的操做经过标准的Http协议就能够实现，开发者也会受益于这种轻量级的协议。REST是一种软件架构风格而非协议也非规范，是一种针对网络应用的开发方式，能够下降开发的复杂性，提升系统的可伸缩性。     

这里提到的条件包括:

C/S结构 (这是Internet服务的一个基本特征)
无状态 (很熟悉吧,呵呵)
能够cache (想起了浏览器?)
分层系统 (想起了无数的架构?)
统一的接口 (若是这是可能的,程序员有福了, :D)
code on demand(可选, 实际上是一种扩展性的要求)
HTTP是WWW的最核心的协议, 它将简单的分布于世界各个角落的资源都统一块儿来, 统一的地址, 简单的方法, 和必定数量的表达方式.(你可能对这三点描述很模糊,请go ahead).

REST 的三个要素是 惟一的资源标识, 简单的方法 (此处的方法是个抽象的概念), 必定的表达方式.

REST 是以 资源 为中心, 名词即资源的地址, 动词即施加于名词上的一些有限操做, 表达是对各类资源形态的抽象.

以HTTP为例, 名词即为URI(统一资源标识), 动词包括POST, GET, PUT, DELETE等(还有其它不经常使用的2个,因此 整个动词集合是有限的), 资源的形态(如text, html, image, pdf等)

其宗旨是从资源的角度来观察整个网络，分布在各处的资源由URI肯定，而客户端的应用经过URI来获取资源的表征。得到这些表征导致这些应用程序转变了其状态。随着不断获取资源的表征，客户端应用不断地在转变着其状态。

举个栗子：

Marcus是一个农民，他有4头猪，12只鸡和3头奶牛。他如今模拟一个REST API，而我是客户端。若是我想用REST来请求当前的农场状态，我仅会问：“State？”Marcus会回答：“4头猪、12只鸡、3头奶牛”。

这是REST最简单的一个例子。Marcus使用表征来传输农场状态。表征的句子很简单：“4头猪、12只鸡、3头奶牛”。
再往下看，看我如何让Marcus用REST方式添加2头奶牛？
按照常理，能够会这样说：Marcus，请在农场你再添加2头奶牛。难道这就是REST方式吗？难道就是经过这样的表征来传输状态的吗？不是的！这是一个远程过程调用，过程是给农场添加2头奶牛。
Marcus很愤怒地响应到：“400，Bad Request”，你究竟是什么意思？
因此，让咱们从新来一次。咱们怎样作到REST方式呢？该怎样从新表征呢？它应该是4头猪、12只鸡、3头奶牛。好，让咱们再次从新表征……
我：“Marcus，……4头猪、12只鸡、5头奶牛！”
Marcus：“好的”。
我：“Marcus，如今是什么状态？”
Marcus：“4头猪、12只鸡、5头奶牛”。
我：“好！”
看到了吗？就这样简单。

为何RPC也不够好？
从逻辑角度来看，为何会更加青睐REST而不是RPC（Remote Procedure Call，远程过程调用 ），由于它极大的下降了咱们沟通的复杂度，经过把表征做为惟一的沟通的方式。无需去讨论过程（添加一头牛？增长一种动物类型？给鸡的数量翻倍仍是卖掉全部猪？）咱们只需讨论表征，而且使用这个表征来达到咱们想要的目标，很简单，不是吗？我不但愿和Marcus的沟通失败，由于咱们彼此的理解过程会不同，因此只须要知道最后的状态就行。但这仅仅是建立RPC会产生许多问题之一。若是你使用RPC，你须要设计一些程序嵌入到某种结构中。这种结构须要存储参数、错误的代码、返回值等。

四、RPC 

RPC（Remote Procedure Call Protocol）——远程过程调用协议，它是一种经过网络从远程计算机程序上请求服务，而不须要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通讯程序之间携带信息数据。在OSI网络通讯模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。
RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，而后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器得到进程参数，计算结果，发送答复信息，而后等待下一个调用信息，最后，客户端调用进程接收答复信息，得到进程结果，而后调用执行继续进行。

RPC工做原理：

运行时,一次客户机对服务器的RPC调用,其内部操做大体有以下十步：

1.调用客户端句柄；执行传送参数

2.调用本地系统 内核发送网络消息

3. 消息传送到远程 主机

4.服务器句柄获得消息并取得参数

5.执行远程过程

6.执行的过程将结果返回服务器句柄

7.服务器句柄返回结果，调用远程系统 内核

8.消息传回 本地主机

9.客户句柄由内核接收消息

10.客户接收句柄返回的数据

注意：

dubbo就是一种RPC框架。他的通信协议是RPC协议，

它是由alibaba得工程师为java开发的一个RPC，有很高的性能以及简单的使用方法：

一、被远程调用的接口，须要在zookeeper中进行注册；

二、须要远程调用的服务在zookeeper中声明本身须要的接口；

三、zookeeper将已经注册的接口通知给须要的服务；

Spring Cloud也是一种RPC框架，他的通信协议是http restful 协议；REST协议，它基于HTTP的协议，是一种明确构建在客户端/服务端体系结构上的一种风格 

HTTP Restful自己轻量，易用，适用性强，能够很容易的跨语言，跨平台，或者与已有系统交互，毕竟HTTP如今没有不支持的。
Spring能够整合其余的RPC方案，好比各类MQ，Hessian，Thrift，均可以。 

看看Spring Cloud和Dubbo都提供了哪些支持。

	Dubbo	Spring Cloud
服务注册中心	Zookeeper	Spring Cloud Netflix Eureka
服务调用方式	RPC	REST API
服务网关	无	Spring Cloud Netflix Zuul
断路器	不完善	Spring Cloud Netflix Hystrix
分布式配置	无	Spring Cloud Config
服务跟踪	无	Spring Cloud Sleuth
消息总线	无	Spring Cloud Bus
数据流	无	Spring Cloud Stream
批量任务	无	Spring Cloud Task
……	……	……

 

五、RPC 与 REST 的区别

Rest基于http做为应用协议，不一样语言之间调用比较方便。典型表明就是spring cloud框架
而RPC是基于TCP和HTTP协议的，是把http做为一种传输协议，自己还会封装一层RPC框架的应用层协议，不一样语言之间调用须要依赖RPC协议，典型表明就是Dubbo;

RPC是以动词为中心的, REST是以名词为中心的, 此处的 动词指的是一些方法, 名词是指资源.

你会发现,以动词为中心,意味着,当你要须要加入新功能时,你必需要添加更多的动词, 这时候服务器端须要实现 相应的动词(方法), 客户端须要知道这个新的动词并进行调用.

而以名词为中心, 假使我请求的是 hostname/friends/, 不管这个URI对应的服务怎么变化,客户端是无需 关注和更新的,而这种变化对客户端也是透明的.

至于其它的区别,如对实现语言的依赖, 耦合性等,这些都是上面提到的这个根本区别所衍生的.

 当你天天使用HTTP冲浪时,你都在使用 REST 与远程的服务器进行亲密接触. 当你使用Gtalk和同事朋友沟通时,你则是在享受着 RPC 的便利. 

另外，因为Dubbo是基础框架，其实现的内容对于咱们实施微服务架构是否合理，也须要咱们根据自身需求去考虑是否要修改，好比Dubbo的服务调用是经过RPC实现的，可是若是仔细拜读过Martin Fowler的microservices一文，其定义的服务间通讯是HTTP协议的REST API。那么这两种有何区别呢？

先来讲说，使用Dubbo的RPC来实现服务间调用的一些痛点：

服务提供方与调用方接口依赖方式太强：咱们为每一个微服务定义了各自的service抽象接口，并经过持续集成发布到私有仓库中，调用方应用对微服务提供的抽象接口存在强依赖关系，所以不论开发、测试、集成环境都须要严格的管理版本依赖，才不会出现服务方与调用方的不一致致使应用没法编译成功等一系列问题，以及这也会直接影响本地开发的环境要求，每每一个依赖不少服务的上层应用，天天都要更新不少代码并install以后才能进行后续的开发。若没有严格的版本管理制度或开发一些自动化工具，这样的依赖关系会成为开发团队的一大噩梦。而REST接口相比RPC更为轻量化，服务提供方和调用方的依赖只是依靠一纸契约，不存在代码级别的强依赖，固然REST接口也有痛点，由于接口定义太轻，很容易致使定义文档与实际实现不一致致使服务集成时的问题，可是该问题很好解决，只须要经过每一个服务整合swagger，让每一个服务的代码与文档一体化，就能解决。因此在分布式环境下，REST方式的服务依赖要比RPC方式的依赖更为灵活。

服务对平台敏感，难以简单复用：一般咱们在提供对外服务时，都会以REST的方式提供出去，这样能够实现跨平台的特色，任何一个语言的调用方均可以根据接口定义来实现。那么在Dubbo中咱们要提供REST接口时，不得不实现一层代理，用来将RPC接口转换成REST接口进行对外发布。若咱们每一个服务自己就以REST接口方式存在，当要对外提供服务时，主要在API网关中配置映射关系和权限控制就可实现服务的复用了。 

六、REST 和SOAP协议的区别：

REST基于HTTP协议，

SOAP基于任何传输协议:诸如 TCP、HTTP、SMTP，甚至是 MSMQ等

国外不少大网站都发布了本身的开发API，不少都提供了SOAP和REST两种Web Service，根据调查部分网站的REST风格的使用状况要高于SOAP。可是因为REST只是一种基于Http协议实现资源操做的思想，所以各个网站的REST实现都自有一套，在后面会讲诉各个大网站的REST API的风格。也正是由于这种各自实现的状况，在性能和可用性上会大大高于SOAP发布的web service，但统一通用方面远远不及SOAP。因为这些大网站的SP每每专一于此网站的API开发，所以通用性要求不高。 

 

SOAP协议对于消息体和消息头都有定义，同时消息头的可扩展性为各类互联网的标准提供了扩展的基础，WS-*系列就是较为成功的规范。可是也因为SOAP因为各类需求不断扩充其自己协议的内容，致使在SOAP处理方面的性能有所降低。同时在易用性方面以及学习成本上也有所增长。 
       REST被人们的重视，其实很大一方面也是由于其高效以及简洁易用的特性。这种高效一方面源于其面向资源接口设计以及操做抽象简化了开发者的不良设计，同时也最大限度的利用了Http最初的应用协议设计理念。同时，在我看来REST还有一个很吸引开发者的就是可以很好的融合当前Web2.0的不少前端技术来提升开发效率。例如不少大型网站开放的REST风格的API都会有多种返回形式，除了传统的xml做为数据承载，还有（JSON,RSS,ATOM）等形式，这对不少网站前端开发人员来讲就可以很好的mashup各类资源信息。 
       所以在效率和易用性上来讲，REST更胜一筹。 

　　REST对于资源型服务接口来讲很合适，同时特别适合对于效率要求很高，可是对于安全要求不高的场景。而SOAP的成熟性能够给须要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。因此我以为纯粹说什么设计模式将会占据主导地位没有什么意义，关键仍是看应用场景。  

七、RPC与SOA的区别

总的来说：RPC是一种进程远程调用的方式，更强调的是异构平台之间进程通讯的机制。SOA是一种产品架构的理念，以服务为中心，松耦合，经过定义严谨明确的接口进行通讯。有比较完善的服务管理机制。二者并非一个层面上的概念，能够说RPC是SOA架构的一种实现。

 场景及选择：

好比公司要作一个社交游戏的项目, 让你去负责整个系统的后端架构和通讯等, 咱们就有必要去仔细地学习和研究下facebook/人人网/新浪等社交网站（游戏）开放的API, 咱们知道facebook使用的是REST 的架构, 因此即便facebook自己是PHP开发的,这也不妨碍咱们使用python来开发, 还有更多的PHP, Java, .net, Perl等客户端API封装.这样就能灵活的适配多端的服务了。

因而在想,假若facebook的架构使用的不是 REST ,会有这样的灵活性吗? 若是使用的是 RPC 可能不会有这么便利。

另外,由于咱们的前端使用的是flash, 与后端的python通讯采用的是 Django+Flex+AMF , 若是你了解 flash,你会知道AMF是一种二进制的flash数据交互协议, 而 它是基于RPC !

因此，咱们须要根据当前需求的状况来选择REST或则RPC 

 

参考：SOA、SOAP、RPC、REST、DUBBO的区别与联系

参考：RPC协议学习（三）与其余区别

参考：谈谈本身对REST、SOA、SOAP、RPC、ICE、ESB、BPM知识汇总及理解

参考：你想要的都在这之RPC/web service/REST/SOA区别联系与对比

参考：Webservice RPC风格 SOAP,REST风格 各之间的对比