Netty

本文是我对Netty的NioEventLoopGroup及NioEventLoop初始化工作的源码阅读笔记, 如下图,是Netty的Reactor线程模型图,本文描述NioEventLoopGroup等价于我在图中标红的MainReactor组件,全篇围绕它的初始化展开,难免地方理解的不正确,欢迎留言 在Nio网络编程模型的图示是下面那张图, 单条Thread全职执行一个Selector,首先是服务端在启动的时候,会把代表服务端的ServerSockerChannel注册进Selector,且感兴趣的事件是Accept, 一旦有客户端请求建立连接,ServerSockerChannel的accept事件就会被Selector感知到,进行下一步处理 对NioEventLoopGroup最感性的认识,是在一定程度上,它其实是对上图组件的封装,那么封装了哪些部分呢? 对Thread的封装 NioEventLoopGroup维护的是事件循环,EventLoop, 在Netty的主从Reactor线程模型中,两个事件循环组其实也是线程组,因为每一个EventLoop在他的整个生命周期中都始终和一条线程唯一绑定,EventLoop的线程使用的是它自己封装的 FastThreadLocalThread , 这条线程使得EventLoop有了处理事件的能力 对Selector的封装

1.Tomcat总体架构 Tomcat有Connector和Container两大核心组件，Connector组件负责网络请求接入，Connector目前支持BIO、NIO、APR三种模式，后续文章会再重点对比下NIO和APR，Tomcat5以后的版本开始支持NIO了；Container组件实现了对servlet的容器管理功能；service服务将Connector和Container又包了一层，包装成外部可以获取的服务；多有service都运行在Tomcat这个大Server服务上，Server有所有service的实例，并实现了LifeCycle接口可以控制所有service的生命周期。 2.Tomcat NIO相关类 Tomcat的NIO实现主要是在Connector组件内，Connector 组件是 Tomcat 中两个核心组件之一，它的主要任务是负责接收浏览器的发过来的 tcp 连接请求，创建一个 Request 和 Response 对象分别用于和请求端交换数据，然后会产生一个线程来处理这个请求并把产生的 Request 和 Response 对象传给处理这个请求的线程，处理这个请求的线程就是 Container 组件要做的事了。 整个Connector组件包含三部分：Http11NioProtocol、Mapper、CoyoteAdapter

本篇文章主要从源码的角度揭秘Spring Cloud Gateway的加载和怎么处理请求流程。 1.Spring Gateway概述 SpringCloudGateway是Spring官方基于Spring 5.0，Spring Boot 2.0和Project Reactor等技术开发的网关，Spring Cloud Gateway旨在为微服务架构提供一种简单而有效的统一的API路由管理方式。Spring Cloud Gateway作为Spring Cloud生态系中的网关，目标是替代Netflix ZUUL，其不仅提供统一的路由方式，并且基于Filter链的方式提供了网关基本的功能，例如：安全，监控/埋点，和限流等。 2.容器启动过程的简单加载分析 加载的流程主要是spring容器为主，需要大家熟悉spring框架，这里不做过多的分析了。 Spring Cloud Gateway自动装配类在 org.springframework.cloud.gateway.config 包下，我们可以看到四个配置类 ： GatewayAutoConfiguration GatewayClassPathWarningAutoConfiguration GatewayLoadBalancerClientAutoConfiguration GatewayRedisAutoConfiguration

demo地址 https://gitee.com/syher/grave-netty RPC介绍 首先了解一下RPC：远程过程调用。简单点说就是本地应用可以调用远程服务器的接口。那么通过什么方式调用远程接口呢？说白了RPC只是一种概念。他的调用可以基于HTTP实现，也可以基于TCP/IP实现。甚至私人定制的通讯协议。 当然，私人定制通讯协议成本过高且不具备通用性。我们不做展开讨论(其实我也展不开。。。)。那为什么不使用HTTP协议呢？受限于HTTP协议层级过高，数据传输效率不如TCP/IP。所以RPC远程调用一般采用TCP/IP实现。即调用socket方法。 RPC实现原理 1. 客户端发起远程服务调用。 2. 客户端将类信息、调用方法和入参信息通过socket通道发送给服务端。 3. 服务端解析数据包，调用本地接口。 5.将执行结果通过socket返回给客户端。 6.客户端拿到并解析返回结果。 RPC实现 java如何实现一个rpc框架，其实就是按照上面的原理再做一些详细的补充。比如通过动态代理封装客户端的数据包、通过反射机制实现服务端实现类的调用等等。 今天，我们先基于spring boot + netty 做rpc服务端的实现。 首先，做一个注解用于标识接口提供rpc调用。 @Target(ElementType.TYPE) @Retention

Spring Boot 2.0 spring.io 官网有句醒目的话是： BUILD ANYTHING WITH SPRING BOOT 复制代码 Spring Boot （Boot 顾名思义，是引导的意思）框架是用于简化 Spring 应用从搭建到开发的过程。应用开箱即用，只要通过一个指令，包括命令行 java -jar 、 SpringApplication 应用启动类 、 Spring Boot Maven 插件等，就可以启动应用了。另外，Spring Boot 强调只需要很少的配置文件，所以在开发生产级 Spring 应用中，让开发变得更加高效和简易。目前，Spring Boot 版本是 2.x 版本。Spring Boot 包括 WebFlux。 Spring Boot 2.0 WebFlux 了解 WebFlux ,首先了解下什么是 Reactive Streams。Reactive Streams 是 JVM 中面向流的库标准和规范： 处理可能无限数量的元素 按顺序处理 组件之间异步传递 强制性非阻塞背压（Backpressure） Backpressure(背压) 背压是一种常用策略，使得发布者拥有无限制的缓冲区存储元素，用于确保发布者发布元素太快时，不会去压制订阅者。 Reactive Streams（响应式流） 一般由以下组成： 发布者：发布元素到订阅者 订阅者

什么是Reactor Netty？ 在开始之前，让我们看一下Reactor Netty是什么以及它与Spring Boot的关系。 Reactor Netty是一个异步事件驱动的网络应用程序框架。它提供非阻塞和背压就绪的TCP，HTTP和UDP客户端和服务器。顾名思义，它基于Netty框架。 现在，让我们看看Spring和Spring Boot的位置。 Spring WebFlux 是Spring框架的一部分，为Web应用程序提供反应式编程支持。如果我们在Spring Boot应用程序中使用WebFlux，Spring Boot会 自动将 Reactor Netty 配置为默认服务器。除此之外，我们可以明确地将Reactor Netty添加到我们的项目中，Spring Boot应该再次自动配置它。 现在，我们将构建一个应用程序来了解如何自定义我们自动配置的Reactor Netty服务器。之后，我们将介绍一些常见的配置方案。 首先，我们将添加所需的Maven依赖项。 要使用Reactor Netty服务器，我们将在我们的pom文件中添加 spring-boot-starter-webflux 作为依赖项： <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter

一、API网关 1.1 Zuul1简介 1.2 Spring Cloud Gateway简介 二、对比 2.0 产品对比 2.1 性能对比 2.1.1 低并发场景 2.1.2 高并发场景 2.1.3 官方性能对比 三、总结 一、API网关   微服务架下，服务之间容易形成网状的调用关系，这种网状的调用关系不便管理和维护，这种场景下API网关应运而生。作为后端服务的入口，API网关在微服务架构中尤其重要，在对外部系统提供API入口的要求下，API网关应具备路由转发、负载均衡、限流熔断、权限控制、轨迹追踪和实时监控等功能。   目前，很多微服务都基于的Spring Cloud生态构建。Spring Cloud生态为我们提供了两种API网关产品，分别是Netflix开源的Zuul1和Spring自己开发的Spring Cloud Gateway（下边简称为Gateway）。Spring Cloud以Finchley版本为分界线，Finchley版本发布之前使用Zuul1作为API网关，之后更推荐使用Gateway。    虽然Netflix已经在2018年5月开源了Zuul2，但是Spring Cloud已经推出了Gateway，并且在github上表示没有集成Zuul2的计划。所以从Spring Cloud发展的趋势来看，Gateway代替Zuul是必然的。 1.1 Zuul1简介  

Netty 值得统计的信息 外在信息 连接统计信息：channelActive / channelInactive 收数据统计：channelRead 发数据统计：write（写到缓存里），用 ctx.write(msg).addListener() 更准确 异常统计：exceptionCaught / ChannelFuture 内在信息 线程数：根据不同实现计算，比如：nioEventLoopGroup.executorCount()； 待处理任务：executor.pendingTask()； 积累的数据：channelOutBoundBuffer.totalPendingSize，这是 Channel 级别的； 可写状态切换：channelWritabilityChanged； 触发事件统计：userEventTriggered，比如 IdleStateEvent； ByteBuf 分配细节：Pooled/UnpooledByteAllocator.DEFAULT.metric()； ———————————————— https://blog.csdn.net/weixin_33669968/java/article/details/104552393 https://community.jboss.org/wiki/Netty4AndJMXIntegration

（大佬和小白都适合） 前言: 常常一些核心技术等我碰到的时候才发现自己忘得差不多了，甘心安于现状，等自己跟别人有了差距之后才想起来要学习，我太难了，永远不要停下自己学习的脚步，比你厉害的人真的有很多. 今天给大家分享的是一份283页的Java核心知识点(PDF)特别详细，有幸得此宝典，这么详细的核心知识点怎能独吞呢，分享给各位有需要想学习的同仁朋友们， 文末可获取. 由于篇幅限制，不能完整的把全部内容分享出来，如果你觉得此文档对你有帮助，你有需求的话，看到末尾会有福利 包含内容: 26个知识点 Java基础，集合，并发，多线程，JVM，设计模式 Java算法，数据结构 Spring，MyBatis，MVC，netty，tomcat 架构设计，Redis缓存，Zookeeper，kafka，RabbitMQ，负载均衡 SpringBoot，SpringCloud，Dubbo，Docker 适用人群: 个人觉得都适用，不管是小白还是大牛，查漏补缺发现更厉害的你 JVM 线程 JVM内存区域 JVM运行内存 垃圾回收与算法 Java四种引用类型 GC 分代收集算法 VS 分区收集算法 GC 垃圾收集器 JAVA IO/NIO JVM类加载机制 JVM 的内存模型和 JVM 的垃圾回收机制一直是 Java 业内从业者绕不开的话题（实际调优、面试）JVM是java中很重要的一块知识

为什么很多公司升级系统，选择在晚上上线？ 答 ：美名其曰，晚上上线，对用户影响最小。 为什么会对用户产生影响？ 答 ：系统升级往往需要重启，重启的过程中，正在访问的用户会访问失败。 如果升级的是web-server： 如上图，重启ip1上的tomcat时，tomcat上或许有1000个http请求正在处理，这些请求就会失败。 如果升级的是service： 如上图，重启ip1的service时，service上或许有2000个请求正在处理，这些请求就会失败。 web-server升级能否不影响正在处理的请求？ 答 ：可以，需要nginx和web-server配合。 （1）给nginx发指令，将ip1上的流量切走 （2）nginx不会将新流量放给ip1，旧流量会很快处理完成 （3）旧流量完成后，升级web-server 此时，ip1上的web-server处于没有流量的状况，可以随便玩： 停服务备份 升级（粉色代表升级后的节点） 服务重启 测试工程师直连ip1进行验证 验证完毕 （4）给nginx发指令，将流量切回ip1 （5）流量切回ip1，单节点上线成功 一个节点升级完成之后，其他节点可以依次逐台升级。 service升级能否不影响正在处理的请求？ 答 ：可以，需要RPC-client和RPC-server配合。 （1）向准备升级的service节点ip1发送切流量指令