懂远程调用Rpc框架的同学来解答一下

Question

看了一下rpc框架的作用，是可以实现远程调用，可以基于http协议，也可以用别的协议。
这里的远程调用，指的应该是后端服务A和后端服务B互调吧（虽然有些地方会把调用方称作客户端，但其实还是服务端和服务端互调）。
那如果前端，就比如浏览器端，想通过post或者get方式去调后端的接口，也能称之为RPC方式吗？应该不是吧，充其量就是基于http的restful接口调用吧。而且前端（浏览器端）想去调后端接口，只能通过http协议，如果那些实现了别的协议的rpc框架，根本没法处理http请求吧
不知道我的理解对不对

Answer 1

HTTP是通信协议，RPC是一种开发方式，他可以基于HTTP协议（比如gRPC)，也可以基于其他协议，比如更基础的TCP

通信协议的选择只是RPC实现中的一小部分，更重要的一部分是编码协议。比如json/xml属于文本编码，还有二进制字节编码，比如protoful，thrift。http对比tcp，最诟病的就是多余的头信息，而且还是使用的文本编码，造成整个数据包体积过大。不过据说http2改进很多，修改为二进制编码了，还支持多路复用，gRPC就是基于http2实现的。

至于restful，其实他本身是一套将资源对象化的设计标准，不过目前都作为技术实现再用，本身又分为严格的和非严格的。从目前上来说restful接口可以认为是一种基于http使用json编码的RPC实现，但还是本身restful是设计规范，更多的是约束资源的访问获取手段，不应当用于复杂的函数调用。

最后前后端，目前javascript也有json-RPC，ajax-RPC一类的更专注于函数调用的RPC实现，可以基于HTTP，也可以基于websocket，如果目的是函数调用，你可以试用一下，会比使用restful舒服很多。

Answer 2

看下这个有没有帮助：http://www.roncoo.com/article...

Answer 3

正在做的项目使用的是icegrid，最大的用处是将列如redis服务，es搜索服务，业务服务等等都是单独独立出来，解决程序间的耦合问题，只提供service层接口。所以我理解的rpc框架就是客服端与服务端的交互，而客户端亦可称为其他程序的服务端。因此感觉在web项目使用rpc框架并不是很适用。

Answer 4

我的观点是http与RPC在实现上没有本质的区别，但是，http和RPC的设计目标是不一样的。

在实际中：

1. http对外服务，RPC一般是供内部调用
2. http可以作为RPC的传输层

Answer 5

rpc是没有post和get之分的.
你可以把多个rpc服务想象成一个很大的项目中的某些方法，比如 user相关方法，支付相关方法，rpc 只是把他们拆分开来而已，rpc直接可以互相调用，通过客户端调用即可。
当然前端也可以直接调用rpc，但是这样不好的一点就是各个端都不统一，可能做出来的东西bug比较多。
如果提供http服务，后端可以在http中调用相关rpc，把需要的聚合在一起，返回给前端，这样就比较统一了。

Answer 6

看问题要看到问题的本质，为什么要有RPC，如果没有RPC 会有什么样的困难，其实你可以这么理解，RPC 是基于http or TCP 协议之上实现的一种封装。 比如在 APP 开发中，以前没有GRPC 我们需要手动去发送请求，解包，然后再使用，但是如果我们在APP 开发中如果用GRPC 协议，那么我们只管调用都可以啦。那么从开发角度来说，GRPC 是不是功能上帮你做啦一层封装。后端也一样，如果没有GRPC 我们需要手动的去调用http 或者 tcp ，

Answer 7

RPC远程过程调用，本质上来说并不是一种协议，而是一种架构方法。将业务进行分布式部署，但是逻辑上调用起来好像“调用本地方法”一样。
http只是RPC的一种手段，thrift,grpc都是如此，不过后两个是直接基于TCP协议开发的私有协议栈，传输效率高于http.