浅谈rpc之通过实例剖析rpc原理

1.什么是RPC

RPC（Remote Procedure Call Protocol）远程过程调用协议，它是一种通过网络从远程计算机程序上请求服务，而不需要了解底层网络技术的协议。RPC协议假定某些传输协议的存在，如TCP或UDP，为通信程序之间携带信息数据。在OSI网络通信模型中，RPC跨越了传输层和应用层，RPC使得开发包括网络分布式多程序在内的应用程序更加容易。

RPC采用C/S模式，请求程序就是要给客户机，而服务提供程序就是一个服务器。首先，客户机调用进程发送一个有进程参数的调用信息到服务进程，然后等待应答信息。在服务端，进程保持睡眠状态直到调用信息到达为止。当一个调用信息到达，服务器获得进程参数，计算结果，发送答复信息。然后等待下一个调用信息，最后，客户端调用进程接收答复信息，获得进程结果，然后调用执行继续进行。

WebService和Socket都是一种RPC。

好了，上面这些当然不是我要说的重点，因为百度一搜都能搜到，接下来我要通过一个案例来简单明了的阐述一下rpc的工作原理，请大家耐着性子读下去吧！

2.RPC框架设计思路

有这样一段代码:

@Autowired

OrderService os;

os.createOrder();

写过spring的朋友看到这段都会想，这里就是注入了一个service，然后调service的方法而已，很简单。但是这是在service也在同一个服务器的前提下的。现在情况变了。我们的app开发和appservice开发在不同的服务器上，这时候如果app开发人员想这么调用，那么appservice的程序员就必须要在service上加@RpcService注解。那么，这个注解是如何实现两台服务器远程调用的呢。

我们知道，我们在启动项目时，spring首先会扫描注解，这样，所有的service服务只要加了@RpcService注解的都会被扫描到。这时我们需要一个HashMap来存储接口名和对应的实现类对象obj。这时候spring会通过它的机制启动服务器SocketService，它提供了一个接口接受app开发端发送过来的调用请求，这个请求包括需要调用的接口名，方法名以及参数名，SocketServer通过反射机制在HashMap中找到对应的实现类对象，然后将其返回给app开发端，app端就调用到了想要调用的接口。

我们在回到开头，我们的app端实际上用到了动态代理。

proxy=Proxy.createProxy(classLoader.接口)，这时程序员写的是OrderService类，所以proxy=OrderService;实际orderService.createOrder() 是 proxy.createOrder()。此时该方法会被invoke(proxy.method.args)阻塞,这时候我们已经拿到了接口,method和args，再将他们封装成request请求放入socket中，由socket发送到socketServer中请求调用。

最后还有一个问题，就是在请求时app端是如何知道服务器的地址的？这时需要zookeeper，在appservice生成HashMap时将接口和服务器地址注册到zookeeper中。客户端在封装request请求的时候只需要从zookeeper中根据接口名取服务器地址就可以了。

这就是RPC的原理，在上层（APP开发人员和APPService开发人员）看起来很简单，只是一方写业务，另一方写Service并加上Rpc注解。但是在底层确有着庞大的工作量！

关于SocketServer，如果有传统的socket，效率非常低，就会变成一个低性能服务器，因此需要引入netty（NIO）。（下回再谈）