开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第18天，点击查看活动详情
今天开始学习新的概念RPC概念，上一篇文章中讲了RabbitMQ中如何模拟RPC的调用，今天接着RPC概念学习下GO中的RPC框架，流行的RPC库有gRPC、Thrift等
RPC介绍
RPC（Remote Procedure Call，远程过程调用）是一种通过网络请求从远程服务器调用服务，不需要了解网络底层通信协议，RPC 协议基于传输层的 TCP 或 UDP 协议，或者是应用层的 HTTP 协议构建，允许开发者直接调用另一台计算机上的程序，从而使得开发网络分布式应用程序更加容易，例如微服务就是用了RPC调用
关于RPC的起源大概可以追溯到1976年以“信使报”（Courier）的名义使用。RPC首次在UNIX平台上普及的执行工具程序是SUN公司的RPC（现在叫ONC RPC）。它被用作SUN的NFC的主要部件。ONC RPC今天仍在服务器上被广泛使用。 另一个早期UNIX平台的工具是“阿波罗”计算机网络计算系统（NCS），它很快就用做OSF的分布计算环境（DCE）中的DCE/RPC的基础，并补充了DCOM。
远程过程调用是一个分布式计算的客户端-服务器(client-server)的例子，远程过程调用总是由客户端对服务端发送一个执行请求，并附带参数，执行结果会返回给客户端，为了允许不同客户端能够访问服务端，不同标准化的RPC系统就诞生了，大部分采用的是IDL（Interface Description Language）接口描述语言,有助于跨平台的远程调用
上图的Client-Server模型，其实也是一种Request-response协议，服务的调用过程如下：
- client进入客户端入口，这是一次本地过程调用
- 客户端入口将参数打包成一个消息，然后发送这个消息，这个过程也叫做marshalling
- client所在的系统将消息发送给server
- server的的系统将收到的包传给服务端入口
- 服务端入口解包得到参数，这个过程也称作unmarshalling
- 最后Server调用服务过程. 返回结果按照相反的步骤传给client
RPC框架
RPC只是描绘了 Client 与 Server 之间的点对点调用流程，包括 stub、通信、RPC 消息解析等部分，在实际应用中，还需要考虑服务的高可用、负载均衡等问题
更高级的的 RPC 框架除了点对点的 RPC 协议的具体实现外，还应包括服务的发现与注销、提供服务的多台 Server 的负载均衡、服务的高可用等更多的功能。 目前的 RPC 框架大致有两种不同的侧重方向
- 一种偏重于服务治理
- 另一种偏重于跨语言调用
gRPC是Google开发的高性能、通用的开源RPC框架，其由Google主要面向移动应用开发并基于HTTP/2协议标准而设计，基于ProtoBuf(Protocol Buffers) 序列化协议开发，且支持跨语言开发， 没有提供服务治理方面功能，所以要实现一个综合的产品级的分布式RPC平台还需要扩展开发，Google内部使用的也不是gRPC,而是Stubby
thrift是Apache的一个跨语言的高性能的服务框架，类似 gRPC, 支持跨语言，不支持服务治理
rpcx 是一个分布式的Go语言的 RPC 框架，支持Zookepper、etcd、consul多种服务发现方式，多种服务路由方式
RPC 与 RESTFUL
RPC 的消息传输可以通过 TCP、UDP 或者 HTTP等，RPC 通过 HTTP 传输消息的时候和 RESTful的架构差不多，但也有差别：
- RPC的客户端和服务器端是紧耦合的，客户端需要知道调用方法的名字，参数类型，顺序等，而RESTful基于 http的语义操作资源，参数的顺序一般没有关系，也很容易的通过代理转换链接和资源位置
- RPC 操作的是方法和过程，RESTful 操作的是资源(resource)
- RESTful执行的是对资源的操作，增加、查找、修改和删除等,如果要实现特定需求的操作，例如在所有名字姓李的学生语文成绩上减10分，RESTful的API设计起来就不直观, 那么通过RPC的实现更有意义，因为可以设计一个方法
Student.Increment(Name, Score)供客户端调用
总结
今天浅谈了Go与RPC(一)，这章只是引出了RPC的相关概念，接下来会继续深入了解RPC的相关知识，对于一个涉世未深的我来说，还有许多地方需要学习，有错误的地方欢迎大家指出，共同进步！！
