[RPC]关于RPC的一点理解

以下内容仅为个人理解,不作正确性保证,感谢批评指正

1.RPC是什么

1.1 概念

在分布式计算中，远程过程调用 （RPC） 是指计算机程序导致过程（子例程）在不同的地址空间（通常在共享网络上的另一台计算机上）中执行， 它的编码就好像是普通（本地）过程调用一样，程序员没有 显式 编码远程交互的详细信息。 也就是说，程序员编写的代码基本 相同，无论子例程是执行程序的本地还是远程的。 这是客户端-服务器交互的一种形式（调用方是客户端，执行者是服务器），通常通过请求-响应消息传递系统实现。 在面向对象的编程范例中，RPC 由远程方法调用 （RMI） 表示。 RPC 模型意味着 一定程度的位置透明性，即 调用过程 无论是本地还是远程，都大致相同，但通常它们不是 相同，因此可以将本地呼叫与远程呼叫区分开来。 远程呼叫通常比本地呼叫慢几个数量级且可靠性低 ，因此区分它们很重要。
RPC 是进程间通信 （IPC） 的一种形式，因为不同的进程具有不同的地址空间：如果在同一 台主机上，它们具有 不同的虚拟地址 空间， 即使 物理地址空间 相同; 而如果它们位于不同的主机上，则物理地址空间是不同的。 许多不同的 （通常是不兼容的）技术 已被用于实现该概念。
— 摘自维基百科

1.2 个人理解

RPC广义上是一种构架思想和方法,它明确了实现远程过程调用的基本形式,RPC本身并不指代某种特定的协议或框架,实现了RPC构架的协议/框架都可以称之为RPC协议/框架.

2.RPC协议

2.1 RPC协议的个人理解

RPC协议是实现远程过程调用过程中的数据传输问题的解决方案,实现数据网络传输就要基于现有传输协议(假定为N协议)做定制化封装,由此产生的N+协议便是RPC协议,N可以是基于传输层的TCP协议或者是应用层的HTTP协议或者其他传输协议.
由此可见,讨论RPC和其他网络传输协议(如TCP/HTTP等)意义不大.

2.2 常见的RPC协议

不同的RPC框架有着不同的网络传输方案,由此产生多个不同的RPC协议. 视RPC框架设计的拓展性,同一个PRC框架也可以支持多种RPC协议.
参考: 深入理解RPC之协议篇

3.RPC框架

3.1 RPC框架的个人理解

RPC框架是对是对RPC构架思想的具体实现.,它包含了对完成远程过程调用所涉及到的组件定义和实现,其中包含网络传输方案(即RPC协议),序列化方案,和远程调用方式等.

3.2 常见的RPC框架

• Dubbo：国内最早开源的 RPC 框架，由阿里巴巴公司开发并于 2011 年末对外开源，仅支持 Java 语言。
• Motan：微博内部使用的 RPC 框架，于 2016 年对外开源，仅支持 Java 语言。
• Tars：腾讯内部使用的 RPC 框架，于 2017 年对外开源，仅支持 C++ 语言。
• SpringCloud：国外 Pivotal 公司 2014 年对外开源的 RPC 框架，提供了丰富的生态组件。
• gRPC：Google 于 2015 年对外开源的跨语言 RPC 框架，支持多种语言。
• Thrift：最初是由 Facebook 开发的内部系统跨语言的 RPC 框架，2007 年贡献给了 Apache 基金，成为Apache 开源项目之一，支持多种语言。
  – 摘自知乎

其他

• 在某种角度,谈及RPC时我们可以讨论REST，在 2000 年，Roy Fielding 提议使用表述性状态转移 (REST) 作为设计 Web 服务的体系性方法。 REST 是一种基于超媒体构建分布式系统的架构风格。 REST 独立于任何基础协议，并且不一定绑定到 HTTP。只是最常见的 REST API 实现会使用 HTTP 作为应用程序协议。这里不再展开
• 除了REST还是RPC外, 服务网格 也是微服务间的通信技术的一种发展方向,而 服务网格 所要解决的问题不光是服务通信, 它的作用在于整个分布式应用构架,后续有机会再学习.

资料参考:
10分钟带你彻底搞懂 RPC 架构
服务网格通信基础结构 等