深入了解RPC之4个关键点，以及优化姿势

写在前面

在我们日常开发的时候，为了满足产品（chouren）大大的需求难免会调用其它三方提供的服务，或者是公司内部的一些服务，可能你的调用机器和被调用机器的部署不在同一台物理机/虚拟机上（目前普遍使用docker/k8s部署），这个时候就需要远程过程调(RPC)用来解决服务调用的难题。

什么是RPC

RPC(远程过程调用), RPC提供的只是一个概念模型，并不给出真正的实现，只要发生了多台机器服务之间的调用，都可以成为是RPC，其实在市面上有很多的RPC框架， 譬如说阿里的DUBBO，还有SpringCloud的restful 接口api等等

解决RPC需要解决的什么问题

1：代理

因为涉及到两个机器，是不能直接调用的，或者说是不能直接访问到目标主机，所以需要一个代理对象来完成这个功能，目前可以使用jdk提供的动态代理，或者是三方提供的动态代理(cglib)的方式来完成整个的代理过程

2：序列化

在调用别人服务的时候，肯定需要一些参数(入参-出参等等)，这些参数需要在网络上进行传输，就涉及到了序列化的问题，因此在实现RPC的是，我们的参数是需要序列话的，序列化的方式我们有很多中选择， 可以选择jdk中自带的，三方的Hessian等等

3：通信

序列化好的数据（二进制流），是怎么到目标机器上面的，然而这个就需要通信技术来解决了，这就引入了I/o网络模型，有阻塞的，非阻塞的，信号的，多路复用的，以及异步的等，选择一种适合的就显示额外重要了

4：服务实例化

当目标服务器接受到了我们的请求后，并返回数据，我们需要在本机上面将进行反序列化，然后生成对象（不一定需要），调用服务

 

在实现RPC需要注意些什么

一个好的RPC框架最重要的还是取决于序列化的速度和大小，以及通信过程中传输的速率

在序列化的速度方面：可以使用序列化速度相对来说比较快的Hessian。dubbo默认使用的就是Hessian，并没有使用jdk的

在序列化的字节大小方面：可以使用哈夫曼编码技术以减少序列化之后的字节大小，也为一次传输需要传入的量

通信过程中传输的速率：这个因素会决定服务器响应客户端的时间，尽量使用可以支持多线程，高并发的网络传输I/O模型，在dubbo中就是使用了netty（NIO的框架，使用了非阻塞的多路复用的IO技术）作为网络非阻塞模型来支持