RPC入门介绍

RPC

什么是RPC

  RPC全称Remote Procedure Call，即远程过程调用。要理解RPC，首先要了解本地服务间的调用，由于在同一个内存空间，函数的内存地址调用前已经知晓，函数可以直接调用。但是服务方和调用方不在一个服务器上，service_a(server A) -> server B (service_b) 此时应该如何调用？

why RPC？

  我们应该很容易就可以想到http api方式调用，这当然是可行的，sever B提供出open api，调用方通过调用api进而调用service_b。但是有几个问题，不妨想以下几个问题：

1. 开发效率低，每次调用均需发起http连接，这部分需要调用方吃掉，当然可以代理层来吃掉通用的调用部分或者其他方式，但是不可否认需要调用方解决，同样服务方每提供一个服务均需开发一个对应的api。
2. 调用耗时长，每次调用都需要走http连接，3次握手。
3. 高可用，若某server一些故障导致服务不可用？

RPC架构

  rpc是一种架构，http也是实现网络传输的一种方式，socket，netty均可以实现网络传输。实现RPC不难，难的是实现一个高性能高可靠的rpc框架。
 解耦服务，对调用方来说，调用是透明的，无需关心服务方在哪里。
 
 rpc架构，这里借助dubbo架构图介绍一下：

1. 服务方注册服务到注册中心
2. 消费方订阅服务，从注册中心获取到服务地址
3. 消费方调用服务，调用信息（调用服务id，参数信息）序列化，网络传输至服务方，
4. 服务方接受到调用信息，反序列化，获取调用信息，invoke service，然后将结果序列化后同步返回
5. 调用方接受到返回信息，反序列化后，获取最终结果。
6. 监控等

几个重点：

1. 注册中心，服务的发布和订阅，服务寻址
2. 通讯协议，服务方地址 + 调用服务id + 参数，序列化
3. 反序列化，服务方接受到调用请求，反序列化出

dubbo架构如下

关于高可用rpc架构要考虑的一些问题

1. 负载均衡
2. 调用方缓存服务注册信息
3. 支持异步调用；
4. 服务修改了？版本控制
5. 服务端多线程处理调用
6. 等等