《从0到1学习Netty》-Netty RPC

RPC，即 Remote Procedure Call(远程过程调用)，调用远程计算机上的服务，就像调用本地服务一 样。RPC 可以很好的解耦系统，如 WebService 就是一种基于 Http 协议的 RPC。这个 RPC 整体框架 如下

关键技术：
1、服务发布与订阅:服务端使用 Zookeeper 注册服务地址，客户端从 Zookeeper 获取可用的服务 地址。

2、通信:使用 Netty 作为通信框架。

3、Spring:使用 Spring 配置服务，加载 Bean，扫描注解。

4、动态代理:客户端使用代理模式透明化服务调用。

5、消息编解码:使用 Protostuff 序列化和反序列化消息。

核心流程：
1、服务消费方(client)调用以本地调用方式调用服务

2、client stub 接收到调用后负责将方法、参数等组装成能够进行网络传输的消息体;

3、client stub 找到服务地址，并将消息发送到服务端;

4、server stub 收到消息后进行解码;

5、server stub 根据解码结果调用本地的服务;

6、本地服务执行并将结果返回给 server stub;

7、server stub 将返回结果打包成消息并发送至消费方;

8、client stub 接收到消息，并进行解码;

9、服务消费方得到最终结果。

客户端的请求消息结构一般需要包括以下内容:
1、接口名称:在我们的例子里接口名是“HelloWorldService”，如果不传，服务端就不知道调用哪 个接口了;

2、方法名:一个接口内可能有很多方法，如果不传方法名服务端也就不知道调用哪个方法;

3、参数类型和参数值:参数类型有很多，比如有 bool、int、long、double、string、map、list， 甚至如 struct(class);以及相应的参数值;

4、超时时间:

5、requestID，标识唯一请求 id，在下面一节会详细描述 requestID 的用处。

6、服务端返回的消息 : 一般包括以下内容。返回值+状态 code+requestID

目前互联网公司广泛使用 Protobuf、Thrift、Avro 等成熟的序列化解决方案来搭建 RPC 框架，这 些都是久经考验的解决方案。

通讯流程
requestID 生成-AtomicLong

client 线程每次通过 socket 调用一次远程接口前，生成一个唯一的 ID，即 requestID (requestID 必需保证在一个 Socket 连接里面是唯一的)，一般常常使用 AtomicLong 从 0 开始累计数字生成唯一 ID; 存放回调对象 callback 到全局 ConcurrentHashMap
将处理结果的回调对象 callback，存放到全局 ConcurrentHashMap 里面 put(requestID, callback); synchronized 获取回调对象 callback 的锁并自旋 wait
当线程调用 channel.writeAndFlush()发送消息后，紧接着执行 callback 的 get()方法试 图获取远程返回的结果。在 get()内部，则使用 synchronized 获取回调对象 callback 的 锁，再先检测是否已经获取到结果，如果没有，然后调用 callback 的 wait()方法，释放 callback 上的锁，让当前线程处于等待状态。
服务端接收到请求并处理后，将 response 结果(此结果中包含了前面的 requestID)发 送给客户端，客户端 socket 连接上专门监听消息的线程收到消息，分析结果，取到 requestID，再从前面的 ConcurrentHashMap 里面 get(requestID)，从而找到 callback 对象，再用 synchronized 获取 callback 上的锁，将方法调用结果设置到 callback 对象里，再调用 callback.notifyAll()唤醒前面处于等待状态的线程。