关于架构方面有很多名词,有点晕头转向,今天就针对相关技术RPC/Web Service/REST/SOA/SOAP理解做下记录。
先对上面的名词做一个概要介绍:
1.SOA面向服务的软件架构(Service Oriented Architecture)
是一种计算机软件的设计模式,主要应用于不通应用组件中通过某种协议来互操作
它的基本设计原理是:服务提供了一个简单的接口,抽象了底层的复杂性,然后用户可以访问独立的服务,而不需要去了解服务底层平台实现。
正因为SOA架构实现不依赖于技术,因此能够被各种不同的技术实现。
例如:
SOAP, RPC
REST
DCOM
CORBA
OPC-UA
Web services
DDS
Java RMI
WCF (Microsoft's implementation of web services now forms a part of WCF)
Apache Thrift
SORCER
因此REST、SOAP、RPC、RMI、DCOM等都是SOA的一种实现而已。
2.Java RMI
SOA思想提出以后,就有很多基于在这个模型上的产物,很多适用于分布式的产物,同事也是越来越庞大系统的产物。Java RMI (Remote Method Invocation 远程方法调用)是用Java在JDK1.1中实现的,它大大增强了Java开发分布式应用的能力。而RMI就是开发百分之百纯Java的网络分布式应用系统的核心解决方案,所以如果不是java的系统就不能使用RMI,这也是其缺点之一。RMI全部的宗旨就是尽可能简化远程接口对象的使用,相当于在服务器端暴露服务,通过bind或者rebind方法注册到RMIRegistry中,注册的信息中包含url,以及相应的类。客户端在在注册中心根据url得到远程对象(stub,存根),然后调用stub远程调用方法,底层的一些stub怎么连接服务器,怎么获取结果返回,下面的参考链接都应该有讲到。
参考文章:http://www.jianshu.com/p/2c78554a3f36
http://blog.csdn.net/guyuealian/article/details/51992182
3.RPC
了解上面的RMI,它的主要的流程就是Client<-->stub<-->[NETWORK]<-->skeleton<-->Server,还有一个比较重要的概念就是RMIRegistry,其实大家网上去查RPC的时候流程其实都差不多,可能叫法和底层东西有点不一样,其实现所遵循的模型还是类似的。主要的区别的话是RMI是只适用于java的,而RPC任何语言都可以;第二点就是他们两者的调用方式不一样,最终的目标还是一致。
什么是RPC
远程方法调用,就是像调用本地方法一样调用远程方法。常见RPC框架结构图:
RPC框架要做到的最基本的三件事:
1、服务端如何确定客户端要调用的函数;
在远程调用中,客户端和服务端分别维护一个【ID->函数】的对应表, ID在所有进程中都是唯一确定的。客户端在做远程过程调用时,附上这个ID,服务端通过查表,来确定客户端需要调用的函数,然后执行相应函数的代码。
2、如何进行序列化和反序列化;
客户端和服务端交互时将参数或结果转化为字节流在网络中传输,那么数据转化为字节流的或者将字节流转换成能读取的固定格式时就需要进行序列化和反序列化,序列化和反序列化的速度也会影响远程调用的效率。
3、如何进行网络传输(选择何种网络协议);
多数RPC框架选择TCP作为传输协议,也有部分选择HTTP。如gRPC使用HTTP2。不同的协议各有利弊。TCP更加高效,而HTTP在实际应用中更加的灵活。
其与RMI大致的区别
1)RPC 跨语言,而 RMI只支持Java。
(2)RMI 调用远程对象方法,允许方法返回 Java 对象以及基本数据类型,而RPC 不支持对象的概念,传送到 RPC
服务的消息由外部数据表示 (External Data Representation, XDR) 语言表示,这种语言抽象了字节序类和数据类型结
构之间的差异。只有由 XDR 定义的数据类型才能被传递, 可以说 RMI 是面向对象方式的 Java RPC 。
(3)在方法调用上,RMI中,远程接口使每个远程方法都具有方法签名(url)。如果一个方法在服务器上执行,但是没有相
匹配的签名被添加到这个远程接口上,那么这个新方法就不能被RMI客户方所调用。
在RPC中,当一个请求到达RPC服务器时,这个请求就包含了一个参数集和一个文本值,通常形成“classname.methodname”的形式。这就向RPC服务器表明,被请求的方法在为 “classname”的类中,名叫“methodname”。然后RPC服务器就去搜索与之相匹配的类和方法,并把它作为那种方法参数类型的输入。这里的参数类型是与RPC请求中的类型是匹配的。一旦匹配成功,这个方法就被调用了,其结果被编码后返回客户方。说的直白一点就是rmi是自己写一个url,如果正确就获得相应的stub,而rpc的url是从注册中心去拿的,不会出现url不对的情况
4.soap
全称Simple Object Access Protocol简单对象访问协议,是交换数据的一种协议规范,是一种轻量的、简单的、基于XML(标准通用标记语言下的一个子集)的协议,它被设计成在WEB上交换结构化的和固化的信息。关键词——协议,实现分布式,webservice的一种协议,一种解决方式。
参考文章:http://blog.csdn.net/zhangzeyuaaa/article/details/20041015
5.REST
REST是英文representational state transfer(表象性状态转变)或者表述性状态转移。首次由Roy Fielding博士在2000年他的博士论文中提出REST(Representational State Transfer)风格的软件架构模式后,REST就基本上迅速取代了复杂而笨重的SOAP,成为Web API的标准了。Rest是web服务的一种架构风格;使用HTTP、URI、XML、JSON、HTML等广泛流行的标准和协议;轻量级,跨平台,跨语言的架构设计;它是一种设计风格一种思想,不是一种标准。Rest架构的主要原则如下:
1.网络上的所有事物都被抽象为资源
2.每个资源都有一个唯一的资源标识符
3.同一个资源具有多种表现形式(xml,json等)
4.对资源的各种操作不会改变资源标识符
5.所有的操作都是无状态的
符合REST原则的架构方式即可称为RESTful。RESTful 架构风格的服务是围绕资源
展开的,是典型的ROA架构。ROA
即Resource Oriented Architecture(面向资源的架构思想)RESTful通过一个URI(统一资源定位符)指向资源,即每个URI都对应一个特定的资源。要获取这个资源,访问它的URI就可以,因此URI就成了每一个资源的地址或识别符。一般的,每个资源至少有一个URI与之对应,最典型的URI即URL。
所谓"资源",就是网络上的一个实体,或者说是网络上的一个具体信息。它可以是一段文本、一张图片、一首歌曲、一种服务,总之就是一个具体的实在。资源总要通过某种载体反应其内容,文本可以用txt格式表现,也可以用HTML格式、XML格式表现,甚至可以采用二进制格式;图片可以用JPG格式表现,也可以用PNG格式表现;JSON是现在最常用的资源表示格式。
RESTful架构风格规定,数据的元操作,即CRUD(create, read, update和delete,即数据的增删查改)操作,分别对应于HTTP方法:GET用来获取资源,POST用来新建资源(也可以用于更新资源),PUT用来更新资源,DELETE用来删除资源,这样就统一了数据操作的接口,仅通过HTTP方法,就可以完成对数据的所有增删查改工作。
即:
例如:如果我们想要获取某个电商网站的某个商品,输入http://localhost:9999/products/123
,就可以看到id为123的商品页面,但这个结果是HTML页面,它同时混合包含了Product的数据和Product的展示两个部分。对于用户来说,阅读起来没有问题,但是,如果机器读取,就很难从HTML中解析出Product的数据。
如果一个URL返回的不是HTML,而是机器能直接解析的数据,这个URL就可以看成是一个Web API。比如,读取http://localhost:9999/api/products/123
,如果能直接返回Product的数据,那么机器就可以直接读取。
REST就是一种设计API的模式。最常用的数据格式是JSON。由于JSON能直接被JavaScript读取,所以,以JSON格式编写的REST风格的API具有简单、易读、易用的特点。
编写API有什么好处呢?由于API就是把Web App的功能全部封装了,所以,通过API操作数据,可以极大地把前端和后端的代码隔离,使得后端代码易于测试,前端代码编写更简单。
在移动互联网的大潮下,随着docker等技术的兴起,微服务概念也越来越被大家接受并应用于实践,日益增多的web service逐渐统一于RESTful 架构风。在企业中,RESTful API(也称RESTful Web服务)也逐渐超越SOAP成为实现SOA的重要手段之一。时至今日,RESTful架构风格已成为企业级服务的标配。
http://www.jianshu.com/p/65ab865a5e9f
6.Web Service
Web Service提供的服务是基于web容器的,底层使用http协议,类似一个远程的服务提供者,比如天气预报服务,对各地客户端提供天气预报,是一种请求应答的机制,是跨系统跨平台的。
首先客户端从服务器的到WebService的WSDL,同时在客户端声称一个代理类(Proxy Class) 这个代理类负责与WebService
服务器进行Request 和Response 当一个数据(XML格式的)被封装成SOAP格式的数据流发送到服务器端的时候,就会生成一个进程对象并且把接收到这个Request的SOAP包进行解析,然后对事物进行处理,处理结束以后再对这个计算结果进行SOAP
包装,然后把这个包作为一个Response发送给客户端的代理类(Proxy Class),同样地,这个代理类也对这个SOAP包进行解析处理,继而进行后续操作。这就是WebService的一个运行过程。
webservice是一种标准,他可以通过soap或RESTful的方式来实现。
传统的soap-webservice,使用了soap协议(基于xml包装)等。如果使用restful webservice的话,则不需要soap与之相关的协议等,而是通过最简单的 http 协议传输数据 ( 包括 xml 或 json) 。既简化了设计,也减少了网络传输量(因为只传输代表数据的 xml 或 json ,没有额外的 xml 包装)。
Web Service主要涉及的概念:
1. Http传输信道
2. XML的数据格式
3. SOAP封装格式
4. WSDL的描述方式
5. UDDI UDDI是一种目录服务,企业可以使用它对Webservices进行注册和搜索
参考文档:https://blog.csdn.net/u013551585/article/details/78983349
总结:
虽然ROA与SOA并不冲突,甚至把ROA看做SOA的一种也未尝不可,但由于RPC也是SOA,比较久远一点点论文、博客或图书也常把SOA与RPC混在一起讨论,因此,RESTful 架构风格的服务(SOA)通常被称之为ROA架构,很少提及SOA架构,以便更加显式的与RPC区分。
RPC风格曾是Web Service的主流,最初是基于XML-RPC协议(一个远程过程调用(remote procedure call,RPC)的分布式计算协议),后来渐渐被SOAP协议(简单对象访问协议(Simple Object Access Protocol))取代;RPC风格的服务,不仅可以用HTTP
,还可以用TCP
或其他通信协议。但RPC风格的服务,受开发服务采用语言的束缚比较大,如.NET框架中,开发web service的传统方式是使用WCF,基于WCF开发的服务即RPC风格的服务,使用该服务的客户端通常要用C#来实现,如果使用python或其他语言,很难实现可以直接与服务通信客户端;进入移动互联网时代后,RPC风格的服务很难在移动终端使用,而RESTful风格的服务,由于可以直接以json
或xml
为载体承载数据,以HTTP方法为统一接口完成数据操作,客户端的开发不依赖于服务实现的技术,移动终端也可以轻松使用服务,这也加剧了REST取代RPC成为web service的主导。
SOA架构中的对外服务一般都由web service来暴露。而web service的实现有基于soap的重量级实现以及基于rest的轻量级实现方式,轻量级的restful风格的web service API 就是将所有业务被抽象成资源使用“本真restful”来实现暴露出来,其实就是严格的rest实现,即就是ROA架构
SOA架构中的内部服务一般由某种高效的RPC调用来暴露,当然了 也可以用web service来暴露,性能可能有些损失,目前SOA使用的比较广泛,多数的分布式集群系统的盛行,其内部多节点之间的服务通信采用RPC调用来实现。毕竟现实业务,很多都是要“干什么”,不仅仅是对资源的增、删、改、查。