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

Question

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

我原来还以为rpc架构是客户端软件和服务器交互用的。。。

Answer 1

RPC从概念上讲，不是一种协议，也不属于通信的范畴；
而是一种编程技术，一种代码封装方式，目的是提高代码构建和维护效率。

RPC（Remote Procedure Call）把进程间（包括跨服务器）的通信过程封装成函数调用方式，隐藏复杂的通信处理细节，方便使用、简化代码；使得调用者可以像调用本地函数那样调用其他进程提供的处理过程。

一旦我们把RPC理解为一种代码封装技术，就很容易理解为啥看上去“内网用的多”，“客户端用的少”。
内网并不是关键。
关键是RPC在简化代码的同时增加了耦合。
如果我们定义两个实体之间通过HTTP通信（或其他任何协议），只要双方遵循HTTP协议，就没有问题，和双方的语言实现没有任何关系。
而如果是RPC，那么我们对外部呈现的是函数接口，这就和语言以及平台相关，需要给调用者提供函数声明文件和链接库。

当我们的场景耦合成本比较高时，例如我们构建的服务是提供给团队之外甚至是公司之外的用户使用，用RPC就比直接用HTTP麻烦多了——
我们需要提供各种版本，以支持用户的各种平台和语言。
即使采用支持多语言的RPC框架，那么这个框架（本质是一个代码库）也要双方都引用和依赖，这和直接采用协议比起来耦合要重的多。

显然题主所看到的“服务器内网交互用的多“，并不是本质，本质是：
同一个系统内部交互，因为可以采用相同的基础平台（或框架），所以可以考虑使用RPC封装通信过程，以提高代码构建和维护效率，而恰恰系统内部交互大都是走内网。。。

Answer 2

RPC是点对点之间通信用的一种协议，这种点对点不仅仅是指服务器和服务器之间，你所说的客户端与服务器之间的通信，广义上来说也可以是RPC（远程过程调用/远程方法调用）。

RPC的方式有很多，常见的各种原始xxxRPC/SOAP/REST/Thrift/gRPC/ProtoBuf等等，根据使用场景的不同可以划分为以下几类：

1. 为业务解耦的需要；
2. 为跨语言或者跨平台的需要；
3. 为服务化、集群化、负载均衡及可伸缩性的需要；

不同的使用场景，对于RPC的选型和架构设计也不太一样。

Answer 3

是不是我只有一台服务器就没有必要用rpc?

不是的， 你装的操作系统进程间通信大量的大用rpc技术，因为当软件复杂到一定程度时需要通过模块化解耦，便于分别升级维护，便于团队开发。

rpc是不是要可以用于远程的客户端服务器通信？

可以的，http-rpc了解下。处理好现在的微服务也是类似的概念，需要做的是处理好安全，和流量管理的问题，这些都有现成的方案。问题是哪种技术更适合。

rpc是否可以跨语言？

当然没问题，跨平台跨语言的早就发明出来了。但如果用同一种语言的序列化方式，显然会更方便也效率更高，成本更低，前提是你没有跨语言的要求。