RPC的原理分析

[wittyResry]

RPC处理过程

客户端 1.创建代理（cglib，java原生代理，javaassist）；2.路由寻址（配置中心，vip，test-url，sofa路由分组）；3.序列化(二进制传输）；4.编码（bolt为了通信的高效，还需要加超时，requestId，按照编码格式传输)；5.网络传输（netty），socket通道；14.收到网络；15.解码响应；16.反序列化 服务端 6.收到网络；7.解码；8.反序列化；9.反射调用；10.回传结果；11.序列化结果；12.编码；13.网络传输；

• 服务端问题：

  • 业务处理超时（服务端GC导致，JVM偏向锁，IO，Load过高）
  • 服务端线程池阻塞（下游hang住了，超时等待过长耗尽线程池）

• 客户端问题

  • 传输字节过大，网络开销
  • 客户端线程池阻塞

• 解决办法

  • 自定义线程池。
  • rpc调用权重预热，解决启动超时问题。
  • 单机故障清除。
  • 线程池耗尽，先增加机器解决。

准备

远程通讯、性能损耗、调用的透明化、同步/异步调用方式的实现

同步 RPC：指的是客户端发起调用后，必须等待调用执行完成并返回结果; 异步 RPC：指客户方调用后不关心执行结果返回，如果客户端需要结果，可用通过提供异步 callback 回调获取返回信息;

1. 对象序列化 对象的序列化过程在RPC过程中影响远程调用的响应速度、吞吐量、网络带宽消耗等。 五种序列化方式：java、hessian、hessian2、json、kyro
2. 动态代理 对于消费方来说，所存在的只有一个接口。虽然底层的实现原理我们知道，但是为了在使用时的高度透明，在JAVA语言层面上的表现形式则是通过动态代理的方式实现的，很多的逻辑都在InvocationHandler 中处理的
3. 网络通信NIO 如果在网络传输过程中，采取普通的BIO（block）,会有很多的问题存在。例如如果调用端有多个请求过来，那么就得需要多个线程去处理，每个线程都使用独立的连接，在远端的提供者端有对应的多个线程来执行相应的服务。这种方式会使得调用者和提供者之间建立大量的连接，而且是阻塞的方式，连接并不能得到充分的利用。 采用NIO则就可以避免这样的损耗，通过第三方的框架Netty，高性能 NIO 框架，如 mina,netty 实现： 协议管理（Protocol）：协议管理组件，负责整个 RPC 通信协议的编/解码； 连接端口（Connector）：负责维持客户方和服务方的长连接通道； 后台处理（Processor）：负责整个调用服务中的管理调度，包括线程池，分发，异常处理等； 连接通道（Channel）：客户端和服务器端的数据传输通道。

实现原理

1.提供rpc服务的大致流程如下： • server启动时候向configserver注册 • client启动时候向configserver请求list • client缓存list，发现不可用的server，从缓存中remove • configserver通过心跳包维护可用server的list • list有更新的时候，configserver通过带version的报文通知client更新

Proxy：接口代理、软负载、单元化 Remoting：Rpc IO：异步、长连接

发起一个 RPC 调用，需要传输的最基本数据如下：

接口方法：包括接口的名字和相应的方法名字； 方法参数：包括参数的类型和取值； 附件参数，包括调用接口版本，接口超时时间等等。

服务端调用优化

• 在动态代理模块，我们不会采用 java 自带的动态接口，而是会采用一些性能更高的三方库cglib
• 在连接通道和连接模块，我们会采用更优秀的三方NIO，如 netty 来实现
• 在后端处理模块，我们也不会仅仅是执行结果并返回，要考虑: 1) 并发控制：当多个请求并发处理的时候，如何管理和控制线程池和超时等待时间；2) 版本隔离：当服务有多个版本的时候，如何让不同的调用者能够调用正确的服务；3) 服务路由：当服务提供者有多台机器的时候，如何提高系统负载均衡，路由到正确的服务端；4) 服务降级：当多个服务重要性有不同的时候，如果保证核心业务的稳定性，适当的降低非核心业务优先级；5) 服务监控和报警：服务出现异常情况时候，运维和对应的系统负责人能够第一时间得到告警和错误信息。

虽然 RPC 有足够多的优点让你去使用，但是当真正转向服务化的时候，依然有很多需要考虑的地方：1)网络问题：本地调用无需考虑是否能够执行问题，网络调用可能会因为各种外部网络环境，端口拦截，IP 受限等可能情况导致无法成功执行。所以 RPC 的服务端通常要考虑幂等性和容错性，接口需要较强的鲁棒性设计；2)异常处理：RPC 和本地服务最大的不同就是 RPC 服务存在分布式一致性问题，当服务没有调用成功情况下，本地和远程的服务可能处于一个不一致的状态，如何进行异常处理和事物的回滚机制也是一个需要考虑的问题，是需要保障强一致性和最终一致性通常取决于具体的业务需求。

建议：可以参考当前最主流的一些 RPC 框架，如dubbo, protobuff, thrift 通过对其源码的深入学习，相信能获益匪浅。

[wittyResry]

1. 扩展点加载机制(ExtensionLoader)
2. Filter:双向过滤的，既可以拦截服务请求，也可以拦截服务响应
3. netty-mina深入学习与对比
4. rpc协议 Link2