写在前面: 技术,不要那么复杂
远程过程调用协议
RPC(Remote Procedure Call)—远程过程调用,它是一种通过网络从远程计算机程序上请求服务,而不需要了解底>层网络技术的协议。RPC协议假定某些传输协议的存在,如TCP或UDP,为通信程序之间携带信息数据。在OSI网络>通信模型中,RPC跨越了传输层和应用层。RPC使得开发包括网络分布式多程序在内的应用程序更加容易。
RPC采用客户机/服务器模式。请求程序就是一个客户机,而服务提供程序就是一个服务器。首先,客户机调用进程发>送一个有进程参数的调用信息到服务进程,然后等待应答信息。在服务器端,进程保持睡眠状态直到调用信息到达为>止。当一个调用信息到达,服务器获得进程参数,计算结果,发送答复信息,然后等待下一个调用信息,最后,客户>端调用进程接收答复信息,获得进程结果,然后调用执行继续进行。
有多种 RPC模式和执行。最初由 Sun 公司提出。IETF ONC 宪章重新修订了 Sun 版本,使得 ONC RPC 协议成为 >IETF 标准协议。现在使用最普遍的模式和执行是开放式软件基础的分布式计算环境(DCE)。
我眼中的RPC
服务提供者提供 ---- 消费者消费
服务提供者在青岛捞海鲜,消费者坐在新疆的餐馆里点了一盘麻辣小龙虾
这中间的过程就是RPC
存在即合理,复杂的东西之所以能持续存在并发展不是无缘无故的,更不是因为高手们故弄玄虚,主要是它能带来某些明显的好处,你对这些东西掌握的越熟练,你会越喜欢它。关于RPC,很早以前的RPC也有其他几种比如DCOM,CORBA,RMI(Java)AXIS等,现在花样就多了去了,基本道理都是用XML或者JSON来传递调用参数和结果。个人体会主要用到的优势是如下几点:
将复杂的事情弄得粗浅易懂,说着简单,做着复杂.可以看看复杂度守恒定律
远程调用简单说就是发送一个请求给远程机器,远程机器返回一个结果回来的过程,为什么要这么做,单台服务器的性能远远不能满足现在互联网这个体量的用户的需求,就好比你去肯德基点个餐,餐台的服务员把薯条鸡腿汉堡的任务分给不同的人,然后收集起来给你的过程,餐台服务员就相当于调用远程服务.
但假如不这么做,点餐员直接做这些事情(又得点餐,又得炸薯条,炸鸡腿等等),两相比较,你就知道远程调用有什么好处了
简单来说就是无法在一个进程内,甚至一个计算机内通过本地调用的方式完成的需求,比如比如不同的系统间的通讯,甚至不同的组织间的通讯。由于计算能力需要横向扩展,需要在多台机器组成的集群上部署应用。
RPC的优点:
RPC的缺点: