NettyRemotingServer是RocketMQ中Netty服务器的实现，封装了与Netty相关的组件。如服务端启动器、事件循环组、通道处理器及其执行器组。Nameserver和broker都会依赖该组件来实现网络通信和事件处理。本文就来分析一下该组件的实现原理。
在RocketMQ中，nameserver会负责管理broker和消息主题。本文会分析RocketMQ中nameserver的创建和启动过程。
在RocketMQ中，broker提供消息存储服务。生产者生成消息和消费者消费消息都要与broker进行交互。本文先来分析一下broker的创建和启动过程。
在前面介绍创建过程时，讲到会创建Netty客户端、以及一些其他服务。那么在启动过程中，就要启动该客户端和这些服务，包括消息拉取、再均衡、消息推送服务；除此以外，还要启动一些定时任务，比如发送心跳给broker。本文就来分析一下具体的实现过程。
MQClientInstance是RocketMQ中客户端实现，生产者和消费者都要依靠它。它内部封装了Netty客户端，实现了nameserver和broker交互的底层细节，为上层应用提供了统一的接口。本文就来分析一下该客户端的创建过程。
在RocketMQ中，支持两种消息消费模式，即PULL（拉模式）和PUSH（推模式），PUSH模式的效果类似broker将消息推送到消费者客户端，不过这是一种伪推送，是基于对PULL模式的封装来实现的。本文先来梳理一下消费者的创建和启动过程，从而能够更好理解消息的拉取过程。
"一切皆文件"是Linux的设计哲学，在网络编程中也不例外。不管是在服务端还是在客户端，都会调用socket系统调用来创建一个socket虚拟文件，该系统调用返回该文件的fd，后续的操作都会基于该fd。本文就来分析一下在socket系统调用的底层做了哪些事情。
Spring Cloud Gateway是基于Spring WebFlux的，使用了ReactorNetty框架和Netty作为底层服务器的实现。Spring Cloud Gateway和WebFlux的关联点在RoutePredicateHandlerMapping，DispatcherHandler会调用它来获取handler方法。本文就以此为入口点来分析Spring Cloud Gateway的请求处理流程。
在Spring Boot中HttpHandler的创建过程一文中，介绍到在WebFluxConfigurationSupport类中会向bean工厂中注册DispatcherHandler类型的bean。在创建后Spring会对该bean进行初始化，以满足处理请求的需要。本文就来分析一下初始化过程中做了哪些事情。