2020-10-29 RPC和http

对比

RPC常用在分布式系统，性能要求高的场景，可以建立在udp，tcp之上，也可以建立在http协议之上（比如说著名的grpc使用http2）或者自定义的tcp（自定义的tcp根据需要约定字段，可以减少很多废话）。
HTTP用在浏览器服务器通信，传输的内容废话太多，太笨重（指http1.1，到http2已经优化了编码问题，那用自定义的tcp就必要不大，可以直接用基于http2的rpc了），但是可读性好（用restful风格的http越来越多，restful要求uri，要求参数名好认等），通过各种防火墙穿透性好。

既然效率问题差不大了，rpc比http更多的是服务治理。成熟的rpc库相对http容器，更多的是封装了“服务发现”，"负载均衡"，“熔断降级”一类面向服务的高级特性。可以这么理解，rpc框架是面向服务的更高级的封装。如果把一个http servlet容器上封装一层服务发现和函数代理调用，那它就已经可以做一个rpc框架了。

适用场景：

RPC常用在分布式系统，性能要求高的场景。（服务A调用服务B的过程是应用间的内部过程，牺牲可读性提升效率、易用性是可取的。）

HTTP用在浏览器服务器通信，可读性好，通过各种防火墙穿透性好。

RPC：

调用方调用的是接口，必须得为接口构造一个假的实现。显然，要使用动态代理。这样，调用方的调用就被动态代理接收到了。
第二，动态代理接收到调用后，应该想办法调用远程的实际实现。
这包括下面几步：
识别具体要调用的远程方法的IP、端口
将调用方法的入参进行序列化
通过通信将请求发送到远程的方法中

这样，远程的服务就接收到了调用方的请求。它应该：
反序列化各个调用参数
定位到实际要调用的方法，然后输入参数，执行方法
按照调用的路径返回调用的结果