Java是世界上最好的语言

在 基于Netty手写RPC框架进阶版（上）——注解驱动 中，我们搭建好了注解驱动的RPC框架，接下来在本文中我们就来逐步实现注册中心以及动态扩容的功能。1. 注册中心模块接下来我们便来引入注册中心，这里使用zookeeper来实现，首先创建netyy-rpc-registry模块。首先引入zk的相关依赖：<dependencies> <dependency> <groupId>org.apache.curator</

本文代码主要基于 基于Netty手写RPC框架，在他的基础上新增一些复杂的功能。在上一个基础版本里面，我们有很多业务代码还是在生产者和消费者端编码的，这样是不是很不合理？使用过Dubbo的读者们应该都知道会直接使用DubboReference、DubboService等注解来简化操作，不需要在客户端来编写相关的动态代理代码。所以我们首先也为我们的框架添加注解驱动的功能，简化客户端的代码，可以实现直接通过注解的方式来实现远程通信。1. 注解首先我们在框架模块中创建注解，类似与DubboReferen

1. RPC 框架什么是RPC框架？他的全称是remoto proceduer call，他旨在让我们开发者能够像调用本地服务一样调用远程服务。最常见的就是DUBBO框架。举一个栗子：比如在我们的电商系统里面有一个用户服务和商品服务，然后在商品服务中有一个查询商品的接口方法，我们只需要在商品服务中暴露出一个接口，然后将其上传至maven仓库中，这样在我们的用户服务中就可以直接调用了。RPC框架可以让我们不需要去关心网络通信的复杂细节和复杂组成，只需要聚焦业务的处理即可，所以极大降低了我们开发的门

1. 什么是拆包粘包？TCP传输协议是基于数据流传输的，而基于流化的数据是没有界限的，当客户端向服务端发送数据时，可能会把一个完整的数据报文拆分成多个小报文进行发送，也可能将多个报文合并成一个大报文进行发送。在这样的情况下，有可能会出现下图所示的情况：服务端恰巧读到了两个完整的数据包 A 和 B，没有出现拆包/粘包问题；服务端接收到 A 和 B 粘在一起的数据包，服务端需要解析出 A 和 B；服务端收到完整的 A 和 B 的一部分数据包 B-1，服务端需要解析出完整的 A，并等待读取完

1. ByteBuf的创建在Netty中，有一个比较常见的对象ByteBuf，它其实等同于Java Nio中的ByteBuffer，但是ByteBuf对Nio中的ByteBuffer的功能做了很作增强，下面我们来简单了解一下ByteBuf。下面这段代码演示了ByteBuf的创建以及内容的打印，这里显示出了和普通ByteBuffer最大的区别之一，就是ByteBuf可以自动扩容，默认长度是256，如果内容长度超过阈值时，会自动触发扩容。public class ByteBufExample {

在了解Netty之前，我们首先需要对网络IO的发展具有一定的了解。网络IO的发展大致可以分为如下类型：BIONIO多路复用AIOReactor模型单线程单Reactor多线程单Reactor主从多线程Reactor1. 从IO发展了解Netty1.1 同步阻塞IO(BIO)如下图所示，客户端向服务端发起一个数据读取请求，客户端在收到服务端返回数据之前，一直处于阻塞状态，直到服务端返回数据后完成本次会话。这个过程就叫同步阻塞IO，在BIO模型中如果想实现异