rpc服务器是不是一般是服务器内部交互用的，这样有什么好处？
最近在学习rpc框架，因为我看有些rpc框架还没跨语言,序列化只有自己语言认识，而那些语言我看很少在客户端开发用到，我这里说的客户端指移动端，浏览器这种。比如golang,python。 那意味着是不是rpc框架主要是用于服务器内网交互的一种架构？ 这样做有什么好处啊？我看貌似好处就是分散流量压力啊，因为用rpc做分布式，计算工作还不全都交到那台server的服务器去做了吗？
我原来还以为rpc架构是客户端软件和服务器交互用的。。。
RPC从概念上讲，不是一种协议，也不属于通信的范畴；
而是一种编程技术，一种代码封装方式，目的是提高代码构建和维护效率。
RPC（Remote Procedure Call）把进程间（包括跨服务器）的通信过程封装成函数调用方式，隐藏复杂的通信处理细节，方便使用、简化代码；使得调用者可以像调用本地函数那样调用其他进程提供的处理过程。
一旦我们把RPC理解为一种代码封装技术，就很容易理解为啥看上去“内网用的多”，“客户端用的少”。
内网并不是关键。
关键是RPC在简化代码的同时增加了耦合。
如果我们定义两个实体之间通过HTTP通信（或其他任何协议），只要双方遵循HTTP协议，就没有问题，和双方的语言实现没有任何关系。
而如果是RPC，那么我们对外部呈现的是函数接口，这就和语言以及平台相关，需要给调用者提供函数声明文件和链接库。
当我们的场景耦合成本比较高时，例如我们构建的服务是提供给团队之外甚至是公司之外的用户使用，用RPC就比直接用HTTP麻烦多了——
我们需要提供各种版本，以支持用户的各种平台和语言。
即使采用支持多语言的RPC框架，那么这个框架（本质是一个代码库）也要双方都引用和依赖，这和直接采用协议比起来耦合要重的多。
显然您所看到的“服务器内网交互用的多“，并不是本质，本质是：
同一个系统内部交互，因为可以采用相同的基础平台（或框架），所以可以考虑使用RPC封装通信过程，以提高代码构建和维护效率，而恰恰系统内部交互大都是走内网。。。