Spring在2017年下半年迎来了Webflux，Webflux的出现填补了Spring在响应式编程上的空白，在一些特殊的场景下Webflux体现出了不俗的性能。那到底Webflux和WebMVC有什么区别呢。
Servlet模型
在这之前，首先介绍传统的Servlet模型
servlet由servlet container进行生命周期管理。container启动时构造servlet对象并调用servlet init()进行初始化；container关闭时调用servlet destory()销毁servlet；container运行时接受请求，并为每个请求分配一个线程（一般从线程池中获取空闲线程）然后调用service()。
弊端：servlet是一个简单的网络编程模型，当请求进入servlet container时，servlet container就会为其绑定一个线程，在并发不高的场景下这种模型是适用的，但是一旦并发上升，线程数量就会上涨，而线程资源代价是昂贵的（上线文切换，内存消耗大）严重影响请求的处理时间。在一些简单的业务场景下，不希望为每个request分配一个线程，只需要1个或几个线程就能应对极大并发的请求，这种业务场景下servlet模型没有优势。
spring webmvc是基于servlet之上的一个路由模型，即spring实现了处理所有request请求的一个servlet（DispatcherServlet），并由该servlet进行路由。所以spring webmvc无法摆脱servlet模型的弊端。
Webflux模型
Webflux模式替换了旧的Servlet线程模型。用少量的线程处理request和response io操作，这些线程称为Loop线程，而业务交给响应式编程框架处理，响应式编程是非常灵活的，用户可以将业务中阻塞的操作提交到响应式框架的work线程中执行，而不阻塞的操作依然可以在Loop线程中进行处理，大大提高了Loop线程的利用率。官方结构图：
性能测试
将WebFlux，VertX和Servlet(JAXRS2.1 Tomcat)三者进行性能对比测试。
测试场景
1. 1000/user, 总request数量500000
2. request：/product?productID=10 response：{"productId":"10"}
3. service server 参数：
cpu = 32 Intel(R) Xeon(R) CPU E5-2690 0 @ 2.90GHz,
memory = 252GB
linux = version 2.6.32-358.el6.x86_64
java = Java(TM) SE Runtime Environment (build 1.8.0_73-b02)
JVM = Java HotSpot(TM) 64-Bit Server VM (build 25.73-b02, mixed mode)
4. client server 参数：same with service server
5. 客户端测试工具 Apache Jmeter 4.0
注：为了尽量和实际service保持一致，每个request耗时控制在20MS。
测试结果
VertX：
summary = 2574404 in 00:00:57 = 45311.3/s Avg: 21 Min: 5 Max: 1133 Err: 75 (0.00%)
WebFlux：
summary = 2499748 in 00:00:57 = 44004.2/s Avg: 22 Min: 4 Max: 4020 Err: 65 (0.00%)
Tomcat：
summary = 1831730 in 00:01:01 = 30234.1/s Avg: 27 Min: 3 Max: 31020 Err: 72 (0.00%)
结论
VertX 吞吐量45311.3/s排名第一，在1000并发平均响应性能损失5%，最坏情况性能损失5665%。
WebFlux吞吐量44004.2/s排名第二，在1000并发平均响应性能损失10%，最坏情况性能损失20100%。
Tomcat 吞吐量30234.1/s排名第三，在1000并发平均响应性能损失35%，最坏情况性能损失155100%。
试用场景
Spring Webflux由于支持@Controller，对于一些已有的Spring MVC Service来说，迁移的工作量和风险相对较小。对于一些service业务逻辑简单，并发高的可以考虑切换至Webflux，可以减少service的部署，降低机器成本。
