RPC简述

RPC简述

remote procedure call
远程方法调用，是一种概念。
从单机到分布式，涉及到分布式通讯，服务部署到不同机器上，这些服务之间要不要通讯？
最基本的数据传输格式，二进制数据。
最最原始的通讯格式是tcp/ip协议传输
当服务接口暴露以后，另一台机器调用我这个服务的时候，数据该怎么流动？
网络才是数据流动的载体，
可是数据先转为二进制，为啥？？因为网络上只有二进制数据，也只能传输二进制数据
能不能对网络传输这部分进行封装，从而提供一种简单办法，专注业务，至于网络传输部分把他单独出来，
使用代理模式中的动态代理来处理网络这块，动态产生一个新的类，调用这个类的方法的时候，会先调用处理器，处理器需要拿到代理，方法，以及方法参数 ，然后就处理网络传输这部分。RPC代理存在于客户端，因为要实现客户端对RPC框架“透明”调用，那么客户端不可能自行去管理消息格式、不可能自己去管理网络传输协议，也不可能自己去判断调用过程是否有异常。这一切工作在客户端都是交给RPC框架中的“代理”层来处理的。
如果想要自己实现一个 RPC，最简单的方式要实现三个技术点，分别是：
服务寻址
数据流的序列化和反序列化
网络传输
服务寻址可以使用 Call ID 映射。在本地调用中，函数体是直接通过函数指针来指定的，但是在远程调用中，函数指针是不行的，因为两个进程的地址空间是完全不一样的。
所以在 RPC 中，所有的函数都必须有自己的一个 ID。这个 ID 在所有进程中都是唯一确定的。
客户端在做远程过程调用时，必须附上这个 ID。然后我们还需要在客户端和服务端分别维护一个函数和Call ID的对应表。
当客户端需要进行远程调用时，它就查一下这个表，找出相应的 Call ID，然后把它传给服务端，服务端也通过查表，来确定客户端需要调用的函数，然后执行相应函数的代码。
实现方式：服务注册中心。

RPC 是一种技术思想而非一种规范或协议，常见 RPC 技术和框架有：
应用级的服务框架：阿里的 Dubbo/Dubbox、Google gRPC、Spring Boot/Spring Cloud。
远程通信协议：RMI、Socket、SOAP(HTTP XML)、REST(HTTP JSON)。
通信框架：MINA 和 Netty。
有些提供了生态圈的一些框架，比如gateway、agent等，有些restful风格的rpc框架天然支持API gateway进行负载均衡
RPC 调用分以下两种：

1. 同步调用
   客户方等待调用执行完成并返回结果。
2. 异步调用
   客户方调用后不用等待执行结果返回，但依然可以通过回调通知等方式获取返回结果。
   若客户方不关心调用返回结果，则变成单向异步调用，单向调用不用返回结果。

异步和同步的区分在于是否等待服务端执行完成并返回结果。

http接口是在接口不多、系统与系统交互较少的情况下，解决信息孤岛初期常使用的一种通信手段；优点就是简单、直接、开发方便。利用现成的http协议 进行传输。但是如果是一个大型的网站，内部子系统较多、接口非常多的情况下，RPC框架的好处就显示出来了，首先就是长链接，不必每次通信都要像http 一样去3次握手什么的，减少了网络开销；其次就是RPC框架一般都有注册中心，有丰富的监控管理；发布、下线接口、动态扩展等，对调用方来说是无感知、统 一化的操作。第三个来说就是安全性。最后就是最近流行的服务化架构、服务化治理，RPC框架是一个强力的支撑
rpc是一种概念，http也是rpc实现的一种方式。论复杂度，dubbo/hessian用起来是超级简单的。最近用dubbo和hessian比较多，http的几乎都被废弃了