rpc通信原理浅析
rpc(remote procedure call)，即远程过程调用，广泛用于分布式或是异构环境下的通信，数据格式一般采取protobuf。
protobuf（protocol buffer）是google 的一种数据交换的格式，它独立于平台语言。
google 提供了protobuf多种语言的实现：java、c#、c++、go 和 python，每一种实现都包含了相应语言的编译器以及库文件。
由于它是一种二进制的格式，比使用 xml（20倍） 、json（10倍）进行数据交换快许多。可以把它用于分布式应用之间的数据通信或者异构环境下的数据交换。作为一种效率和兼容性都很优秀的二进制数据传输格式，可以用于诸如网络传输、配置文件、数据存储等诸多领域。
protobuf比json、xml块是毋庸置疑的，一方面前者是二进制存储，后两者是纯文本存储且还需要存取一些额外的数据信息，例如xml需要存取标签、json需要存取key-vale。
上一节说到，分布式环境下不同服务器上的节点，想要完成服务的互相调用离不开rpc远程调用，这里简单分析一下调用过程。
step1：local调用一个service，即一个method，该method有方法名、方法的参数以及返回值，首先如何知道这个服务在哪个分布式节点上？这就要实现服务注册和服务发现(例如zookeeper)，分布式各节点先将自身拥有的一些服务注册到服务中心，那么local调用某个服务的时候，就先去服务中心去找这个注册的服务在哪台节点上注册的，找到这个节点后，那么说明我要通过该结点返回这个服务所执行的结果。
step2：拥有该服务的分布式节点如何知道调用者需要哪个服务？显然local需要自己将要调用的服务的一些标识信息(方法名、参数、返回值)通过网络传输给该结点，这里local采取protobuf来序列化服务的标识信息，然后通过网络发送给对端。
step3：拥有该服务的节点，接收到local发送过来的数据之后，需要反序列化出服务的标识信息，这样才知道需要调用哪个服务，调用完成之后得到该服务的结果，那么和调用的过程类似，先将这个结果序列化，然后发送给对端，当然如果该服务没有调用成功，那么可以序列化错误信息返回，表示调用失败。
step4：local端接收到服务调用的结果，同样采取反序列化的方式得到需要的结果，local再根据结果做下一步操作或是返回错误，整个rpc调用过程结束。
黄色部分：设计rpc方法参数的打包和解析，也就是数据的序列化和反序列化，使用Protobuf。
绿色部分：网络部分，包括寻找rpc服务主机，发起rpc调用请求和响应rpc调用结果。
