rpc介绍

rpc是一个计算机通信协议，允许运行在一台计算机的程序调用另一台计算机的子程序，而程序员无须额外的为这个交互编程。

从上图可见，rpc本身是client-server模型，也是request-response模型。

服务的调用过程：

1.client调用client stub，这是一次本地过程调用

2.client stub将参数打包成一个消息，然后发送这个消息，打包过程也叫做marshalling

3.client所在的系统将消息发送给server

4.server所在的系统将收到的包传给server stub

5.server stub解包得到参数，解包也称为unmarshalling

6.最后server stub调用服务过程，返回结果按照相反的步骤传给client.

完整的rpc架构包含4个核心组件：

客户端(client):服务的调用方

服务端(server):真正的服务提供者

客户端存根(client stub)，存放服务端的地址消息，再将客户端的请求参数打包成网路消息，然后通过网络远程发送给服务方。

服务端存根，接收客户端发送过来的消息，将消息解包，并调用本地的方法。

rpc只是描绘了client与server之间的点对点调用流程，包括stub，通信，rpc，消息解析等，实际应用中，还需要考虑服务的高可用，负载均衡等，所以产品级的rpc除了点对点的rpc协议的具体实现外，还应包括服务发现与注销，提供服务的多台server的负载均衡，服务的高可用等。

rpc框架的两种侧重方向：

1.侧重于服务治理

如alibab dubbo，motan等。这类rpc功能丰富，提供高性能的远程调用以及服务发现和治理功能，适用于大型服务的微服务化拆分及管理。但是语言耦合度大，跨语言支持难度大。

2.侧重于跨语言调用

如thrift，grpc，hessian，finagle等。能够支持大部分的语言进行语言无关的调用，适合为不同语言提供通用远程服务的场景。这类框架没有服务发现相关机制，实际应用时一般需要代理层进行请求转发和负载均衡策略控制。

rpc  vs   restful

rpc的消息传输可以通过tcp,udp,或者http等，所以有时候称为rpc over tcp，rpc over http。rpc通过http传输消息的时候和restful的架构类似，但也有不同。

1.rpc over http  和 restful

1.rpc客户端和服务端紧耦合，客户端需要知道调用的过程的名字，过程的参数以及他们的类型，顺序等。一旦服务器更改了过程的实现，客户端的实现也很容易出现问题。restful基于http语义操作资源，参数的顺序一般没有关系，也很容易通过代理转换链接和资源位置，从这点看restful更灵活。

2.操作对象不一样。rpc操作的是方法和过程，要操作的是方法对象。restful操作的是资源，而不是方法。

3.restful执行的是对资源的操作，增加、查找、修改和删除等，主要是CRUD，所以要实现一个特定目的的操作，restful涉及起来可能不是那么直观。此时rpc实现起来就更方便，可提供一个方法供客户端调用。

2.rpc over tcp 和restful

rpc over tcp可以通过长连接减少连接的建立所产生的花费，在抵用次数非常巨大的时候（高并发），花费影响很大。restful可以通过keep-alive实现长连接，但是request-response是阻塞的，发送一个请求后只有等到response返回才能发送第二个请求。rpc没有这个限制。