Spring5.1.2核⼼技术之WebFlux（⼀）
Spring WebFlux是Spring从5.0开始提供的，由于最近在研究Spring Boot，正好研究到了Spring Boot中的WebFlux所以就看了下Spring官⽅⽂档，后来发现只有英⽂的，不太⽅便，所以根据官⽹进⾏了翻译.我不是⼀个专业的翻译⼈员，第⼀写，希望⼤家多多⿎励.如果有翻译不太恰当的地⽅，希望⼤家给指正.
1.1 概论
spring mvc和boot区别
为什么需要Spring WebFlux?
⼀个答案是需要⼀个只使⽤了少量线程和更低硬件资源的⾮阻塞web栈来处理并发问题.Servlet3.1为⾮阻塞IO提供了⼀些API.然⽽使⽤他就意味着与那些同步和阻塞的Servlet API远离了.
这是新的能服务于跨⾮阻塞运⾏环境的普遍API产⽣的动机.这也是很重要的，有像Netty这样的在异步和⾮阻塞上做的⽐较好的服务器的⽀持
另⼀个答案是函数式程序设计.虽然Java5中增加的注解(RestController和UnitTest)和Java8中增加的Lambda表达式都为Java⾥的函数式编程创造了机会.对于⾮阻塞应⽤程序和允许声明式创建异步逻辑的后继式API(通过CompletableFuture和ReactiveX来普及)来说是个福利.在程序设计模型级别上,Java8启⽤了Spring WebFlux来提供函数式web endpoints与注解Controller.
1.1.1 "Reactive"的定义
我们接触了"⾮阻塞"和"函数式"，那reactive是什么意思呢?
"reactive"这个术语指的是：围绕着对改变做出响应的程序设计模型---⽹络组件对IO事件做出响应,UIController对⿏标事件做出响应等等.在那种情况下,⾮阻塞取代了阻塞是响应式的，我们正处于响应模式中，当操作完成和数据变得可⽤的时候发起通知.
还有另⼀个重要的机制那就是我们在spring team⾥整合"reactive"以及⾮阻塞式背压机制.在同步⾥，命令式的代码，阻塞式地调⽤服务为普通的表单充当背压机制强迫调⽤者等待.在⾮阻塞式编程中，控制事件的频率就变得很重要防⽌快速的⽣产者不会压垮他的⽬的地.
Reactive Streams 是⼀个定义了使⽤背压机制的异步组件之间交互设计的⼩型说明书(在Java9中也采纳了).例如,⼀个数据仓库(可以看做Publisher)可以⽣产数据，然后HTTP Server(看做订阅者)可以写⼊到响应⾥.Reactive Streams的主要⽬的是让订阅者可以控制⽣产者产⽣数据的速度有多快或有多慢.
这⾥有个问题，如果⽣产者不能降速怎么办?我们要明⽩,Reactive Stream的⽬的只是简历⼀个机制和边界.如果⽣产者不能降速，就必须决定是否要开启缓冲，放弃或失败.
1.1.2 Reactive API
Reactive Streams 在互操作性上扮演了⼀个很重要的⾓⾊.类库和基础设施组件虽然有趣，但对于应⽤程序API来说却⽤处甚少，因为他们太底层了.应⽤程序需要⼀个更⾼级别更丰富的函数式API来编写异步逻辑---和Java8⾥的StreamAPI很类似，不过不仅仅是为集合做准备的.
Reactor 是为SpringWebFlux选择的⼀个reactive类库.它提供了Mono和Flux类型的API来处理0..1(Mono)和0..N(Flux)数据序列化通过⼀组丰富的操作集和ReactiveX vocabulary of operators对齐.Reactor 是⼀个Reactive Streams类库，所以他所有的操作都⽀持⾮阻塞背压机制.Reactor强烈地聚焦于Server端的Java.他在发展上和Spring有着紧密的协作.
WebFlux要求Reactor作为⼀个核⼼依赖，但凭借Reactive Streams也可以和其他的reactive libraries⼀起使⽤.⼀般来说,⼀个WebFlux API 接收⼀个Publisher作为输⼊，转换给⼀个内置的Reactor类型来使⽤，最后返回⼀个Flux或⼀个Mono作为输出.所以，你可以批准任何的Publisher作为输⼊，你可以应⽤操作在输出上，但你因为你使⽤了其他的reactive library所以你需要进⾏转换.只要可⾏(例如，注解controllers),WebFlux可以在使⽤RXJava和另⼀个reactive library之间透明的改变.看获取更多地细节.
1.1.3 Programming Models
Spring-Web模块包含了由SpringWebFlux构成的响应式的根基.包含了HTTP的抽象,Reactive 为服务端提供⽀持的Streams适配器,codecs和⼀个可以和Servlet API相⽐的使⽤了⾮阻塞约定的WebHandler A
PI核⼼.
在那个基础上,Spring WebFlux提供了两种程序设计模型以供选择:
: 与Spring MVC并存的并且基于同样从spring-web模块⽽来的注解。⽆论是SpringMVC还是WebFlux都⽀持响应式的(Reactor和RXJava)返回类型.就结果⽽⾔，讲出他们之间的区别并不是很容易.⼀个明显的区别是WebFlux也⽀持响应式的@RequestBody 参数.
: 基于Lambda的，轻量级的和函数式程序设计模型.你可以把这个看作是⼀个⼩的应⽤程序可以⽤来路由和处理请求的类库或是⼀组实⽤的集合.使⽤注解Controller⼀个很⼤的不同就是应⽤程序负责从开始到结尾的请求处理,⽽不是通过注解和回调声明intent(这个词不知道怎么翻译合适).
1.1.4 适⽤性
Spring MVC还是 WebFlux?
⼀个很⾃然的问题要问，但要建⽴⼀个不完全⼆分法.实际上，扩展可⽤范围的情况下两者是可以⼀起⼯作的.这两者被设计得彼此之间是有⼀定的连续性和⼀致性的，他们可以被并列使⽤,⼀⽅可以从另⼀⽅中获益和反馈.以下的图显⽰了这两者的联系，他们的共性以及他们各⾃特有的⼀些⽀持:
我们建议你考虑以下具体的⼏点:
如果你有⼀个Spring MVC应⽤程序运⾏地很好，那就不要改变它.命令式程序设计从编写，理解和调试上来说都是最简单的.从历史的⾓度来看，因为⼤多数类库都是阻塞的，所以你有最⼤限度的选择余地.
如果你正在谋求⼀站式的⾮阻塞web技术栈,Spring WebFlux在这⼀⽅⾯和其他框架⼀样提供了执⾏模型的好处额停了⼀些⾮阻塞的服务器选择(Netty,Tomcat,Jetty,Undertow和Servlet3.1容器),⼀个程序设计模型的选择(注解Controller和函数式web endpoints)和⼀个响应式类库选择(Reactor,RXJava或者其
他的).
如果你因为使⽤Java8的lambda或Kotlin⽽对轻量级，函数式web框架感兴趣，你可以使⽤Spring WebFlux的函数式web endpoints.对于较⼩的应⽤程序或不太复杂的微服务来说，这也是个不错的选择，因为他们可以从更⼤的透明度和控制权中获益.
在微服务架构中，你有⼀个混合了SpringMVC或Spring WebFlux controller或使⽤了Spring WebFlux 函数式endpoint的项⽬.对不同框架间基于⼀样注解的程序设计模型的⽀持时复⽤更加容易，同时还可以为合适的⼯作选择合适的⼯具.
评估⼀个应⽤程序的⼀个简单⽅式就是检查他的依赖.如果你要使⽤阻塞型的持久化API(JPA,JDBC)或者⽹络api,Spring MVC⾄少对于常见架构来说是⼀种最好的选择.使⽤Reactor和RxJava在分离线程上执⾏⼀些阻塞式的调⽤从技术⾓度来讲是可⾏的，只是你⽆法充分利⽤⾮阻塞式web栈.
如果你有⼀个使⽤了远程服务调⽤的Spring MVC应⽤程序，尝试⼀下响应式的WebClient.你可以直接从SpringMVC的Controller⽅法中直接返回响应式的类型(Reactor,RxJava或其他的).每次调⽤的延迟越⼤或调⽤之间相互依赖越⼤，动态效益越⼤.Spring MVC的controller也可以调⽤其他的响应式组件.
如果你有⼀个⼤型的团队，请牢记在转变过程中⾮阻塞，函数式和声明式程序设计陡峭的学习路线.⼀
个⾮全盘式转变的可实践的⽅式就是使⽤响应式的WebClient.初次之外，衡量利益⼩范围的开始.我们认为，应⽤程序的范围很宽泛的话，就没有转移的必要.如果你不太确定希望得到的益处是什么，可以通过学习⾮阻塞IO是如何⼯作的(例如,nodejs单线程的并发性)以及它的影响.
1.1.5 服务器
Spring WebFlux在Tomcat,Jetty,Servlet3.1+容器上被⽀持的和⾮Servlet运⾏环境像Netty和Undertow⼀样的好.所有的服务器都会被转换为更底层的，共性的API以便更⾼级别的程序设计模型能被跨服务器地⽀持.
Spring WebFlux没有内置的配置来启动和停⽌⼀个服务器.然⽽，从Spring 配置和WebFlux infrastructure和run it 中使⽤少量代码进⾏集成是很容易的.
Spring Boot有⼀个⾃动完成这些步骤的WebFlux Starter.该starter默认使⽤的是Netty，但通过改变Maven或Gradle的依赖来切换到tomcat,Jetty或Undertow是⾮常容易的.Spring Boot默认使⽤Netty是因为在异步和⾮阻塞⽅⾯使⽤的⾮常⼴泛，并且可以在客户端和服务端共享资源.
Tomcat和Jetty⽆论是SpringMVC还是WebFlux都可以使⽤.然⽽，要记住，他们使⽤这些服务器的⽅式是⾮常不⼀样的.Spring MVC主要依赖于Servlet的阻塞I/O，并且在需要是让应⽤程序直接使⽤Servlet
API.Spring WebFlux依赖的是Servlet3.1⾮阻塞I/O，使⽤的是在底层进⾏了转换的Servlet API,⽽不是直接使⽤那些已暴露出来的接⼝.
对于Undertow来说,Spring WebFlux直接使⽤Undertow的APIs，并没有使⽤Servlet API.
1.1.6 性能
性能这个词有很多特征和含义.Reactive 和⾮阻塞通常不会使应⽤程序运⾏地更快.在某些场景下，他们也可以.(例如，在并⾏条件下使⽤WebClient来执⾏远程调⽤的话).整体来说,⾮阻塞⽅式可能需要做更多的⼯作并且他也会稍微增加请求处理的时间.
对reactive和⾮阻塞好处的预期关键在于使⽤⼩，固定的线程数和更少的内存来扩展的能⼒.这使应⽤程序在加载的时候更加有弹性，因为他们以⼀种更可以预测的⽅式扩展.然⽽为了看到这些好处，你需要⼀些延迟(包括⽐较慢的不可预知的⽹络I/O).那是响应式堆栈开始显⽰他⼒量的地⽅，并且这些不同是⾮常吸引⼈的.
1.1.7 并发模型
Spring MVC和Spring WebFlux都⽀持注解Controllers，但他们在并发模型和对阻塞和线程的默认呈现(assumptions)上是⾮常不同的.
在Spring MVC(和通⽤的servlet应⽤)中，都假设应⽤程序是阻塞当前线程的(例如，远程调⽤)，并且出于这个原因,servlet容器处理请求的期间使⽤⼀个巨⼤的线程池来吸收潜在的阻塞.
在Spring WebFlux(和⾮阻塞服务器)中，假设应⽤程序是⾮阻塞的，所以,⾮阻塞服务器使⽤⼩的，固定代销的线程池(event loop workders)来处理请求.
"弹性伸缩"和"⼩数量的线程"或许听起来⽭盾，但是对于不会阻塞当前线程(⽤依赖回调来取代)意味着你不需要额外的线程，因为⾮阻塞调⽤给处理了.
调⽤⼀个阻塞API
要是你需要使⽤阻塞库怎么办?Reactor和RxJava都提供了publishOn操作⽤⼀个不同的线程来继续处理.那意味着有⼀个简单的脱离舱⼝(⼀个可以离开⾮阻塞的出⼝).然⽽，请牢记，阻塞API对于并发模型来说不太合适.
易变的状态
在Reactor和RxJava⾥，你通过操作符⽣命逻辑，在运⾏时在不同的阶段⾥，都会形成⼀个进⾏数据序列化处理的管道.这样做的⼀个主要好处就是把应⽤程序从不同的状态保护中解放了出来，因为管道中的应⽤代码是绝不会被同时调⽤的.
线程模型
在运⾏了⼀个使⽤Spring WebFlux的服务器上，你期望看到什么线程呢?
在⼀个"vanilla"Spring WebFlux服务器上(例如，没有数据访问也没有其他可选的依赖)，你能够看到⼀个服务器线程和⼏个其他的⽤来处理请求的线程(⼀般来说，线程的数⽬和CPU的核数是⼀样的).然⽽,Servlet容器在启动的时候就使⽤了更多的线程(例如,tomcat是10个)，来⽀持servlet(阻塞)I/O和servlet3.1(⾮阻塞)I/O的⽤法.
响应式的WebClient操作是⽤Event Loop⽅式.所以你可以看到少量的固定数量的线程和他关联.(例如，使⽤了Reactor Netty连接的reactor-http-nio).然⽽，如果Reactor Netty在客户端和服务端都被使⽤了，这两者之间的event loop资源默认是被共享的.
Reactor和RxJava提供了抽象化的线程池，调度器⽬的是结合publishOn操作符在不同的线程池之间切换操作.调度器有⼀个名字，建议这个名字是⼀个具体的并发策略--例如,"parallel"(因为CPU-bound使⽤有限的线程数来⼯作)或者"elastic"(因为I/O-bound使⽤⼤量的线程来⼯作).如果你看到这类的线程，这就意味着⼀些代码正在使⽤⼀个具体的使⽤了Scheduler策略的线程池.
数据访问库和其他第三⽅库依赖也创建和使⽤了他们⾃⼰的线程.
配置
Spring 框架不为启动和停⽌servers提供⽀持.为了给⼀个服务器配置⼀个线程模型，你需要使⽤指定的服务器配置APIs，或者，你使⽤Spring Boot，检查Spring Boot为每个服务器提供的配置选项.你可以直接配置WebClient.对于所有其他的库，可以参考他们各⾃的⽂档.
如果喜欢，可以给个好评⿎励⼀下，嘿嘿.稍后会发布第⼆篇《Reactive Core》，敬请期待

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。