情景引入

很早之前,Java就火起来了,是因为它善于开发和处理网络方面的应用。

Java有一个爱好,就是喜欢制定规范标准,但自己又不善于去实现。

反倒是一些服务提供商使用它的规范标准来制造应用服务器而赚的盆满钵满。

企业用户因要使用这些应用服务器而向提供商支付高额费用,而且也不是特别好用。

一个青年才俊为了打破这种局面而奔走呼号、奋发图强。

自我介绍

显然,这个青年才俊就是后来的Spring。

因企业应用大都和web相关,而Java的web标准中较核心的一部分其实就是JavaEE里的Servlet。

Spring和Servlet“相亲相爱”一番后,我就来到了这个世界。我的全名叫Spring MVC,这里的Spring既是我的姓也是我的“爸爸”,那Servlet就是我的“妈妈”了,大家叫我MVC就行了。

那个年代社会很落后,条件也不好,好歹我们要求也不高,求个温饱就行了。

所以我的妈妈Servlet和她的闺蜜Filter天生就是同步阻塞的,包括她们同事HttpServletRequest的getParameter,getPart等这些方法也都是阻塞的。

虽然我的爸爸Spring给了我23条染色体来进行改良,但不要忘了我还从Servlet妈妈那里继承了23条,所以我也是同步阻塞的。不过我的“长相”已经好看很多了,因为Spring爸爸知道,在以后的日子里,除了拼实力之外,颜值也是非常重要的。

因为我妈妈Servlet是一个规范,我爸爸Spring是一个框架,所以我跟他们一样,都是无法自己独立运行的。

所以在我们要运行的时候,必须要寻找一个特殊的“家”,通常称它为Servlet容器,比如tomcat就算非常知名的一个。

Servlet容器熟知我极有可能阻塞当前执行线程,所以专门量身打造。它给我准备了一个非常大的线程池,里面有好多线程。每过来一个请求,它就扔给我一个线程,说自己玩去吧,随便“折腾”。

好在那时美国那个叫乔布斯的家伙被自己的公司赶出去在外面“流浪”,Servlet容器为我量身打造的这种方法完全能够胜任日常,关键还非常的简单。

这种小富即安的日子就这样往前过着。

兄弟出生

生命不息,变化不止。随着乔布斯推出iphone,智能机瞬间大火,全民进入移动互联网时代。激增的网民数量,给现有软件架构带来极大的挑战。

一般来说,社会越发达,分工越精细,对单一工种的要求就越高。

软件也是如此,在传统“大块头”软件表现的越来越格格不入的时候,微服务就如一丝春风吹了进来。

按它的指导原则,将大软件按某种方式拆分为一个个小工程。小工程规模小,便于管理,而且机动性也好,功能聚合性更好。它承受的并发应该更高。

有人觉得与微服务比起来,过去使用的web服务器如tomcat略显笨重,不够轻量级。也有人说tomcat内部一个请求一个线程这种阻塞执行方式消耗太多线程,不太容易支撑超高并发。

无论怎么说,简而言之一句话,一个全新的时代已经到来。

此时我们需要一个更加轻量级web应用,它使用更少的硬件资源和线程,反而更容易处理高并发。那么它一定是异步非阻塞的。

这样的使命自然落到了响应式编程的范畴上了。所以我的爸爸Spring审时度势,在5.0之后就赶紧把我推出来了。

没错,我就是Spring WebFlux,这里的Spring既是我的姓也是我爸爸。大家可以叫我WebFlux。初来乍到,好多人都对我不熟悉,请容许我介绍一番。

首先这个响应式究竟是什么意思呢?响应式这个术语,指的是一个编程模型,它是围绕着对变化的反映来构建的。

如网络组件用来响应I/O事件,UI控制器用来响应鼠标事件等等。按照这种意识的话,非阻塞就是响应式的,对操作完成或数据可用通知事件的响应方式。

另外一个关于响应式的机制是非阻塞后压。在命令式代码中,同步阻塞调用带有自然的后压迫使调用者等待。

在异步代码中,它变得非常重要,用来控制事件的速率,以至于不让一个快速的事件源压垮它的响应者。就是响应者能够控制事件源发射事件的快慢。

因为响应式编程是非阻塞的,所以我也是非阻塞的,因此我通常运行在非阻塞web服务器上,如Netty,Undertow等。

因为我不会阻塞线程的执行,所以使用一个小的固定数量的线程池(event loop workers)来处理请求。典型地,线程数与CPU的核数相同。

这里还要感谢我的姥爷Java 8,他老人家引入了lambda表达式造就了函数式编程API。这对于非阻塞应用和连续式API来说是一个非常棒的东西,允许以声明的方式把异步逻辑组合起来。

我感觉我的爸爸Spring已经超越了一个框架,成为一个平台了。所以他自己并没有亲自去实现响应式处理,而是为我选择Reactor作为响应式库。

Reactor提供Flux和Mono类型,拥有丰富的操作符,支持非阻塞后压,使用函数式API来组合异步逻辑。并且Reactor强烈聚焦于Java服务器端。它在开发时就已经与爸爸Spring亲密协作了。

爸爸说,我也支持其它的库如RxJava,但看样子似乎让我更爱Reactor一些。

这就是我,WebFlux,一个集天时地利于一身的幸运儿。但你是不是已经晕晕的啦,没关系,慢慢来。

包罗万象

我想,大家都看出了我爸爸Spring的野心,他不仅要成为一个平台,还要建起自己的生态系统,竖起壁垒。

所以他的核心事业就是进行抽象,组合和装配,进而包罗万象。说的掉渣一些,就是哪个技术好,就给它整合进来。

为了抹平底层不同web服务器的差异,我爸爸抽象了一个最低级别的契约接口,HttpHandler,用于响应式HTTP请求的处理。

Mono<java.lang.Void> handle(ServerHttpRequest request, ServerHttpResponse response);

它是一个通用的接口,要横跨不同的运行时。它是有意设计成最小化的,只有一个方法,主要唯一目的就是在不同的HTTP服务器API上面成为一个最小化的抽象。

如果想用Netty服务器的话,就基于Netty实现一下,同理也可以基于Undertow实现一下,等等,只要以后有了新的服务器,都可以加进来的。

显而易见,HttpHandler的目标是抽象出来对不同HTTP服务器的使用,说白了就是为了和底层服务器对接。但由于太偏底层,不利用上层代码使用。

为此,我的爸爸又抽象出一个稍微高一点级别的契约接口,WebHandler,用于Web请求处理。很明显,WebHandler的目标是提供web应用中广泛使用的通用特性,如Session、表单数据和附件等等,也是为了更容易和上层代码对接。

很自然的,WebHandler是构建于HttpHandler之上的,换句话说WebHander的处理会通过一个适配器HttpWebHandlerAdapter最终代理给HttpHandler来执行。

WebHandler接口也只有一个方法:

Mono<java.lang.Void> handle(ServerWebExchange exchange);

参数类型是ServerWebExchange,可以这样理解,你发一个请求,给你一个响应,相当于用请求交换了一个响应,而且是在服务器端交换的。

其实,整个web请求的处理过程是一个链式的,最后才是一个WebHandler,它前面可以插入多个错误处理器,WebExceptionHandler,多个过滤器,WebFilter。

这是错误处理器接口:

Mono<java.lang.Void> handle(ServerWebExchange exchange, java.lang.Throwable ex);

这是过滤器接口:

Mono<java.lang.Void> filter(ServerWebExchange exchange, WebFilterChain chain);

可见,我的爸爸Spring的抽象能力非常强,对下抽象一个接口,抹平了不同服务器的差异。对上抽象一个接口,可以用于支撑不同的编程模型。

都有哪些编程模型呢,请继续往下看吧。

皮囊之下

上面我在介绍自己的时候使用了美颜,所以诸位很难看清我的“真面目”,下面就来进行一下自我剖析,看看真实的我。

我包含一个轻量级函数式编程模型,函数被用来参与处理请求,它是相对于基于注解编程模型的另一种选择,这种编程模型叫做函数式端点,functional endpoints,是构建于上面提到的WebHandler之上的。

我是使用HandlerFunction来处理一个HTTP请求的,这是一个函数式接口,也称处理函数:

@FunctionalInterface
public interface HandlerFunction<T extends ServerResponse> {
    reactor.core.publisher.Mono<T> handle(ServerRequest request);
}

带有一个ServerRequest参数,返回一个Mono<ServerResponse>,其中request和response对象都是不可变的,HandlerFunction就等价于Controller中的@RequestMapping标记的方法。

实际当中,请求很多,处理函数也很多,如何知道一个请求过来后,该由哪个处理函数去处理呢?

这自然要用到我的另一个函数式接口RouterFunction来搞定,称为路由函数:

@FunctionalInterface
public interface RouterFunction<T extends ServerResponse> {
    reactor.core.publisher.Mono<HandlerFunction<T>> route(ServerRequest request);
}

带有一个ServerRequest参数,返回一个Mono<HandlerFunction>。就是它把一个请求路由到一个HandlerFunction的,当路由函数匹配时,就返回一个处理函数,否则返回一个空的Mono。RouterFunction等价于@RequestMapping注解,但主要不同的是路由函数提供的不仅是数据,还有行为。

下面通过一些示例,来更加直观的帮助大家认识这两个函数式接口。

因处理函数是函数式接口,所以可以直接用一个lambda表达式来处理请求,如下:

HandlerFunction<ServerResponse> handler = request -> Response.ok().body("Hello World");

这就表示当任何一个请求过来时,都返回Hello World作为响应。

在实际应用中,处理逻辑一般都很复杂,肯定不是一个lambda表达式能搞定的,此时希望把处理方法专门写到一个类里,就叫处理器类,和MVC里的Controller差不多一回事。

下面就是一个Person的处理器类:

public class PersonHandler {

    public Mono<ServerResponse> listPeople(ServerRequest request) {
        // ...
    }     public Mono<ServerResponse> createPerson(ServerRequest request) {
        // ...
    }     public Mono<ServerResponse> getPerson(ServerRequest request) {
        // ...
    }
}

此时就可以通过处理函数,引用这些处理器方法了,如下:

PersonHandler handler = new PersonHandler();

HandlerFunction<ServerResponse> list = handler::listPeople;

HandlerFunction<ServerResponse> create = handler::createPerson;

HandlerFunction<ServerResponse> get = handler::getPerson;

要想使请求能够正确被路由,首先要定义好路由函数,如下:

RouterFunction<ServerResponse> route = RouterFunctions.route()
    .GET("/person/{id}", get)
    .GET("/person", list)
    .POST("/person", create)
    .build();

它表示当以GET方法请求/person/{id}时,最终会由getPerson方法处理。当以GET方法请求/person时,最后会由listPeople方法处理。同理,以POST方法请求/person时,会由createPerson方法处理。

可见,一个路由函数可以包含多个路由规则,实际当中,可以定义多个路由函数,这些路由函数可以组合在一起。

路由函数是按顺序计算的,如果第一个路由不匹配,计算第二个,等等。因此,把更加具体的路由放到通用路由前面是非常有意义的。注意这和基于注解的不同。

怎么样,关掉滤镜的我是不是更加真实了。我相信你也看明白了,至少要记住,这是基于函数式的一种编程模型,叫做函数式端点。

雨露均沾

像我这样的幸运儿,你们一定以为Spring爸爸对我非常溺爱吧,告诉你,确实是这样的。不过考虑到大家伙一路走来对Spring的不离不弃,爸爸也设身处地为你们着想。

为此,我除了支持函数式端点这种编程模型之外,还支持一种编程模型叫基于注解的控制器,annotated controllers,没错,就是MVC里的那个。

话说的再白一些,就是大家已经非常熟悉的Spring MVC那套东西,我百分之百的完全支持,妥妥的,放心使用。

但是,并不是所有的控制器方法参数都支持响应式类型,只有一些支持,如WebSession,java.security.Principal,@RequestBody,HttpEntity<B>,@RequestPart等。

下面看一个示例:

@PostMapping("/")
public String handle(@RequestBody Mono<MultiValueMap<String, Part>> parts) { 
    // ...
} @PostMapping("/")
public String handle(@RequestBody Flux<Part> parts) { 
    // ...
} @PostMapping("/accounts")
public void handle(@RequestBody Mono<Account> account) {
    // ...
}

不过对于控制器方法的所有返回值,都是支持响应式类型的。

各有千秋

Spring MVC和Spring WebFlux可以一起使用,从设计上讲,它们互为继续、互为一致。

它们的关系,请看下图,既有共同的部分,也有互相独立的部分。

Spring MVC的特点就是,它是命令式编程,代码非常容易写,也好理解和调试。但是它是同步的,会有人觉得它性能不好。

但是我要说的是,响应式和非阻塞通常来讲也不会使应用运行的更快。相反,非阻塞方式要求做更多的事情,而且还会稍微增加一些必要的处理时间。也就是说,还可能稍稍变慢一点,what,那为啥还要用它呢?

响应式和非阻塞的关键好处是,在使用很少固定数目的线程和较少的内存情况下的扩展能力。

这使应用在负载下更有适应能力,因为它们以一个更加具有可预见性的方式在扩展。

为了能够观察到这些好处,你需要有一些延迟才行,比如一个既不可靠且速度又慢的网络I/O,这才是响应式开始展示它强劲的地方,带来的差异(惊喜)可能是巨大的哦。

其实技术无好坏,各有各的适用场景罢了。

(完)

编程新说


用独特的视角说技术

爸爸又给Spring MVC生了个弟弟叫Spring WebFlux的更多相关文章

  1. Spring MVC 学习总结(九)——Spring MVC实现RESTful与JSON(Spring MVC为前端提供服务)

    很多时候前端都需要调用后台服务实现交互功能,常见的数据交换格式多是JSON或XML,这里主要讲解Spring MVC为前端提供JSON格式的数据并实现与前台交互.RESTful则是一种软件架构风格.设 ...

  2. Spring MVC 学习总结(十)——Spring+Spring MVC+MyBatis框架集成(IntelliJ IDEA SSM集成)

    与SSH(Struts/Spring/Hibernate/)一样,Spring+SpringMVC+MyBatis也有一个简称SSM,Spring实现业务对象管理,Spring MVC负责请求的转发和 ...

  3. Spring MVC 学习总结(六)——Spring+Spring MVC+MyBatis框架集成

    与SSH(Struts/Spring/Hibernate/)一样,Spring+SpringMVC+MyBatis也有一个简称SSM,Spring实现业务对象管理,Spring MVC负责请求的转发和 ...

  4. Java Spring MVC项目搭建(一)——Spring MVC框架集成

    1.Java JDK及Tomcat安装 我这里安装的是JDK 1.8 及 Tomcat 8,安装步骤详见:http://www.cnblogs.com/eczhou/p/6285248.html 2. ...

  5. Spring MVC 学习总结(八)——Spring MVC概要与环境配置(IDEA+Maven+Tomcat7+JDK8、示例与视频)

    一.MVC概要 MVC是模型(Model).视图(View).控制器(Controller)的简写,是一种软件设计规范,用一种将业务逻辑.数据.显示分离的方法组织代码,MVC主要作用是降低了视图与业务 ...

  6. Spring MVC学习总结(10)——Spring MVC使用Cors跨域

    跨站 HTTP 请求(Cross-site HTTP request)是指发起请求的资源所在域不同于该请求所指向资源所在的域的 HTTP 请求.比如说,域名A(http://domaina.examp ...

  7. Spring MVC学习总结(2)——Spring MVC常用注解说明

        使用Spring MVC的注解及其用法和其它相关知识来实现控制器功能. 02     之前在使用Struts2实现MVC的注解时,是借助struts2-convention这个插件,如今我们使 ...

  8. Spring MVC学习总结(1)——Spring MVC单元测试

    关于spring MVC单元测试常规的方法则是启动WEB服务器,测试出错 ,停掉WEB 改代码,重启WEB,测试,大量的时间都浪费在WEB服务器的启动上,下面介绍个实用的方法,spring MVC单元 ...

  9. Spring,SpringMvc配置常见的坑,注解的使用注意事项,applicationContext.xml和spring.mvc.xml配置注意事项,spring中的事务失效,事务不回滚原因

    1.Spring中的applicationContext.xml配置错误导致的异常 异常信息: org.apache.ibatis.binding.BindingException: Invalid ...

随机推荐

  1. RabbitMQ windows本地安装

    1: 安装RabbitMQ需要先安装Erlang语言开发包.下载地址 http://www.erlang.org/download.html 配置环境变量 ERLANG_HOME C:\Program ...

  2. subprocess实时获取结果和捕获错误

    需要调用命令行来执行某些命令,主要是用 subprocess 实时获取结果和捕获错误,发现subprocess的很多坑. subprocess 普通获取结果方式,其需要命令完全执行才能返回结果: im ...

  3. python接口自动化(十九)--Json 数据处理---实战(详解)

    简介 上一篇说了关于json数据处理,是为了断言方便,这篇就带各位小伙伴实战一下.首先捋一下思路,然后根据思路一步一步的去实现和实战,不要一开始就盲目的动手和无头苍蝇一样到处乱撞,撞得头破血流后而放弃 ...

  4. 网络协议 22 - RPC 协议(下)- 二进制类 RPC 协议

        前面我们认识了两个常用文本类的 RPC 协议,对于陌生人之间的沟通,用 NBA.CBA 这样的缩略语,会使得协议约定非常不方便.     在讲 CDN 和 DNS 的时候,我们讲过接入层的设计 ...

  5. vue.js框架原理浅析

    vue.js是一个非常优秀的前端开发框架,不是我说的,大家都知道. 首先我现在的能力,独立阅读源码还是有很大压力的,所幸vue写的很规范,通过方法名基本可以略知一二,里面的原理不懂的地方多方面查找资料 ...

  6. 我的Lambda的学习笔记

    前述 Lambda表达式是 Java 8 的新特性.许多语言都有 Lambda 的特性. 因此使用的 Java 环境一定要 8 以上的环境. Lambda 到底什么是 Lambda 表达式呢? Lam ...

  7. java~springboot~目录索引

    回到占占推荐博客索引 最近写了不过关于java,spring,微服务的相关文章,今天把它整理一下,方便大家学习与参考. java~springboot~目录索引 Java~关于开发工具和包包 Java ...

  8. Android版数据结构与算法(四):基于哈希表实现HashMap核心源码彻底分析

    版权声明:本文出自汪磊的博客,未经作者允许禁止转载. 存储键值对我们首先想到HashMap,它的底层基于哈希表,采用数组存储数据,使用链表来解决哈希碰撞,它是线程不安全的,并且存储的key只能有一个为 ...

  9. 从0开始构建你的api网关--Spring Cloud Gateway网关实战及原理解析

    API 网关 API 网关出现的原因是微服务架构的出现,不同的微服务一般会有不同的网络地址,而外部客户端可能需要调用多个服务的接口才能完成一个业务需求,如果让客户端直接与各个微服务通信,会有以下的问题 ...

  10. SuperMap iObject入门开发系列之三管线系统标注

    本文是一位好友“托马斯”授权给我来发表的,介绍都是他的研究成果,在此,非常感谢. 管线系统会涉及到一些坐标标注,属性标注,提供给用户查询获取其需要的信息,这期的文章介绍的是基于超图iObject开发的 ...