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

[柯南在写代码]

迷惑不解,不知是何.
我了解了一下dubbo框架,很多的术语搞得是更加模糊不清.
顺便提一点,
为什么深奥的东西就是被人向往的?
将复杂的东西弄成粗浅易懂的这不是更好吗?

[Sunyiban]

简单来说就是无法在一个进程内，甚至一个计算机内通过本地调用的方式完成的需求，比如比如不同的系统间的通讯，甚至不同的组织间的通讯。由于计算能力需要横向扩展，需要在多台机器组成的集群上部署应用。

[oyljerry]

主要是用在大型服务内部。可以把不同功能拆分成不同的服务模块。这样在业务调用的时候通过rpc来进行通信。获取其他业务的返回值。从而组合成一个更大的服务提供给外面。rpc进行了服务拆分。提高健壮性。不会受到其他服务的影响。

[cdsn13082487212]

我之前参与过一个rpc项目，总的来说可以将一个工程分别差分成几个系统，然后系统之间通过接口调用实现的。这里主要需要zookper 来实现。所谓的好处呢，就是单个系统只负责单独一块的功能，另外在上线时，可以根据每一个系统，增加部署的机器的数量。我看来，传统的单个系统来说，如果顶不住压力，那么整个ngix 后面拽几个服务器，同样可以解决服务器顶不住压力的问题，但是这就没有目的性，所有的模块都增加了部署的数量，并不能直接的解决问题。另外，如果一个系统，想要ngix 负载均衡道每一个不同的机器上的画，那么你的session 怎么处理？这里需要redis 做分布式缓存。所以rpc 分布式，都是针对互联网项目来说，如果是小型项目，例如某个后台应用根本不用整这个，麻烦，rpc 系统开发起来麻烦。写接口，另外，是否信任所谓的前端，这个度很不好把握。我觉得，需要的项目才是用rpc。

[柯南在写代码]

如果还是用术语来回复的各位老爷,咱还是算了.官方的文档我看的脑袋都大了

[jingwen_yang]

先说RPC的优点吧： 1. 提升系统可扩展性 2. 提升系统可维护性和持续交付能力 3. 实现系统高可用 RPC的缺点： 1. 一个完善的RPC框架开发难度大 2. RPC框架调用成功率受限于网络状况 3. 调用远程方法对初学者来说难度大 dubbo不只是一个RPC框架，还是一个服务治理框架

[kampoo]

存在即合理，复杂的东西之所以能持续存在并发展不是无缘无故的，更不是因为高手们故弄玄虚，主要是它能带来某些明显的好处，你对这些东西掌握的越熟练，你会越喜欢它。关于RPC，很早以前是AXIS，现在花样就多了去了，基本道理都是用XML或者JSON来传递调用参数和结果。个人体会主要用到的优势是如下几点： 1. RPC能够跨多种开发工具及平台，比如说企业已有的系统开发完毕或者子系统已经部署交付了，它提供了RPC接口，新的子系统要集成，使用业界通用的RPC接口就可以集成了，你不可能要求原来的开发商再来修改一遍接口，否则的话就变成了信息孤岛； 2. RPC能够跨多个服务器，这个在其他计算机上很容易透过80端口的RPC来访问各个服务器。其他如TCP消息来访问，尽管高效但不方便而且还要穿透防火墙，尤其不方便网页集成。

[kampoo]

引用 2 楼 kampoo 的回复:

存在即合理，复杂的东西之所以能持续存在并发展不是无缘无故的，更不是因为高手们故弄玄虚，主要是它能带来某些明显的好处，你对这些东西掌握的越熟练，你会越喜欢它。关于RPC，很早以前是AXIS，现在花样就多了去了，基本道理都是用XML或者JSON来传递调用参数和结果。个人体会主要用到的优势是如下几点： 1. RPC能够跨多种开发工具及平台，比如说企业已有的系统开发完毕或者子系统已经部署交付了，它提供了RPC接口，新的子系统要集成，使用业界通用的RPC接口就可以集成了，你不可能要求原来的开发商再来修改一遍接口，否则的话就变成了信息孤岛； 2. RPC能够跨多个服务器，这个在其他计算机上很容易透过80端口的RPC来访问各个服务器。其他如TCP消息来访问，尽管高效但不方便而且还要穿透防火墙，尤其不方便网页集成。

再补充一点点，原来的RPC也有其他几种比如DCOM，CORBA，RMI（Java）等。前两种都是爷爷级的，现在年轻人都不太了解了。RMI也还可以，但现在远不如XML-RPC或者JSON用的普遍。

[大碗2512]

mark

[maradona1984]

将复杂的事情弄得粗浅易懂,说着简单,做着复杂. 可以看看复杂度守恒定律 回到这个问题上,远程调用简单说就是发送一个请求给远程机器,远程机器返回一个结果回来的过程,为什么要这么做,单台服务器的性能远远不能满足现在互联网这个体量的用户的需求,就好比你去肯德基点个餐,餐台的服务员把薯条鸡腿汉堡的任务分给不同的人,然后收集起来给你的过程,餐台服务员就相当于调用远程服务. 但假如不这么做,点餐员直接做这些事情(又得点餐,又得炸薯条,炸鸡腿等等),两相比较,你就知道远程调用有什么好处了

[月下门推2333]

引用 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 原生的对象序列化方式，生成的字节数组空间较大，效率很差。