SOA,SOAP,RPC,以及 RPC协议与 REST 协议之间的关系(搜狗)
- 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的成熟性可以给需要提供给多开发语言的，对于安全性要求较高的接口设计带来便利。所以我觉得纯粹说什么设计模式将会占据主导地位没有什么意义，关键还是看应用场景，正是那句老话：适合的才是最好的
1、SOA
SOA（面向服务的软件架构、Service Oriented Architecture），是一种软件设计模式，主要应用于不同应用组件之间通过某种协议来互操作。例如典型的 通信网络协议。因此SOA是独立于任何厂商、产品、技术的。
SOA有两个层面的定义：
- 从应用的角度定义：SOA是一种应用框架，它着眼于日常的业务应用，并将他们划分为单独的业务功能和流程，及所谓的服务。
- 从软件的基本原理定义：SOA是一个组件模型，它将应用程序的不同功能单元(服务)通过这些服务之间定义良好的接口和契约联系起来。
- 把引用和资源转换为对象；
- 把这些服务编程标准的服务，形成资源的共享；
- 用户界面层 ---- 这些GUI的最终用户或应用程序访问的应用程序/服务接口；
- 业务流程层 ---- 在应用方面的业务用例服务；
- 服务层 ---- 服务合并在一起，提供统一的实时服务；
- 服务组件层 ---- 用来建造服务的组件，如功能库、技术库、技术接口等；
- 操作系统 ---- 这层包含数据模型，企业数据仓库，技术平台等；
2、SOAP
简单对象访问协议是交换数据的一种协议规范，
- 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请求。发出请求的用户端一般都是需要向远端系统要求呼叫的软件。
3、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，你需要设计一些程序嵌入到某种结构中。这种结构需要存储参数、错误的代码、返回值等。
4、RPC
RPC（Remote Procedure Call Protocol）——远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。
RPC采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务器端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息，然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。
RPC工作原理：
注意：
dubbo就是一种RPC框架。他的通讯协议是RPC协议，
它是由alibaba得工程师为java开发的一个RPC，有很高的性能以及简单的使用方法：
1、被远程调用的接口，需要在zookeeper中进行注册；
2、需要远程调用的服务在zookeeper中声明自己需要的接口；
3、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 |
| …… | …… | …… |
5、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网关中配置映射关系和权限控制就可实现服务的复用了。
6、REST 和SOAP协议的区别：
REST被人们的重视，其实很大一方面也是因为其高效以及简洁易用的特性。这种高效一方面源于其面向资源接口设计以及操作抽象简化了开发者的不良设计，同时也最大限度的利用了Http最初的应用协议设计理念。同时，在我看来REST还有一个很吸引开发者的就是能够很好的融合当前Web2.0的很多前端技术来提高开发效率。例如很多大型网站开放的REST风格的API都会有多种返回形式，除了传统的xml作为数据承载，还有（JSON,RSS,ATOM）等形式，这对很多网站前端开发人员来说就能够很好的mashup各种资源信息。
因此在效率和易用性上来说，REST更胜一筹。
7、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的区别与联系
参考：谈谈自己对REST、SOA、SOAP、RPC、ICE、ESB、BPM知识汇总及理解
本文来自博客园，作者：aspirant，转载请注明原文链接：https://www.cnblogs.com/aspirant/p/9172336.html
