【Dubbo笔记整理二】RPC基本概述

客官°小女子只卖身不卖艺 2022-09-13 01:58 207阅读 0赞

> 版权声明：本文为 小异常 原创文章，非商用自由转载-保持署名-注明出处，谢谢！  
> 本文网址：[https://sunkuan.blog.csdn.net/article/details/120501254][https_sunkuan.blog.csdn.net_article_details_120501254]

### 文章目录 ###

*  一、RPC协议
 *  二、RPC框架
 *  三、RPC与HTTP、TCP/UDP的区别
 *  四、为什么需要RPC

> 怎么说呢，其实我感觉分布式虽然简单了不少，但其理论含义却很深奥，文字也就相对多了一些。**Dubbo** 是阿里巴巴开源的一个高性能、**基于 Java 开源的 RPC 框架**。  
> 　  
> **RPC** 是一种概念性的技术知识，它的中文名叫 **远程过程调用**。**远程过程调用** 这个词官方解释特别专业，在这里我也不复制粘贴了，用一小段幽默的故事给大家介绍一下 **什么是远程过程调用**：
> 
>     刚才女朋友问我什么是 RPC，我直接甩出去一句，RPC 就是远程过程调用嘛，
>     女朋友一个巴掌就飞过来了。吓的我赶紧坐起来好好解释。
>     
>     远程过程调用要相对于本地过程调用来说，比如你要洗衣服，那你直接把衣服丢到洗衣机里，
>     按下开关就可以洗了，这就是本地过程调用。
>     远程过程调用就是你在外面，突然想起衣服还没有洗，打个电话过来，叫我去洗衣服，
>     这就是远程过程调用。
>     
>     看这直白吧，通俗易懂。我真是天才。谁曾想到她直接甩给我一句话，
>     我要出去玩呀，一会儿记得接收我的 RPC 哦。 我：……
> 
> 好了，相信大家对 **RPC** 概念有了一个很清楚的认识。那本篇还是围绕 **Dubbo** 的前言知识来讲解 **RPC** 理论。

--------------------

# 一、RPC协议 #

*  **RPC** 虽然是一个概念，但它更是一种协议（**远程过程调用协议**），它是一种通过网络从远程计算机上请求服务，而不需要了解底层网络技术的协议。
 *  **RPC** 采用的是 **客户机 / 服务器** 模式，请求程序就是一个客户机，而服务提供程序就是一个服务器。

--------------------

# 二、RPC框架 #

*  **RPC 框架** 是 **RPC 协议** 的具体实现。在单机时代一台电脑运行多个进程，进程之间无法通讯，显然这会很浪费资源，因此后来出现了 IPC *（Inter-process communication，单机中运行的进程之间的相互通信）*，这样就能允许进程之间进行通讯，比如在一台计算机中的 A 进程写了一个吃饭的方法，那以前的话要在 B 进程中也要有一个吃饭的方法，必须要在 B 进程中写这个方法，但有了 **RPC** 后 B 只需要调用 A 进程的程序即可完成，再到后来网络时代的出现，大家电脑都连起来，这时可不可以调用其他电脑上的进程呢？当然可以，这样 **RPC 框架** 就出现了。严格意义上来讲：Unix 的生态系统中 **RPC** 可以在同一台电脑上以不同进程进行，也可以在不同电脑上进行；而在 Windows 里面同一台电脑上不同进程间的通讯还可以采用 LPC（本地访问）。一句话总结：**RPC 或 LPC 是上层建筑，IPC 是底层基础**。
 *  **RPC 框架** 有很多：比如 Java RMI 、 Thrift 、 Dubbo 、 grpc 等。

--------------------

# 三、RPC与HTTP、TCP/UDP的区别 #

*  **TCP / UDP：** 它们都是传输协议，主要区别是 **TCP 协议** 连接需要 3 次握手，断开需要 4 次挥手，是通过流来传输的，就是确定连接后，一直发送信息，传完后断开。**UDP** 不需要进行连接，直接把信息封装成多个报文，直接发送。所以 **UDP** 的速度更快，但是不保证数据的完整性。
 *  **HTTP：** 超文本传输协议，它是一种应用层协议，建立在 **TCP** 协议之上。
 *  **RPC** 是一种通过网络从远程计算机程序上请求服务的通讯协议，而不需要了解底层网络技术的协议。 所以 **RPC** 的实现可以通过不同的协议去实现 比如可以使用 HTTP 或 RMI 技术等。

--------------------

# 四、为什么需要RPC #

*  论复杂度，**RPC 框架** 肯定是高于简单的 HTTP 接口的。但毋庸置疑，HTTP 接口由于受限于 HTTP 协议，需要携带 HTTP 请求头，导致传输起来效率或者安全性不如 **RPC**。
 *  HTTP 接口是在接口不多、系统与系统交互较少的情况下，解决信息初期常使用的一种通信手段；它优点就是简单、直接、开发方便。利用现成的 HTTP 协议进行传输。但是如果是一个大型的网站，内部子系统较多、接口非常多的情况下，**RPC 框架** 的好处就显示出来了，首先是长连接，不必每次通信都要像 HTTP 一样去 3 次握手什么的，这样减少了网络开销（虽然这个问题在 HTTP2.0 已经被解决不再算是问题了）；其次就是 **RPC 框架** 一般都有注册中心，有丰富的监控管理；发布、下线接口、动态扩展等，对调用方来说是无感知、统一化的操作。第三个来说就是安全性。最后就是流行的服务化架构、服务化治理，**RPC 框架** 是一个强力的支撑。
 *  **RPC 我们可以理解成是一种概念，HTTP 其实也是 RPC 实现的一种方式，用 HTTP 交互就已经属于 RPC 了。**
 *  总的来说，**RPC 适用于大型系统，中小型系统使用 HTTP 就足够了**。

*博客中若有不恰当的地方，请您一定要告诉我。前路崎岖，望我们可以互相帮助，并肩前行！*

[https_sunkuan.blog.csdn.net_article_details_120501254]: https://sunkuan.blog.csdn.net/article/details/120501254