1.技术要点
rpc_1">1.1 rpc协议
netty_4">1.2 netty粘包半包处理
由于数据传说使用tcp协议，rpc协议的数据在网络传输过程中会产生三种情况：
1）刚好是完整的一条rpc协议数据
2）不止一条rpc协议的数据（粘包）
3）不够一条rpc协议的数据（半包）
针对这些可能发生粘包核半包情况，netty提供了很多解码器，这里使用：
LengthFieldBasedFrameDecoder
这个解码器是基于长度的帧解码器，需要定义最大的帧有多少字节（自定义的rpc协议的数据包最大长度不能超过帧的大小，否则就会抛出异常），只要数据长度不超过最大帧数据，就会按照实际长度进行解码。
下面来看看为什么LengthFieldBasedFrameDecoder能够解决粘包或者半包
rpc4_14">假设rpc协议的数据，长度用4个字节表示。（半包情况）
1）接收到的数据首先会进入到系统的缓冲区中，当读取长度的时候，缓存区数据不够四个字节，就等待够四个字节了在读取，这样就保证先读取到数据长度，假设读取到的长度值是512，表示内容的部分有512个字节。
2）当拿到长度以后，就要读取内容部分了，当缓冲区的数据不够512字节的时候，就等够512个字节以后，就读取512个字节，多余的部分会进行下一个解码。。
rpc4_17">假设rpc协议的数据，长度用4个字节表示。（粘包情况）
1）先读取到数据长度，假设读取到的长度值是512，表示内容的数据有512个字节。
2）当拿到长度以后，就要读取内容部分了，这里只会读取512个字节，多余的部分会进行下一个解码。
rpcjavajava_21">这样长度的4个字节的数据+内容的512个字节的数据=516个字节的rpc协议数据就接收完成了，然后通过后续的解码器解码成对应的java对象，可以在代码中使用这样java对象进行后续业务操作。
1.3 动态代理
在rpc的客户端，能够获取service的代理对象，这个代理对象，内部通过netty封装网络请求，rpc协议的数据编解码。
1.4 整体流程
客户端请求注册中心找到某个服务接口的地址列表，然后从地址列表中选一个地址（这个过程也叫负载均衡）；
然后通过实现InvocationHandler的invoke方法，在invoke方法里面里面会把接口名、方法参数、方法参数类型等信息封装成一个java请求对象，这个java请求对象在客户端经过一系列的编码器编码成rpc协议（字节数据）发送给服务端；
服务端接收到rpc协议数据以后，经过一系列解码器把rpc协议数据解码成java请求对象，然后进行后续业务操作，生成java响应对象；
服务端把java响应对象通过一系列编码器编码成rpc协议数据发送给客户端，客户端经过一些列解码器变成java响应对象。
2.项目结构
2.1 公共部分
service （服务接口）
register (注册中心)
protocol (rpc协议)
context （rpc上下文）
codec (rpc调用编解码)
2.2 服务端
server
2.3 客户端
client
总结
通过netty实现rpc服务，需要定义rpc协议，用来客户端和服务端数据交互，服务端通过监听端口，客户端tcp连接服务端，然后发送和接收数据，这个数据交互的过程，需要把数据序按照rpc协议的格式进行编解码，客户端通过动态代码封装网络请求，产生接口的代理对象。
