关于RPC的一些感想

RPC 是在开发过程中一个司空见惯的词，任何接口设计都要考虑到是否符合RPC的规范，但是一直对RPC对概念理解不是很深刻，只有一些比较直观的理解（这也是一个思维的习惯，有好有坏）。下面说一下自己对RPC的理解，然后在结合在找到的一些文章对RPC的讲解说一说体会。

目前我们的项目中，虽然协议采用的是Profobuf，制定协议时默认会按照 RPC 的惯例。例如：

@ServiceName=foo_svr
@L5=123:4324
RpcService{
    rpc  invokeSomeMethod(ReqBody)returns(RspBody);
}

ServiceName标识了这个服务的名称。
L5是公司的路由服务，提供了服务的路由、负载均衡、容错等能力。
RpcService中则具体定义了服务中提供了那些命令字。
乍一看，很清晰，命令子、入参出参都已经定义ok，以及服务的发现等。但是我们使用的非常丑陋。通常是通过一个静态类作为一个统一的入口来执行服务的调用。例如：
ClientApis.invoke(“serviceName”,”method”,params);

这种方式已经违反了RPC最基础的一点，也是我直观认为的。
调用一个RPC方法，应该像调用一个本地方法一样。
RPC之所以被推崇，是因为它这种理念可以让使用者不关心实现的细节，是面向接口的一种变成方式。
除了这一点外，其余的就是你实现者要做的事情了，例如：接口实现的具体操作、和后端的通信问题、服务路由等。
这里我们实现的采用的是字节码动态生成的形式。既然是面向接口编程了，那么我们要动态生成的则是接口的实现。通常来说只是一些把请求包按照协议组织起来，统一网络发包收包，然后再返回。
再一个重要的部分就是
服务发现与路由
公司L5的组件就是通过一对整数：（modid：123，cmdid：324）来标识唯一的一个服务，业务方通过这对整数可以获取到服务上线的服务器IP以及端口，获取都是动态的，同时这对数字和服务器之间的关系是可以动态配置的。

以上就是个人对RPC粗略的理解，下面列出两篇文章，觉得写的非常的得体而且很生动。

来自知乎，通俗的理解RPC
总结，RPC三要素：

1. Call ID的映射。
   也就是Client调用的方法如何和远端（Server）调用的方法映射起来，通常协议里定义方法field，Server端收到后能够辨识就可以。

2. 序列与反序列
   由于请求是要经过网络的，序列就是为了能在网络上传输，反序列即为收到回包后如何转换成你可以处理的对象。

3. 网络传输
   也就是采用哪种网络协议，或者网络编程技术，Socket？Http？一些网络框架这方便已经做了很多的封装，例如Netty、Mina。

你应该知道的RPC原理
比较详尽的讲述了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. 服务消费方得到最终结果。

都细节的有点啰嗦了，haha 这个stub不知道作者如何理解的，可以简单理解为一段专门处理这块逻辑的代码。

还有几点重要的问题：
1、如何透明化调用？（也就是让使用者就像调用本地方法一样调用你的服务）。实现有两种：字节码、动态代理（这里本人也尝试过，但是由于使用了Kilim协程，有一些天然的残疾，所以无法用，字节码动态生成的如果有兴趣的可以聊一聊）。
2、消息编解码？我觉得Protobuf真心好用，不用考虑其他的二进制协议了。
3、通信，这块只是传输的问题，Netty挺好用的。不过我也没深入了解其他的。
4、协议中为什么要RequestID，也就是请求的SEQ，这个看文章吧。
5、如何发布服务，文中介绍的是Zookeeper，用的挺多的，例如阿里的Dubbo。

很久没有写文章，感觉工作非常的忙碌，每天一开始上班都在处理各种问题，忙成狗，没有多少时间是自己的，所以萌生了想要自己写文章的想法，给自己一点时间积累沉淀自己，也算一种修行吧。

打算还是按照这样的套路，先写自己理解的、直观的，在写找到的一些觉得分析的不错的文章来看，觉得这样吸收比较好。