RPC 原理概述
踏入公司尤其是大型互联网公司就会发现，公司的系统都由成千上万大大小小的服务组成，各服务部署在不同的机器上，由不同的团队负责。这时就会遇到两个问题：
1）要搭建一个新服务，免不了需要依赖他人的服务，而现在他人的服务都在远端，怎么调用？
2）其它团队要使用我们的服务，我们的服务该怎么发布以便他人调用？下文我们将对这两个问题展开探讨。
1 如何调用他人的远程服务？
由于各服务部署在不同机器，服务间的调用免不了网络通信过程，服务消费方每调用一个服务都要写一坨网络通信相关的代码，不仅复杂而且极易出错。
如果有一种方式能让我们像调用本地服务一样调用远程服务，而让调用者对网络通信这些细节透明，那么将大大提高生产力，比如服务消费方在执行helloWorldService.sayHello(“test”)时，实质上调用的是远端的服务。这种方式其实就是RPC（Remote Procedure Call Protocol），在各大互联网公司中被广泛使用，如阿里巴巴的hsf、dubbo（开源）、Facebook的thrift（开源）、Google grpc（开源）、Twitter的finagle等。
要让网络通信细节对使用者透明，我们自然需要对通信细节进行封装，我们先看下一个RPC调用的流程：
RPC的目标就是要2~8这些步骤都封装起来，让用户对这些细节透明。
1.2 怎么对消息进行编码和解码？
1.2.1 确定消息数据结构
上节讲了invoke里需要封装通信细节，而通信的第一步就是要确定客户端和服务端相互通信的消息结构。客户端的请求消息结构一般需要包括以下内容：
1）接口名称
在我们的例子里接口名是“HelloWorldService”，如果不传，服务端就不知道调用哪个接口了；
2）方法名
一个接口内可能有很多方法，如果不传方法名服务端也就不知道调用哪个方法；
3）参数类型&参数值
参数类型有很多，比如有bool、int、long、double、string、map、list，甚至如struct（class）；
以及相应的参数值；
4）超时时间
5）requestID，标识唯一请求id，在下面一节会详细描述requestID的用处。
同理服务端返回的消息结构一般包括以下内容。
1）返回值
2）状态code
3）requestID
1.2.2 序列化
一旦确定了消息的数据结构后，下一步就是要考虑序列化与反序列化了。
什么是序列化？序列化就是将数据结构或对象转换成二进制串的过程，也就是编码的过程。
什么是反序列化？将在序列化过程中所生成的二进制串转换成数据结构或者对象的过程。
为什么需要序列化？转换为二进制串后才好进行网络传输嘛！为什么需要反序列化？将二进制转换为对象才好进行后续处理！
现如今序列化的方案越来越多，每种序列化方案都有优点和缺点，它们在设计之初有自己独特的应用场景，那到底选择哪种呢？从RPC的角度上看，主要看三点：
1）通用性，比如是否能支持Map等复杂的数据结构；
2）性能，包括时间复杂度和空间复杂度，由于RPC框架将会被公司几乎所有服务使用，如果序列化上能节约一点时间，对整个公司的收益都将非常可观，同理如果序列化上能节约一点内存，网络带宽也能省下不少；
3）可扩展性，对互联网公司而言，业务变化快，如果序列化协议具有良好的可扩展性，支持自动增加新的业务字段，删除老的字段，而不影响老的服务，这将大大提供系统的健壮性。
目前国内各大互联网公司广泛使用hessian、protobuf、thrift、avro等成熟的序列化解决方案来搭建RPC框架，这些都是久经考验的解决方案。
1）要搭建一个新服务，免不了需要依赖他人的服务，而现在他人的服务都在远端，怎么调用？
2）其它团队要使用我们的服务，我们的服务该怎么发布以便他人调用？下文我们将对这两个问题展开探讨。
1 如何调用他人的远程服务？
由于各服务部署在不同机器，服务间的调用免不了网络通信过程，服务消费方每调用一个服务都要写一坨网络通信相关的代码，不仅复杂而且极易出错。
如果有一种方式能让我们像调用本地服务一样调用远程服务，而让调用者对网络通信这些细节透明，那么将大大提高生产力，比如服务消费方在执行helloWorldService.sayHello(“test”)时，实质上调用的是远端的服务。这种方式其实就是RPC（Remote Procedure Call Protocol），在各大互联网公司中被广泛使用，如阿里巴巴的hsf、dubbo（开源）、Facebook的thrift（开源）、Google grpc（开源）、Twitter的finagle等。
要让网络通信细节对使用者透明，我们自然需要对通信细节进行封装，我们先看下一个RPC调用的流程：
1）服务消费方（client）调用以本地调用方式调用服务；
2）client stub接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体；
3）client stub找到服务地址，并将消息发送到服务端；
4）server stub收到消息后进行解码；
5）server stub根据解码结果调用本地的服务；
6）本地服务执行并将结果返回给server stub；
7）server stub将返回结果打包成消息并发送至消费方；
8）client stub接收到消息，并进行解码；
9）服务消费方得到最终结果。
RPC的目标就是要2~8这些步骤都封装起来，让用户对这些细节透明。
1.2 怎么对消息进行编码和解码？
1.2.1 确定消息数据结构
上节讲了invoke里需要封装通信细节，而通信的第一步就是要确定客户端和服务端相互通信的消息结构。客户端的请求消息结构一般需要包括以下内容：
1）接口名称
在我们的例子里接口名是“HelloWorldService”，如果不传，服务端就不知道调用哪个接口了；
2）方法名
一个接口内可能有很多方法，如果不传方法名服务端也就不知道调用哪个方法；
3）参数类型&参数值
参数类型有很多，比如有bool、int、long、double、string、map、list，甚至如struct（class）；
以及相应的参数值；
4）超时时间
5）requestID，标识唯一请求id，在下面一节会详细描述requestID的用处。
同理服务端返回的消息结构一般包括以下内容。
1）返回值
2）状态code
3）requestID
1.2.2 序列化
一旦确定了消息的数据结构后，下一步就是要考虑序列化与反序列化了。
什么是序列化？序列化就是将数据结构或对象转换成二进制串的过程，也就是编码的过程。
什么是反序列化？将在序列化过程中所生成的二进制串转换成数据结构或者对象的过程。
为什么需要序列化？转换为二进制串后才好进行网络传输嘛！为什么需要反序列化？将二进制转换为对象才好进行后续处理！
现如今序列化的方案越来越多，每种序列化方案都有优点和缺点，它们在设计之初有自己独特的应用场景，那到底选择哪种呢？从RPC的角度上看，主要看三点：
1）通用性，比如是否能支持Map等复杂的数据结构；
2）性能，包括时间复杂度和空间复杂度，由于RPC框架将会被公司几乎所有服务使用，如果序列化上能节约一点时间，对整个公司的收益都将非常可观，同理如果序列化上能节约一点内存，网络带宽也能省下不少；
3）可扩展性，对互联网公司而言，业务变化快，如果序列化协议具有良好的可扩展性，支持自动增加新的业务字段，删除老的字段，而不影响老的服务，这将大大提供系统的健壮性。
目前国内各大互联网公司广泛使用hessian、protobuf、thrift、avro等成熟的序列化解决方案来搭建RPC框架，这些都是久经考验的解决方案。
