到底什么是RPC?远程调用有什么好处?

柯南在写代码 2018-01-15 09:04:03
迷惑不解,不知是何.
我了解了一下dubbo框架,很多的术语搞得是更加模糊不清.
顺便提一点,
为什么深奥的东西就是被人向往的?
将复杂的东西弄成粗浅易懂的这不是更好吗?
...全文
2953 10 打赏 收藏 转发到动态 举报
写回复
用AI写文章
10 条回复
切换为时间正序
请发表友善的回复…
发表回复
月下门推2333 2019-11-17
  • 打赏
  • 举报
回复
引用 3 楼 kampoo 的回复:
[quote=引用 2 楼 kampoo 的回复:] 存在即合理,复杂的东西之所以能持续存在并发展不是无缘无故的,更不是因为高手们故弄玄虚,主要是它能带来某些明显的好处,你对这些东西掌握的越熟练,你会越喜欢它。关于RPC,很早以前是AXIS,现在花样就多了去了,基本道理都是用XML或者JSON来传递调用参数和结果。个人体会主要用到的优势是如下几点: 1. RPC能够跨多种开发工具及平台,比如说企业已有的系统开发完毕或者子系统已经部署交付了,它提供了RPC接口,新的子系统要集成,使用业界通用的RPC接口就可以集成了,你不可能要求原来的开发商再来修改一遍接口,否则的话就变成了信息孤岛; 2. RPC能够跨多个服务器,这个在其他计算机上很容易透过80端口的RPC来访问各个服务器。其他如TCP消息来访问,尽管高效但不方便而且还要穿透防火墙,尤其不方便网页集成。
再补充一点点,原来的RPC也有其他几种比如DCOM,CORBA,RMI(Java)等。前两种都是爷爷级的,现在年轻人都不太了解了。RMI也还可以,但现在远不如XML-RPC或者JSON用的普遍。 [/quote] RMI 使用专为 Java 远程对象定制的协议 JRMP(Java Remote Messaging Protocol)进行通信,这限制了它的通信双方,只能是 Java 语言的程序,无法实现跨语言通信;RMI 使用 Java 原生的对象序列化方式,生成的字节数组空间较大,效率很差。
maradona1984 2018-01-15
  • 打赏
  • 举报
回复
将复杂的事情弄得粗浅易懂,说着简单,做着复杂. 可以看看复杂度守恒定律 回到这个问题上,远程调用简单说就是发送一个请求给远程机器,远程机器返回一个结果回来的过程,为什么要这么做,单台服务器的性能远远不能满足现在互联网这个体量的用户的需求,就好比你去肯德基点个餐,餐台的服务员把薯条鸡腿汉堡的任务分给不同的人,然后收集起来给你的过程,餐台服务员就相当于调用远程服务. 但假如不这么做,点餐员直接做这些事情(又得点餐,又得炸薯条,炸鸡腿等等),两相比较,你就知道远程调用有什么好处了
大碗2512 2018-01-15
  • 打赏
  • 举报
回复
mark
kampoo 2018-01-15
  • 打赏
  • 举报
回复
引用 2 楼 kampoo 的回复:
存在即合理,复杂的东西之所以能持续存在并发展不是无缘无故的,更不是因为高手们故弄玄虚,主要是它能带来某些明显的好处,你对这些东西掌握的越熟练,你会越喜欢它。关于RPC,很早以前是AXIS,现在花样就多了去了,基本道理都是用XML或者JSON来传递调用参数和结果。个人体会主要用到的优势是如下几点: 1. RPC能够跨多种开发工具及平台,比如说企业已有的系统开发完毕或者子系统已经部署交付了,它提供了RPC接口,新的子系统要集成,使用业界通用的RPC接口就可以集成了,你不可能要求原来的开发商再来修改一遍接口,否则的话就变成了信息孤岛; 2. RPC能够跨多个服务器,这个在其他计算机上很容易透过80端口的RPC来访问各个服务器。其他如TCP消息来访问,尽管高效但不方便而且还要穿透防火墙,尤其不方便网页集成。
再补充一点点,原来的RPC也有其他几种比如DCOM,CORBA,RMI(Java)等。前两种都是爷爷级的,现在年轻人都不太了解了。RMI也还可以,但现在远不如XML-RPC或者JSON用的普遍。
kampoo 2018-01-15
  • 打赏
  • 举报
回复
存在即合理,复杂的东西之所以能持续存在并发展不是无缘无故的,更不是因为高手们故弄玄虚,主要是它能带来某些明显的好处,你对这些东西掌握的越熟练,你会越喜欢它。关于RPC,很早以前是AXIS,现在花样就多了去了,基本道理都是用XML或者JSON来传递调用参数和结果。个人体会主要用到的优势是如下几点: 1. RPC能够跨多种开发工具及平台,比如说企业已有的系统开发完毕或者子系统已经部署交付了,它提供了RPC接口,新的子系统要集成,使用业界通用的RPC接口就可以集成了,你不可能要求原来的开发商再来修改一遍接口,否则的话就变成了信息孤岛; 2. RPC能够跨多个服务器,这个在其他计算机上很容易透过80端口的RPC来访问各个服务器。其他如TCP消息来访问,尽管高效但不方便而且还要穿透防火墙,尤其不方便网页集成。
jingwen_yang 2018-01-15
  • 打赏
  • 举报
回复
先说RPC的优点吧: 1. 提升系统可扩展性 2. 提升系统可维护性和持续交付能力 3. 实现系统高可用 RPC的缺点: 1. 一个完善的RPC框架开发难度大 2. RPC框架调用成功率受限于网络状况 3. 调用远程方法对初学者来说难度大 dubbo不只是一个RPC框架,还是一个服务治理框架
柯南在写代码 2018-01-15
  • 打赏
  • 举报
回复
如果还是用术语来回复的各位老爷,咱还是算了.官方的文档我看的脑袋都大了
cdsn13082487212 2018-01-15
  • 打赏
  • 举报
回复
我之前参与过一个rpc项目,总的来说可以将一个工程分别差分成几个系统,然后系统之间通过接口调用实现的。这里主要需要zookper 来实现。所谓的好处呢,就是单个系统只负责单独一块的功能,另外在上线时,可以根据每一个系统,增加部署的机器的数量。我看来,传统的单个系统来说,如果顶不住压力,那么整个ngix 后面拽几个服务器,同样可以解决服务器顶不住压力的问题,但是这就没有目的性,所有的模块都增加了部署的数量,并不能直接的解决问题。另外,如果一个系统,想要ngix 负载均衡道每一个不同的机器上的画,那么你的session 怎么处理?这里需要redis 做分布式缓存。所以rpc 分布式,都是针对互联网项目来说,如果是小型项目,例如某个后台应用根本不用整这个,麻烦,rpc 系统开发起来麻烦。写接口,另外,是否信任所谓的前端,这个度很不好把握。我觉得,需要的项目才是用rpc。
oyljerry 2018-01-15
  • 打赏
  • 举报
回复
主要是用在大型服务内部。可以把不同功能拆分成不同的服务模块。这样在业务调用的时候通过rpc来进行通信。获取其他业务的返回值。从而组合成一个更大的服务提供给外面。rpc进行了服务拆分。提高健壮性。不会受到其他服务的影响。
Sunyiban 2018-01-15
  • 打赏
  • 举报
回复
简单来说就是无法在一个进程内,甚至一个计算机内通过本地调用的方式完成的需求,比如比如不同的系统间的通讯,甚至不同的组织间的通讯。由于计算能力需要横向扩展,需要在多台机器组成的集群上部署应用。

67,547

社区成员

发帖
与我相关
我的任务
社区描述
J2EE只是Java企业应用。我们需要一个跨J2SE/WEB/EJB的微容器,保护我们的业务核心组件(中间件),以延续它的生命力,而不是依赖J2SE/J2EE版本。
社区管理员
  • Java EE
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧