一、Lifecycle
二、综合实战
三、现代分布式系统复杂的网络通信挑战
最大问题一个Http请求对应一个Thread
同步模型 vs 异步模型 (thread pre request vs reactor)
轮询所有事件，经典事件驱动模型，好处是一个线程不止服务一个请求，但是编写代码困难，需要知道哪个请求每次写几个字节去维护状态
由于异步编程能很好应对互联网高峰值高低谷的请求，所以Netty封装了NIO变成一个Web服务器框架供大家使用，但是Netty很难用需要对框架有很多理解才能写出没有Bug的代码，一旦出现Bug也很难解决。Netty无法应对数据库查询的时候JDBC本身就是同步这一状况——于是引出了Spring Reactive stack从底层到顶层全都是异步
四、Spring Reactive stack
也得益于Reactor Netty的出现协助底层通讯
4.1）Reactor Netty
Reactive出现后，Netty改动一下出现Reactor Netty，随后Spring在此基础上开发了Spring Reactive
Netty向外暴露了Httpserver.handler()接口，Spring自己编写的Handler将Reactor Netty和Spring Reactive桥接起来
4.2）WebMVC vs WebFlux
4.3）Springboot 如何选用Reactive栈
4.4）Spring webflux 核心组件
注解方式
函数式编程请求路由
服务器主动推消息
WebHandler API
4.5）Webflux 相关配置
从上述类中可发现WebFlux核心组件的具体实现
4.6）请求链——描述了Spring如何和Reactive Netty桥接
经过一层层最终通过DispatcheHandler进行请求的分发之后调用我们写的业务接口
HttpServerHandler这个类属于Netty
Spring用来桥接Netty的类
此类封装了一些东西，相当于上文WebHandler API那张图
concatMap就是一个一个来，next是找到了就拿一个mapping出来
getHandler()
invokeHandler()
4.7）RouterFunctionBuilder
轻量级WebFlux，没有IOC也没有注解映射
4.8）HandlerMapping & ResultHandler
函数式结果处理
4.9）Reactive DB
使用了Reactive数据库就不能使用同步阻塞的JDBC
4.10）测试应对请求的线程数
