rpc服务器是不是一般是服务器内部交互用的，这样有什么好处？

Question

最近在学习rpc框架，因为我看有些rpc框架还没跨语言,序列化只有自己语言认识，而那些语言我看很少在客户端开发用到，我这里说的客户端指移动端，浏览器这种。比如golang,python。那意味着是不是rpc框架主要是用于服务器内网交互的一种架构？这样做有什么好处啊？我看貌似好处就是分散流量压力啊，因为用rpc做分布式，计算工作还不全都交到那台server的服务器去做了吗？我原来还以为rpc架构是客户端软件和服务器交互用的。。。

Answer 1

RPC从概念上讲，不是一种协议，也不属于通信的范畴；而是一种编程技术，一种代码封装方式，目的是提高代码构建和维护效率。
RPC（RemoteProcedureCall）把进程间（包括跨服务器）的通信过程封装成函数调用方式，隐藏复杂的通信处理细节，方便使用、简化代码；使得调用者可以像调用本地函数那样调用其他进程提供的处理过程。
一旦我们把RPC理解为一种代码封装技术，就很容易理解为啥看上去“内网用的多”，“客户端用的少”。内网并不是关键。关键是RPC在简化代码的同时增加了耦合。如果我们定义两个实体之间通过HTTP通信（或其他任何协议），只要双方遵循HTTP协议，就没有问题，和双方的语言实现没有任何关系。而如果是RPC，那么我们对外部呈现的是函数接口，这就和语言以及平台相关，需要给调用者提供函数声明文件和链接库。
当我们的场景耦合成本比较高时，例如我们构建的服务是提供给团队之外甚至是公司之外的用户使用，用RPC就比直接用HTTP麻烦多了——我们需要提供各种版本，以支持用户的各种平台和语言。即使采用支持多语言的RPC框架，那么这个框架（本质是一个代码库）也要双方都引用和依赖，这和直接采用协议比起来耦合要重的多。
显然题主所看到的“服务器内网交互用的多“，并不是本质，本质是：同一个系统内部交互，因为可以采用相同的基础平台（或框架），所以可以考虑使用RPC封装通信过程，以提高代码构建和维护效率，而恰恰系统内部交互大都是走内网。。。
                            

Answer 2

RPC是点对点之间通信用的一种协议，这种点对点不仅仅是指服务器和服务器之间，你所说的客户端与服务器之间的通信，广义上来说也可以是RPC（远程过程调用/远程方法调用）。
RPC的方式有很多，常见的各种原始xxxRPC/SOAP/REST/Thrift/gRPC/ProtoBuf等等，根据使用场景的不同可以划分为以下几类：
为业务解耦的需要；
为跨语言或者跨平台的需要；
为服务化、集群化、负载均衡及可伸缩性的需要；
不同的使用场景，对于RPC的选型和架构设计也不太一样。