到底什么是RPC - 概述

前言

远古时期，每个进程各干各的，但随着发展有时候会存在A进程调用B进程某一方法，使用其功能的场景，比如说把画图统一都在某一个进程中，其他进程只需要调用它就ok了（代码没有散落到各地、也减少了一部分动态链接的管理），但是最初是不支持的，就产生了所谓的IPC（Inter-process communication 本地进程间通信），没错这里的IPC就是上学的时候经常背的 共享内存等进程间通讯方式。
再后来越来越多的单机系统复杂到无法维护面临拆分，小型机的瓶颈凸显及性价比越来越低，由pc和廉价服务器构成的集群、分布式方案逐渐形成，开始出现多个pc或者服务器 搭建分布式系统的场景，之前单机上的IPC也演变成了现在的RPC（远程过程调用）。
做服务器端研发，经常会有这样的一些名词RMI(remote method invocation，面向对象的远程方法调用)、RPC（remote procedure call，远程过程调用）、SOAP(simple object access protoal，简单对象访问协议)、REST(representational state transfer，表达性状态转移)，这些都可以理解为调用远程方法的一些通信技术“风格”，其中RPC是一个泛化的概念，严格来说一切远程过程调用手段都属于rpc范畴，本系列要说的就是这个泛化的RPC。

定义

RPC（Remote Procedure Call Protocol）远程过程调用协议，就是允许程序调用另一个地址空间（通常是共享网络的另一台机器上）的过程或函数，且不需要显式编码这个远程调用的细节。
它是一种架设在计算机网络之上并隐藏底层网络技术，像调用本地服务一样调用远端程序，在编码代价不高的情况下提升吞吐的能力。
通俗来说，就是为了使程序员从网络处理中释放出来，在分布式环境下编程变得简单，无需关系底层网络实现细节&协议仅关注业务逻辑实现即可，比如Java的Dubbo、Go的net/rpc & RPCX、谷歌的grpc等。我们只需要按照约定定义对外接口，按照约定发起调用即可，操作起来跟调了一个函数差异不大。

核心关注点

看完定义之后，应该清楚rpc所要解决的核心问题：进程间通信时，减少网络编码的成本&出错概率
在看rpc时首先想到的是它的构成，通常来说是长这样的：

image.png
对于远程过程调用，通常有服务端、客户端、通信网络 三部分构成
一个RPC协议比较核心的通常是通信协议、编码协议、序列化格式：
客户端对传输内容（数据+指令） 进行序列化、协议编码、网络传输到远程服务器端，服务端接受输入对传输内容进行解码、反序列化完成数据的逻辑计算，产生输出后，同样方式传递给客户端，完成整个RPC调用。
一个RPC框架除实现RPC协议外，通常提供了负载均衡、容错机制、服务注册发现等附加功能：（这些功能并不是RPC所必需的）
在调用过程中，为了解决分布式环境下机器&服务数量巨大&状态繁多导致的难以管理的问题，RPC框架通常还集成了 “如何鉴别调用哪些机器，哪些机器是死是活” 的服务注册&发现功能。
对于分布式环境下必然存在的网络不稳定问题，提供了一定的容错机制。
针对合理使用机器&网络资源，保证各个机器的稳定程度，提供了一定的负载均衡功能

通信协议

在通信协议方面，RPC跨越了传输层和应用层，像grpc 就是基于http 2.0的协议、Dubbo在tcp基础上研发的应用层传输协议。
这一块后续会单独对于常见的应用层网络协议（基于TCP的自研协议、基于现有的HTTP 2.0）进行介绍，包括其中的特点优势等
另外，好多同学刚接触RPC时，可能会对RPC or http 产生一点疑惑，为什么有了http还要使用RPC，这两个概念的维度上是不同的：
HTTP ：提供标准的报文格式，都认可的通讯特性等，对外仍然暴露出标准的网络编程接口。
RPC ：针对某些领域的特定场景提供具有更灵活、可定制的、更加保密的协议。可以把RPC理解是通讯协议之上，站在服务的角度，做的更高一级的封装。
换句话说，如果你想 在http 1.1 上包一层函数代理（隐藏网络通信细节）、集成服务注册发现（某场景下的特定诉求）等具有加成作用的功能，你可能就写出了一个RPC框架。

编码协议

首先RPC协议是语言无关的，客户端的实现语言与服务端的实现语言可以是相同的也可以是不同的，在RPC调用时必然需要一种标准的编码协议来约定接口数据格式、处理传输内容的编码解码操作，具体要看框架的实现程度和支持。
后续会对业界常见的 基于文本编码的json、xml、基于二进制编码protobuf 为例进行介绍。

RPC框架选型

常见的RPC 框架是很多的，在我们进行新业务开发的时候RPC框架的选型问题会变得很凸显，通常有如下几个方面考虑：（核心就是成本（现在&将来），不能因为新技术或者大家都在用就贸然引入）
1、机器成本（比较各个RPC所能带来的性能提升，从而节省出的机器）
2、研发效率成本（引入新的技术所带来的效率提升比较）
3、研发质量成本（引入新的技术会不会引入新的风险，该风险是否可控，解决风险的代价）
4、人力成本（引入新的技术时，团队对该技术该语言的熟悉程度，引入&熟悉时需要付出的人力成本，要考虑团队技术栈等多方面因素）
前三点是引入的价值比较（是否值得引入、应该用哪个），最后一点是当前情况下是否值得引入。
分布式RPC框架性能大比拼 dubbo、motan、rpcx、gRPC、thrift的性能比较

小记

本系列文章是2020 年第一个系列的文章，同步更新中（服务注册发现等服务治理范畴内的内容本系列暂不叙述，仅说RPC）
《RPC 概述》
《由RPC 再探网络--高效率网络通信》
《由RPC 再探网络--http 2.0等应用层协议》
《由RPC 再探编码--高效率编码》
《用Netty手写RPC》
《用Go手写RPC》
《学RPC？来看看Dubbo》
《学RPC？来看看BRPC》
《学RPC？来看看GRPC》
《学RPC？来看看RPCX》
《通讯&编码，Redis应用层协议实现》
《通讯&编码，Kafka应用层协议实现》