RPC(remote procedure call)即远程过程调用，在分布式越来越普及的现在，许多系统都用到了RPC服务，他们有的基于thrift，有的基于dubbo，有的基于webservice，那么到底什么是RPC呢？不同的RPC框架又有什么区别呢？
什么是RPC?
首先我们要有分布式的概念，用到RPC的系统通常不是单机的，比如你做的是一个电商平台系统，你可能会有一个订单服务的集群，一个商品服务的集群。订单服务提供订单查询接口，订单明细接口等，而订单明细需要展示商品的数据，显然，订单服务里是查询不到商品的数据，这个时候订单服务就需要调用商品服务的接口，而订单服务调用商品服务的接口这个过程即是远程过程过程调用。将一个远程的方法像本地方法一样调用，即远程过程调用。
RPC的流程
RPC服务调用流程
如图所示，一个RPC服务有客户端，和服务端之分，客户端调用服务端暴露的RPC服务，发起请求，而服务端则负责提供服务，接受客户端传入的参数，将结果返回给客户端。
client发起一个请求，首先会委托给代理Proxy，将调用的信息封装好交给Invoker去执行，Invoker通过Connector与服务端进行通信，当然通信前，会将要传输的对象信息根据协议进行序列化。服务端接收器Acceptor收到客户端发来的请求后，首先根据协议进行解码，然后将客户端的调用信息传给processor进行处理，最后调用invoke执行调用的方法，并且返回相应的结果给客户端。
几个值得思考的问题
了解了流程之后，我们可能对RPC的大致流程有了一定了解，但是整个流程中还有一些问题值得我们深入思考。
1.序列化的方法
我们在程序里调用本地方法的时候，是将相应参数压到栈底，然后让让函数自己读取，但是我们使用RPC服务调用远程方法的时候，则一定要有一个序列化的过程，因为客户端与服务端是用流进行通信，甚至客户端和服务端可能是基于不同语言实现的（例如，客户端使用的java，服务端使用的python），我们需要先将客户端所需传递的参数序列化成字节流，然后传给服务端，服务端再进行反序列化，进行读取。
常见的序列化方式有
（1）json／xml:可读性，扩展性较强，但是压缩效率及解析效率低。对性能要求高时不适用。
（2）thrift:支持二进制传输，支持json序列化，支持多种语言。二进制相对json／xml效率较高，但同时也带来了可读性较差的缺点。
（3）protobuf:序列化层面上和thrift一样，支持二进制，支持json等多种数据格式，以及多种语言，不过protobuf的底层通信需要自己实现，而没有thrift的支持更全面。
2.异常处理
调用RPC服务的时候和本地对异常处理的方式可能会更加复杂，因为异常的原因可能会更多。既有可能是业务层面的异常，也有可能是网络原因导致的通信异常，所以对于不同类型的异常，我们应该定义为不同的异常类，做好区分。
假设，我们定义业务异常为BizException，网络异常为TException，由于RPC服务可能设计比较长的调用链，我们可能因为一次操作，抛出了TException，但无法定位具体是哪个服务抛出了异常。所以针对不同的业务逻辑，对RPC调用可能的异常，做好更详细的说明，能在异常被抛出的时候让我们更快地定位异常原因。
基于thrift的RPC服务代码demo
首先我们基于IDL定义thrift文件
thrift数据结构比较简单，有其他语言基础的话，稍微了解，即可以根据接口定义出对应的thrift文件ThriftDemo.thrift
定义的thrift文件
定义好了thrift文件之后，我们可以使用thrift命令生成对应的java文件（需要先安装thrift-0.9.2.exe）
thrift-0.9.2.exe -r -gen java ThriftDemo.thrift
接下来我们即可以根据thrift接口，写出我们自定义接口的具体实现，我们需要实现DemoTest.Iface接口
具体实现类ThriftDemoServiceImpl
最后，我们可以在本地写个server和client进行测试。
server端：
为了测试简单，采用的nio，二进制协议书写的一个简单的server的demo
自定义server端实现
client端的实现
包括我们平时在服务端开发时，也可以自己写一个client端，来对自己的thrift服务进行一个简单的测试。
自定义客户端实现
总结
最后，RPC服务为我们在分布式服务中互相调用提供了很多便利，但是我们在使用RPC的同时，也会遇到他给我们带来的很多问题，我们必须根据自己服务特点，探索我们开发过程中选用哪种框架，需要注意哪些问题，让我们的服务更稳定。
网友评论