javaRPC原理
在学校期间⼤家都写过不少程序，⽐如写个hello world服务类，然后本地调⽤下，如下所⽰。这些程序的特点是服务消费⽅和服务提供⽅是本地调⽤关系。
⽽⼀旦踏⼊公司尤其是⼤型互联⽹公司就会发现，公司的系统都由成千上万⼤⼤⼩⼩的服务组成，各服务部署在不同的机器上，由不同的团队负责。这时就会遇到两个问题：1）要搭建⼀个新服务，免不了需要依赖他⼈的服务，⽽现在他⼈的服务都在远端，怎么调⽤？2）其它团队要使⽤我们的新服务，我们的服务该怎么发布以便他⼈调⽤？下⽂将对这两个问题展开探讨。
1 public interface HelloWorldService {
2 String sayHello(String msg);
3 }
1 public class HelloWorldServiceImpl implements HelloWorldService {
2 @Override
3 public String sayHello(String msg) {
4 String result = "hello world " + msg;
5 System.out.println(result);
6 return result;
7 }
8 }
1 public class Test {
2 public static void main(String[] args) {
3 HelloWorldService helloWorldService = new HelloWorldServiceImpl();
4 helloWorldService.sayHello("test");
5 }
6 }
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.1 怎么做到透明化远程服务调⽤？
怎么封装通信细节才能让⽤户像以本地调⽤⽅式调⽤远程服务呢？对java来说就是使⽤代理！java代理有两种⽅式：1） jdk 动态代理；2）字节码⽣成。尽管字节码⽣成⽅式实现的代理更为强⼤和⾼效，但代码维护不易，⼤部分公司实现RPC框架时还是选择动态代理⽅式。
下⾯简单介绍下动态代理怎么实现我们的需求。我们需要实现RPCProxyClient代理类，代理类的invoke⽅法中封装了与远端服务通信的细节，消费⽅⾸先从RPCProxyClient获得服务提供⽅的接⼝，当执⾏helloWorldService.sayHello("test")⽅法时就会调⽤invoke⽅法。
1 public class RPCProxyClient implements flect.InvocationHandler{
2 private Object obj;
3
4 public RPCProxyClient(Object obj){
5 this.obj=obj;
6 }
7
8 /**
9 * 得到被代理对象;
10 */
11 public static Object getProxy(Object obj){
12 return Class().getClassLoader(),
13 Class().getInterfaces(), new RPCProxyClient(obj));
14 }
15
16 /**
17 * 调⽤此⽅法执⾏
18 */
19 public Object invoke(Object proxy, Method method, Object[] args)
20 throws Throwable {
21 //结果参数;
22 Object result = new Object();
23 // ...执⾏通信相关逻辑
24 // ...
25 return result;
26 }
27 }
1 public class Test {
2 public static void main(String[] args) {
3 HelloWorldService helloWorldService = (Proxy(HelloWorldService.class);
4 helloWorldService.sayHello("test");
5 }
6 }
1.2 怎么对消息进⾏编码和解码？
1.2.1 确定消息数据结构
上节讲了invoke⾥需要封装通信细节，⽽通信的第⼀步就是要确定客户端和服务端相互通信的消息结构。客户端的请求消息结构⼀般需要包括以下内容：
java dubbo1）接⼝名称
在我们的例⼦⾥接⼝名是“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）可扩展性，对互联⽹公司⽽⾔，业务变化飞快，如果序列化协议具有良好的可扩展性，⽀持⾃动增加新的业务字段，⽽不影响⽼的服务，这将⼤⼤提供系统的灵活度。
⽬前互联⽹公司⼴泛使⽤Protobuf、Thrift、Avro等成熟的序列化解决⽅案来搭建RPC框架，这些都是久经考验的解决⽅案。
1.3 通信
消息数据结构被序列化为⼆进制串后，下⼀步就要进⾏⽹络通信了。⽬前有两种常⽤IO通信模型：1）BIO；2）NIO。⼀般RPC框架需要⽀持这两种IO模型，原理可参考：。
如何实现RPC的IO通信框架呢？1）使⽤java nio⽅式⾃研，这种⽅式较为复杂，⽽且很有可能出现隐
藏bug，但也见过⼀些互联⽹公司使⽤这种⽅式；2）基于mina，mina在早⼏年⽐较⽕热，不过这些年版本更新缓慢；3）基于netty，现在很多RPC框架都直接基于netty这⼀IO通信框架，省⼒⼜省⼼，⽐如阿⾥巴巴的HSF、dubbo，Twitter的finagle等。
1.4 消息⾥为什么要有requestID？
如果使⽤netty的话，⼀般会⽤channel.writeAndFlush()⽅法来发送消息⼆进制串，这个⽅法调⽤后对于整个远程调⽤(从发出请求到接收到结果)来说是⼀个异步的，即对于当前线程来说，将请求发送出来后，线程就可以往后执⾏了，⾄于服务端的结果，是服务端处理完成后，再以消息的形式发送给客户端的。于是这⾥出现以下两个问题：
1）怎么让当前线程“暂停”，等结果回来后，再向后执⾏？
2）如果有多个线程同时进⾏远程⽅法调⽤，这时建⽴在client server之间的socket连接上会有很多双⽅发送的消息传递，前后顺序也可能是随机的，server处理完结果后，将结果消息发送给client，client收到很多消息，怎么知道哪个消息结果是原先哪个线程调⽤的？
如下图所⽰，线程A和线程B同时向client socket发送请求requestA和requestB，socket先后将requestB和requestA发送⾄server，⽽server可能将responseA先返回，尽管requestA请求到达时间更晚。我们需要⼀种机制保证responseA丢给ThreadA，responseB丢给ThreadB。
怎么解决呢？
1）client线程每次通过socket调⽤⼀次远程接⼝前，⽣成⼀个唯⼀的ID，即requestID（requestID必需保证在⼀个Socket连接⾥⾯是唯⼀的），⼀般常常使⽤AtomicLong从0开始累计数字⽣成唯⼀ID；
2）将处理结果的回调对象callback，存放到全局ConcurrentHashMap⾥⾯put(requestID, callback)；
3）当线程调⽤channel.writeAndFlush()发送消息后，紧接着执⾏callback的get()⽅法试图获取远程返回的结果。在get()内部，则使⽤synchronized获取回调对象callback的锁，再先检测是否已经获取到结果，如果没有，然后调⽤callback的wait()⽅法，释放callback上的锁，让当前线程处于等待状态。
4）服务端接收到请求并处理后，将response结果（此结果中包含了前⾯的requestID）发送给客户端，客户端socket连接上专门监听消息的线程收到消息，分析结果，取到requestID，再从前⾯的Concurrent
HashMap⾥⾯get(requestID)，从⽽到callback对象，再⽤synchronized获取callback上的锁，将⽅法调⽤结果设置到callback对象⾥，再调⽤ifyAll()唤醒前⾯处于等待状态的线程。
1 public Object get() {
2 synchronized (this) { // 旋锁
3 while (!isDone) { // 是否有结果了
4 wait(); //没结果是释放锁，让当前线程处于等待状态
5 }
6 }
7 }
1 private void setDone(Response res) {
2 s = res;
3 isDone = true;
4 synchronized (this) { //获取锁，因为前⾯wait()已经释放了callback的锁了
5 notifyAll(); // 唤醒处于等待的线程
6 }
7 }
2 如何发布⾃⼰的服务？
如何让别⼈使⽤我们的服务呢？有同学说很简单嘛，告诉使⽤者服务的IP以及端⼝就可以了啊。确实是这样，这⾥问题的关键在于是⾃动告知还是⼈⾁告知。
⼈⾁告知的⽅式：如果你发现你的服务⼀台机器不够，要再添加⼀台，这个时候就要告诉调⽤者我现在有两个ip了，你们要轮询调⽤来实现负载均衡；调⽤者咬咬⽛改了，结果某天⼀台机器挂了，调⽤者发现服务有⼀半不可⽤，他⼜只能⼿动修改代码来删除挂掉那台机器的ip。现实⽣产环境当然不会使⽤⼈⾁⽅式。
有没有⼀种⽅法能实现⾃动告知，即机器的增添、剔除对调⽤⽅透明，调⽤者不再需要写死服务提供⽅地址？当然可以，现如今zookeeper被⼴泛⽤于实现服务⾃动注册与发现功能！
简单来讲，zookeeper可以充当⼀个服务注册表（Service Registry），让多个服务提供者形成⼀个集，让服务消费者通过服务注册表获取具体的服务访问地址（ip+端⼝）去访问具体的服务提供者。如下图所⽰：
具体来说，zookeeper就是个分布式⽂件系统，每当⼀个服务提供者部署后都要将⾃⼰的服务注册到zookeeper的某⼀路径
上: /{service}/{version}/{ip:port}, ⽐如我们的HelloWorldService部署到两台机器，那么zookeeper上就会创建两条⽬录：分别
为/HelloWorldService/1.0.0/100.19.20.01:16888 /HelloWorldService/1.0.0/100.19.20.02:16888。
zookeeper提供了“⼼跳检测”功能，它会定时向各个服务提供者发送⼀个请求（实际上建⽴的是⼀个 Socket 长连接），如果长期没有响应，服务中⼼就认为该服务提供者已经“挂了”，并将其剔除，⽐如100.19.20.02这台机器如果宕机了，那么zookeeper上的路径就会只
剩/HelloWorldService/1.0.0/100.19.20.01:16888。
服务消费者会去监听相应路径（/HelloWorldService/1.0.0），⼀旦路径上的数据有任务变化（增加或减少），zookeeper都会通知服务消费⽅服务提供者地址列表已经发⽣改变，从⽽进⾏更新。
更为重要的是zookeeper与⽣俱来的容错容灾能⼒（⽐如leader选举），可以确保服务注册表的⾼可⽤性。
3 ⼩结
RPC⼏乎是每⼀个从学校进⼊互联⽹公司的同学都要⾸先学习的框架，之前⾯试过⼀个在⼤型互联⽹
公司⼯作过两年的同学，对RPC 还是停留在使⽤层⾯，这是不应该的，希望⼤家不仅要会⽤⽽且要知道内部的原理。本⽂也仅是对RPC的⼀个⽐较粗糙的描述，希望对⼤家有所帮助，错误之处也请指出修正。
4 ⼀些开源的RPC框架
发表评论