远程过程调用协议

前面两个小节分别对rpc服务端和客户端的建立流程做了详细的分析，也就是说rpc客户端和服务器端已经能够进行正常的通信了（rpc客户端已经通过connect链接上rpc服务器了），那么这一小节主要根据一个实际的例子来分析一个完整的rpc通信过程。 下面以客户端创建逻辑卷（volume）为例来分析rpc的通信过程，就以下面这个客户端的命令开始： gluster volume create test-volume server3:/exp3 server4:/exp4 先简单看看glusterfs的客户端是怎样开始提交rpc请求的，提交准备过程流程图如下： 从上面的流程图可以看出真正开始提交 rpc 请求调用还是从具体命令的回调函数开始发起的，上面的流程图主要展示的是准备工作，下面从具体命令的回调函数开始分析，这里分析的实例是创建逻辑卷的命令，执行的函数是 cli_cmd_volume_create_cbk ，主要实现代码如下： 1 proc = &cli_rpc_prog->proctable[GLUSTER_CLI_CREATE_VOLUME]; // 从rpc程序表中选择对应函数 2 3 frame = create_frame (THIS, THIS->ctx->pool); // 创建帧 4 5 ret = cli_cmd_volume_create_parse (words,

本文简单地介绍一下两种形式的C/S架构，先说一下他们最本质的区别，就是 RPC主要是基于TCP/IP协议的，而HTTP服务主要是基于HTTP协议的 ，我们都知道HTTP协议是在传输层协议TCP之上的，所以效率来看的话，RPC当然是要更胜一筹啦！下面来具体说一说RPC服务和HTTP服务。 OSI网络七层模型 在说RPC和HTTP的区别之前，我觉的有必要了解一下OSI的七层网络结构模型（虽然实际应用中基本上都是五层），它可以分为以下几层： （从上到下） 第一层：应用层。定义了用于在网络中进行通信和传输数据的接口； 第二层：表示层。定义不同的系统中数据的传输格式，编码和解码规范等； 第三层：会话层。管理用户的会话，控制用户间逻辑连接的建立和中断； 第四层：传输层。管理着网络中的端到端的数据传输； 第五层：网络层。定义网络设备间如何传输数据； 第六层：链路层。将上面的网络层的数据包封装成数据帧，便于物理层传输； 第七层：物理层。这一层主要就是传输这些二进制数据。 实际应用过程中，五层协议结构里面是没有表示层和会话层的。应该说它们和应用层合并了。我们应该将重点放在应用层和传输层这两个层面。因为 HTTP是应用层协议，而TCP是传输层协议 。好，知道了网络的分层模型以后我们可以更好地理解为什么RPC服务相比HTTP服务要Nice一些！ TCP(Transmission Control

RPC 全称 Remote Procedure Call――远程过程调用。在学校学编程，我们写一个函数都是在本地调用就行了。但是在互联网公司，服务都是部署在不同服务器上的分布式系统，如何调用呢？ RPC技术简单说就是为了解决远程调用服务的一种技术，使得调用者像调用本地服务一样方便透明。 下图是客户端调用远端服务的过程： 1）客户端client发起服务调用请求。 2）client stub 可以理解成一个代理，会将调用方法、参数按照一定格式进行封装，通过服务提供的地址，发起网络请求。 3）消息通过网络传输到服务端。 4）server stub接受来自socket的消息 5）server stub将消息进行解包、告诉服务端调用的哪个服务，参数是什么 6）结果返回给server stub 7）sever stub把结果进行打包交给socket 8）socket通过网络传输消息 9）client slub 从socket拿到消息 10）client stub解包消息将结果返回给client。 一个RPC框架就是把步骤2到9都封装起来。 为什么需要RPC 1、首先要明确一点：RPC可以用HTTP协议实现，并且用HTTP是建立在 TCP 之上最广泛使用的 RPC，但是互联网公司往往用自己的私有协议，比如鹅厂的JCE协议，私有协议不具备通用性为什么还要用呢？因为相比于HTTP协议

微服务的特点 单一职责：微服务中每一个服务都对应唯一的业务能力，做到单一职责； 微：微服务的服务拆分粒度很小，例如一个用户管理就可以作为一个服务。每个服务虽小，但是五脏俱全。 面向服务：面向服务是说每个服务都要对外暴露服务接口API，并不关心服务的技术实现，做到与平台无关、与语言无关，也不限定什么技术实现，只要提供Rest接口即可。 自治：自治是说服务间互相独立，互不干扰； 团队独立：每个服务都是一个独立的开发团队； 技术独立：因为是面向服务，提供Rest接口，使用什么技术没有别人干涉； 前后端分离：采用前后端分离开发，提供统一Rest接口，后端不再为PC、移动端开发不同接口。 数据库分离：每个服务都使用自己的数据源； 部署独立：服务间虽然由调用，但要做到服务重启不影响其他服务。有利用持续集成和持续交付。每个服务都是独立的组件，可复用，可替换，降低耦合，容易维护。 微服务结构图 远程调用方式 常见的远程调用方式 RPC：Remote Process Call 远程过程调用，类似的还有RMI。自定义数据格式，基于原生TCP通信，速度快，效率高。比如早期的webservice和现在的Dubbo，都是RPC典型； Http:http其实是一种网络传输协议，基于TCP，规定了数据传输的格式，现在客户端浏览器与服务端通信基本都是采用http协议，也可以用来进行远程服务调用，缺点是消息封装臃肿

RPC RPC 就是为解决服务之间信息交互而发明和存在的。 RPC（Remote Procedure Call）――远程过程调用，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。 RPC 采用客户机/服务器模式。请求程序就是一个客户机，而服务提供程序就是一个服务器。 首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。 在服务器端，进程保持睡眠状态直到调用信息到达为止。 当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息 然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。 RPC 就是一种远程调用函数接口的方式，说白了，就是一种远程调用函数接口的方式，客户端和服务端之间约定一种契约（函数接口），然后服务端一直等待客户端的调用。 有点像平常的 WEB 网络请求。 一种用途是在多台服务器之间互相进行调用。 另一个用途则在于，不同编程语言之间都支持这种方式，像 Python 更是内置对其的支持，不需要额外安装什么库，所以可以直接在多语言的服务器之间互相进行调用。 Socket 编程就是 RPC 通信 简单的服务端 像web请求一样，我们需要确定供客户端访问的url和端口号，以及供客户端调用的方法实现，最后要让我们服务器一直处于等待被访问的状态： rpc_server.py

一、序言 　　 大家或多或少都听过 WebService（Web服务），有一段时间很多计算机期刊、书籍和网站都大肆的提及和宣传WebService技术，其中不乏很多吹嘘和做广告的成 分。但是不得不承认的是WebService真的是一门新兴和有前途的技术，那么WebService到底是什么？何时应该用？ 　　当前的应用程序开发逐步的呈现了两种迥然不同的倾向：一种是基于浏览器的瘦客户端应用程序，一种是基于浏览器的富客户端应用程序（RIA），当然后一种技术相对来说更加的时髦一些（如现在很流行的Html5技术），这里主要讲前者。 　　基于浏览器的瘦客户端应用程序并不是 因为瘦客户能够提供更好的用户界面，而是因为它能够避免花在桌面应用程序发布上的高成本。发布桌面应用程序成本很高，一半是因为应用程序安装和配置的问 题，另一半是因为客户和服务器之间通信的问题。传统的Windows富客户应用程序使用DCOM来与服务器进行通信和调用远程对象。配置好DCOM使其在 一个大型的网络中正常工作将是一个极富挑战性的工作，同时也是许多IT工程师的噩梦。事实上，许多IT工程师宁愿忍受浏览器所带来的功能限制，也不愿在局 域网上去运行一个DCOM。关于客户端与服务器的通信问题，一个完美的解决方法是使用HTTP协议来通信。这是因为任何运行Web浏览器的机器都在使用 HTTP协议。同时

一：什么是 Web Service ? 一言以蔽之： WebService是一种跨编程语言和跨操作系统平台的远程调用技术。 所谓跨编程语言和跨操作平台，就是说服务端程序采用java编写，客户端程序则可以采用其他编程语言编写，反之亦然！跨操作系统平台则是指服务端程序和客户端程序可以在不同的操作系统上运行。 所谓远程调用，就是一台计算机a上 的一个程序可以调用到另外一台计算机b上的一个对象的方法，譬如，银联提供给商场的pos刷卡系统，商场的POS机转账调用的转账方法的代码其实是跑在银 行服务器上。 再比如， amazon，天气预报系统，淘宝网，校内网，百度等把自己的系统服务以webservice服务的形式暴露出来，让第三方网站和程 序可以调用这些服务功能，这样扩展了自己系统的市场占有率，往大的概念上吹，就是所谓的SOA应用。 其实可以从多个角度来理解 WebService， 从表面上看， WebService就是一个应用程序向外界暴露出一个能通过Web进行调用的API， 也就是说能用编程的方法通过 Web来调用这个应用程序。我们把调用这个WebService的应用程序叫做客户端，而把提供这个WebService的应用程序叫做服务端。 从深层次 看， WebService是建立可互操作的分布式应用程序的新平台，是一个平台，是一套标准。它定义了应用程序如何在Web上实现互操作性

RPC（Remote Procedure Call Protocol） RPC使用C/S方式，采用http协议,发送请求到服务器，等待服务器返回结果。这个请求包括一个参数集和一个文本集，通常形成“classname.methodname”形式。优点是跨语言跨平台，C端、S端有更大的独立性，缺点是不支持对象，无法在编译器检查错误，只能在运行期检查。 Web Service Web Service提供的服务是基于web容器的，底层使用http协议，类似一个远程的服务提供者，比如天气预报服务，对各地客户端提供天气预报，是一种请求应答的机制，是跨系统跨平台的。就是通过一个servlet，提供服务出去。 首先客户端从服务器的到WebService的WSDL，同时在客户端声称一个代理类(Proxy Class) 这个代理类负责与WebService 服务器进行Request 和Response 当一个数据（XML格式的）被封装成SOAP格式的数据流发送到服务器端的时候，就会生成一个进程对象并且把接收到这个Request的SOAP包进行解析，然后对事物进行处理，处理结束以后再对这个计算结果进行SOAP 包装，然后把这个包作为一个Response发送给客户端的代理类(Proxy Class)，同样地，这个代理类也对这个SOAP包进行解析处理，继而进行后续操作

如何科学的解释RPC 说起RPC，就不能不提到分布式，这个促使RPC诞生的领域。 假设你有一个计算器接口，Calculator，以及它的实现类CalculatorImpl，那么在系统还是单体应用时，你要调用Calculator的add方法来执行一个加运算，直接new一个CalculatorImpl，然后调用add方法就行了，这其实就是非常普通的本地函数调用，因为在同一个地址空间，或者说在同一块内存，所以通过方法栈和参数栈就可以实现。 现在，基于高性能和高可靠等因素的考虑，你决定将系统改造为分布式应用，将很多可以共享的功能都单独拎出来，比如上面说到的计算器，你单独把它放到一个服务里头，让别的服务去调用它。 这下问题来了，服务A里头并没有CalculatorImpl这个类，那它要怎样调用服务B的CalculatorImpl的add方法呢？ 有同学会说，可以模仿B/S架构的调用方式呀，在B服务暴露一个Restful接口，然后A服务通过调用这个Restful接口来间接调用CalculatorImpl的add方法。 很好，这已经很接近RPC了，不过如果是这样，那每次调用时，是不是都需要写一串发起http请求的代码呢？比如httpClient.sendRequest...之类的，能不能像本地调用一样，去发起远程调用，让使用者感知不到远程调用的过程呢，像这样： @Reference

转载地址: http://blog.csdn.net/qq_19916577/article/details/44988015 一、序言 大家或多或少都听过WebService（Web服务），有一段时间很多计算机期刊、书籍和网站都大肆的提及和宣传WebService技术，其中不乏很多吹嘘和做广告的成分。但是不得不承认的是WebService真的是一门新兴和有前途的技术，那么WebService到底是什么？何时应该用？ 当前的应用程序开发逐步的呈现了两种迥然不同的倾向：一种是基于浏览器的瘦客户端应用程序，一种是基于浏览器的富客户端应用程序（RIA），当然后一种技术相对来说更加的时髦一些（如现在很流行的Html5技术），这里主要讲前者。 基于浏览器的瘦客户端应用程序并不是因为瘦客户能够提供更好的用户界面，而是因为它能够避免花在桌面应用程序发布上的高成本。发布桌面应用程序成本很高，一半是因为应用程序安装和配置的问题，另一半是因为客户和服务器之间通信的问题。传统的Windows富客户应用程序使用DCOM来与服务器进行通信和调用远程对象。配置好DCOM使其在一个大型的网络中正常工作将是一个极富挑战性的工作，同时也是许多IT工程师的噩梦。事实上，许多IT工程师宁愿忍受浏览器所带来的功能限制，也不愿在局域网上去运行一个DCOM。关于客户端与服务器的通信问题