徒手撸代码之自定义网关系列-SpringWebFlux的应用

 

系列文章目录

(一)   SpringWebFlux的应用

(二)   JAVA SPI的概述

(三)   开发Spring第一个插件

(四)  开始撸第一个路由模块之正向代理

(五)   设置路由选择器

目录

系列文章目录

前言

响应式编程是什么？

定义

特性

响应性

韧性

弹性

消息驱动

JAVA的实现

RxJAVA

SpringWebFlux

SpringWebFlux应用

1.概述

2.第一个SpringWebFlux的应用

SpringWebFlux原理

WebServer

ReactiveWebServerFactory

HttpHandler

WebHandler

HandlerMapping

ReactiveWebServerApplicationContext

总结

 

---

前言

本文主要介绍响应式编程的定义，以及SpringWebFlux的应用和原理。

---

响应式编程是什么？

• 定义

在维基百科中，其属于声明式编程，数据流。 它是一种基于数据流 (data stream) 和 变化传递 (propagation of change) 的声明式 (declarative) 的编程范式。使用异步数据流进行编程，这意味着可以在编程语言中很方便地表达静态或动态的数据流，而相关的计算模型会自动将变化的值通过数据流进行传播。

• 特性

• 响应性

快速/一致的响应时间。假设在有500个并发操作时，响应时间为1s，那么并发操作增长至5万时，响应时间也应控制在1s左右。快速一致的响应时间才能给予用户信心，是系统设计的追求。

• 韧性

复制/遏制/隔绝/委托。当某个模块出现问题时，需要将这个问题控制在一定范围内，这便需要使用隔绝的技术，避免连锁性问题的发生。或是将出现故障部分的任务委托给其他模块。韧性主要是系统对错误的容忍。

• 弹性

无竞争点或中心瓶颈/分片/扩展。如果没有状态的话，就进行水平扩展，如果存在状态，就使用分片技术，将数据分至不同的机器上。

• 消息驱动

异步/松耦合/隔绝/地址透明/错误作为消息/背压/无阻塞。消息驱动是实现上述三项的技术支撑。

地址透明有很多方法。例如DNS提供的一串人类能读懂的地址，而不是IP，这是一种不依赖于实现，而依赖于声明的设计；

错误作为消息，这在Java中是不太常见的，Java中通常将错误直接作为异常抛出，而在响应式中，错误也是一种消息，和普通消息地位一致，这和JavaScript中的Promise类似；

背压（Backpressure）是指当上游向下游推送数据时，可能下游承受能力不足导致问题。背压是下游需要向上游声明每次只能接受大约多少量的数据，当接受完毕再次向上游申请数据传输。这便转换成是下游向上游申请数据，而不是上游向下游推送数据。

无阻塞是通过no-blocking IO提供更高的多线程切换效率。

• JAVA的实现

• RxJAVA

RxJava最核心的两个东西是Observables（被观察者，事件源）和Subscribers（观察者）。Observables发出一系列事件，Subscribers处理这些事件。这里的事件可以是任何你感兴趣的东西

• SpringWebFlux

Spring WebFlux 是一个自底向上构建的非阻塞 Web 框架，用于利用多核、下一代处理器并处理大量并发连接。

SpringWebFlux应用

1.概述

随Spring 5一起发布了一个和Spring WebMvc同级的Spring WebFlux。这是一个支持反应式编程模型的新框架体系。Spring Boot 2是基于Spring 5的，其中一个比较大的更新就在于支持包括spring-webflux和响应式的spring-data在内的响应式模块.

如上图左侧为传统基于servlet的Springmvc应用对应的技术栈，右侧为基于Reactor技术站的WebFlux。 WebFlux可以运行在 基于Servlet 3.1提供的非阻塞模式的servlet容器中，也可以运行在异步运行时框架，比如netty/Tomcat上。

2.第一个SpringWebFlux的应用

基于Spring WebFlux的项目与Spring MVC的步骤一致，仅有两点不同:

1、依赖“Reactive Web”的starter而不是“Web”：修改项目POM，调整依赖使其基于Spring WebFlux

    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-webflux</artifactId> 
    </dependency>

 2、Controller中处理请求的返回类型采用响应式类型

    @RestController
    public class HelloController {
    
        @GetMapping("/hello")
        public Mono<String> hello() {   
            return Mono.just("Welcome to reactive world ~"); 
        }
    }

 

---

SpringWebFlux原理

WebFlux所有功能其实内部只由几个抽象类构建而成：

org.springframework.boot.web.reactive.server.ReactiveWebServerFactory

org.springframework.boot.web.server.WebServer

org.springframework.http.server.reactive.HttpHandler

org.springframework.web.reactive.HandlerMapping

org.springframework.web.server.WebHandler

我们从最底层网上层分析：

• WebServer

WebServer见名之意，就是Reacive服务器的抽象类，它定义了服务的基本方法行为，包含启动，停止等接口。结构如下：

package org.springframework.boot.web.server;

public interface WebServer {
    void start() throws WebServerException;

    void stop() throws WebServerException;

    int getPort();

    default void shutDownGracefully(GracefulShutdownCallback callback) {
        callback.shutdownComplete(GracefulShutdownResult.IMMEDIATE);
    }
}

Spring默认有五个WebServer的实现，默认的不特别指定情况下，在spring-boot-starter-webflux自带的是Netty的实现，其实现类如下：

• ReactiveWebServerFactory

对应WebServer，每个实现都会有一个工厂类对应，主要准备创建WebServer实例的资源，如NettyReactiveWebServerFactory生产WebServer方法：

	public WebServer getWebServer(HttpHandler httpHandler) {
		HttpServer httpServer = createHttpServer();
		ReactorHttpHandlerAdapter handlerAdapter = new ReactorHttpHandlerAdapter(
				httpHandler);
		return new NettyWebServer(httpServer, handlerAdapter, this.lifecycleTimeout);
	}

在创建NettyReactiveWebServer实例时需要一个参数HttpHandler。而且进而传入了一个HttpHandlerAdapter实例里，这是因为每个WebServer的接收处理接口的适配器是不一样的，在每个不同的WebServer工厂里通过不过的适配器去适配不同的实现。

• HttpHandler

上面在创建WebServer的时候，传了一个入参，类型就是Httphandler。为了适配不同的WebServer请求响应体，Spring设计了HttpHandler用来转化底层的Http请求响应语义，用来接收处理底层容器的Http请求。其结构如下：

package org.springframework.http.server.reactive;

import reactor.core.publisher.Mono;

public interface HttpHandler {
    Mono<Void> handle(ServerHttpRequest var1, ServerHttpResponse var2);
}

在Netty的实现中，Netty接收请求处理的适配器ReactorHttpHandlerAdapter的apply中转化的代码如下：

package org.springframework.http.server.reactive;

public class ReactorHttpHandlerAdapter implements BiFunction<HttpServerRequest, HttpServerResponse, Mono<Void>> {
    private static final Log logger = HttpLogging.forLogName(ReactorHttpHandlerAdapter.class);
    private final HttpHandler httpHandler;

    public ReactorHttpHandlerAdapter(HttpHandler httpHandler) {
        Assert.notNull(httpHandler, "HttpHandler must not be null");
        this.httpHandler = httpHandler;
    }

    public Mono<Void> apply(HttpServerRequest reactorRequest, HttpServerResponse reactorResponse) {
        NettyDataBufferFactory bufferFactory = new NettyDataBufferFactory(reactorResponse.alloc());

        try {
            ReactorServerHttpRequest request = new ReactorServerHttpRequest(reactorRequest, bufferFactory);
            ServerHttpResponse response = new ReactorServerHttpResponse(reactorResponse, bufferFactory);
            if (request.getMethod() == HttpMethod.HEAD) {
                response = new HttpHeadResponseDecorator((ServerHttpResponse)response);
            }

            return this.httpHandler.handle(request, (ServerHttpResponse)response).doOnError((ex) -> {
                logger.trace(request.getLogPrefix() + "Failed to complete: " + ex.getMessage());
            }).doOnSuccess((aVoid) -> {
                logger.trace(request.getLogPrefix() + "Handling completed");
            });
        } catch (URISyntaxException var6) {
            if (logger.isDebugEnabled()) {
                logger.debug("Failed to get request URI: " + var6.getMessage());
            }

            reactorResponse.status(HttpResponseStatus.BAD_REQUEST);
            return Mono.empty();
        }
    }
}

 

• WebHandler

其实一般来讲设计到HttpHandler这一层级基本就差不多了，有一致的请求体和响应体了。但是Spring说还不够，对Web开发来讲不够简洁，就又造了一个WebHandler，WebHandler架构更简单，如下：

public interface WebHandler {
	Mono<Void> handle(ServerWebExchange exchange);
}

这回够简洁了，只有一个入参，那请求提和响应体去哪里了呢？被包装到ServerWebExchange中了。我么看下当HttpHandler接收到请求后，是怎么处理然后在调用WebHandler的，最终处理HttpHandler实现是HttpWebHandlerAdapter.java,通过其内部的createExchange方法将请求和响应体封装在ServerWebExchange中了。其handle代码如下：

public Mono<Void> handle(ServerHttpRequest request, ServerHttpResponse response) {
		if (this.forwardedHeaderTransformer != null) {
			request = this.forwardedHeaderTransformer.apply(request);
		}
 
		ServerWebExchange exchange = createExchange(request, response);
 
		LogFormatUtils.traceDebug(logger, traceOn ->
				exchange.getLogPrefix() + formatRequest(exchange.getRequest()) +
						(traceOn ? ", headers=" + formatHeaders(exchange.getRequest().getHeaders()) : ""));
 
		return getDelegate().handle(exchange)
				.doOnSuccess(aVoid -> logResponse(exchange))
				.onErrorResume(ex -> handleUnresolvedError(exchange, ex))
				.then(Mono.defer(response::setComplete));
	}

• HandlerMapping

首先看下HandlerMapping的构造,可以看到就是根据web交换器返回了一个Handler对象:

public interface HandlerMapping {
	String BEST_MATCHING_HANDLER_ATTRIBUTE = HandlerMapping.class.getName() + ".bestMatchingHandler";
	String BEST_MATCHING_PATTERN_ATTRIBUTE = HandlerMapping.class.getName() + ".bestMatchingPattern";
	String PATH_WITHIN_HANDLER_MAPPING_ATTRIBUTE = HandlerMapping.class.getName() + ".pathWithinHandlerMapping";
	String URI_TEMPLATE_VARIABLES_ATTRIBUTE = HandlerMapping.class.getName() + ".uriTemplateVariables";
	String MATRIX_VARIABLES_ATTRIBUTE = HandlerMapping.class.getName() + ".matrixVariables";
	String PRODUCIBLE_MEDIA_TYPES_ATTRIBUTE = HandlerMapping.class.getName() + ".producibleMediaTypes";
	Mono<Object> getHandler(ServerWebExchange exchange);
}

上面的“请求“已经到WebHandler了，那么最终是怎么到我们定义的控制器接口的呢？其实，没有HandlerMapping,Spring WebFlux的功能也是完整的，也是可编程的，因为可以基于WebHandler直接编码。我们最弄的一个网关最后就是直接走自定义的WebHandler，根本没有HandlerMapping的什么事情，但是你这么做的话就失去了Spring编码的友好性了。WebFlux的初始化过程中，会去Spring上下文中找name是“webHandler”的的WebHandler实现。默认情况下，Spring会在上下文中初始化一个DispatcherHandler.java的实现，Bean的name就是“webHandler”。这个里面维护了一个HandlerMapping列表，当请求过来时会迭代HandlerMapping列表，返回一个WebHandler处理，代码如下：

public Mono<Void> handle(ServerWebExchange exchange) {
		if (this.handlerMappings == null) {
			return Mono.error(HANDLER_NOT_FOUND_EXCEPTION);
		}
		return Flux.fromIterable(this.handlerMappings)
				.concatMap(mapping -> mapping.getHandler(exchange))
				.next()
				.switchIfEmpty(Mono.error(HANDLER_NOT_FOUND_EXCEPTION))
				.flatMap(handler -> invokeHandler(exchange, handler))
				.flatMap(result -> handleResult(exchange, result));
	}

• ReactiveWebServerApplicationContext

WebFlux的启动都在Reactive的上下文中完成，和WebMvc类似，Mvc也有一个ServletWebServerApplicationContext，他们是同宗同脉的。ReactiveWebServerApplicationContext还有一个父类AnnotationConfigReactiveWebServerApplicationContext，在Spring boot启动中，创建的就是这个父类的实例。在Spring boot的run()方法中创建上下文时有如下代码：

protected ConfigurableApplicationContext createApplicationContext() {
		Class<?> contextClass = this.applicationContextClass;
		if (contextClass == null) {
			try {
				switch (this.webApplicationType) {
				case SERVLET:
					contextClass = Class.forName(DEFAULT_SERVLET_WEB_CONTEXT_CLASS);
					break;
				case REACTIVE:
					contextClass = Class.forName(DEFAULT_REACTIVE_WEB_CONTEXT_CLASS);
					break;
				default:
					contextClass = Class.forName(DEFAULT_CONTEXT_CLASS);
				}
			}
			catch (ClassNotFoundException ex) {
				throw new IllegalStateException(
						"Unable create a default ApplicationContext, "
								+ "please specify an ApplicationContextClass",
						ex);
			}
		}
		return (ConfigurableApplicationContext) BeanUtils.instantiateClass(contextClass);
	}

总结

WebFlux里面启动流程太复杂，全盘脱出写的太长严重影响阅读体验。所以上面权当抛砖引玉，开一个好头。不过，WebFlux的启动流程节点博主都已分析并整理成流程图了，结合上面的接口设计分析，搞懂WebFlux的设计及工作原理应该冒点问题。

参考地址：http://www.kailing.pub/article/index/arcid/249.html

---