Microsoft Word - 朱晔和你聊Spring系列S1E5：Spring WebFlux小探.docx

Size: px

Start display at page:

Download "Microsoft Word - 朱晔和你聊Spring系列S1E5：Spring WebFlux小探.docx"

锵怀
5 years ago
Views:

1 朱晔和你聊 Spring 系列 S1E5:Spring WebFlux 小探本文会来做一些应用对比 Spring MVC 和 Spring WebFlux, 观察线程模型的区别, 然后做一下简单的压力测试创建一个传统的 Spring MVC 应用先来创建一个新的 webflux-mvc 的模块 : <?xml version="1.0" encoding="utf-8"?> <project xmlns=" xmlns:xsi=" xsi:schemalocation=" <modelversion>4.0.0</modelversion> <groupid>me.josephzhu</groupid> <artifactid>spring101-webflux-mvc</artifactid> <version>0.0.1-snapshot</version> <packaging>jar</packaging> <name>spring101-webflux-mvc</name> <description></description> <parent> <groupid>me.josephzhu</groupid> <artifactid>spring101</artifactid> <version>0.0.1-snapshot</version> </parent> <dependencies> <dependency> <groupid>org.springframework.boot</groupid> <artifactid>spring-boot-starter-data-mongodb</artifactid> </dependency> <dependency> <groupid>org.springframework.boot</groupid> <artifactid>spring-boot-starter-web</artifactid> </dependency> </dependencies>

2 <build> <plugins> <plugin> <groupid>org.springframework.boot</groupid> <artifactid>spring-boot-maven-plugin</artifactid> </plugin> </plugins> </build> </project> 然后在项目里定义一个我们会使用到的 POJO: package me.josephzhu.spring101webfluxmvc; import lombok.allargsconstructor; import lombok.data; import lombok.noargsconstructor; import org.springframework.data.annotation.id; = "mydata") public class MyData private String id; private String payload; private long time; 是为 Mongodb 服务的, 我们定义了 MyData 将会以 mydata 作为 Collection 的名字, 然后 id 字段是 Document 的 Id 列然后我们来创建 Controller, 在这个 Controller 里面我们尝试三种不同的操作 : 1. Sleep 100ms 的纯获取数据的方法从请求中获得 length 参数作为 payload 字符串的长度, 从请求中获得 size 参数作为 MyData 的个数我们在之后的测试过程中可以随意调节这两个参数来调整我们的数据量 2. 从 Mongodb 获取数据的方法, 获取到数据后直接返回 3. 复合逻辑先走 HTTP 请求从 data 方法获取数据, 然后把数据保存进入 Mongodb, 最后返回这些数据 package me.josephzhu.spring101webfluxmvc;

3 import org.springframework.beans.factory.annotation.autowired; import org.springframework.core.parameterizedtypereference; import org.springframework.http.httpmethod; import org.springframework.http.responseentity; import org.springframework.web.bind.annotation.getmapping; import org.springframework.web.bind.annotation.requestparam; import org.springframework.web.bind.annotation.restcontroller; import org.springframework.web.client.resttemplate; import org.springframework.web.util.uricomponentsbuilder; import java.util.list; import java.util.uuid; import java.util.stream.collectors; import public class MyController private RestTemplate private MyRepository public List<MyData> getdata(@requestparam(value = "size", defaultvalue = "10") int size,@requestparam(value = "length", defaultvalue = "100") int length) { try { Thread.sleep(100); catch (InterruptedException e) { String payload = IntStream.rangeClosed(1,length).mapToObj(i->"a").collect(Collectors.joining()); return IntStream.rangeClosed(1, size).maptoobj(i->new MyData(UUID.randomUUID().toString(), payload, public List<MyData> getdbdata() { return

4 public List<MyData> = "size", defaultvalue = "10") int size,@requestparam(value = "length", defaultvalue = "100") int length){ UriComponentsBuilder builder = UriComponentsBuilder.fromHttpUrl(" size).queryparam("length", length); ResponseEntity<List<MyData>> responseentity = resttemplate.exchange(builder.touristring(), HttpMethod.GET, null, new ParameterizedTypeReference<List<MyData>>() {); return responseentity.getbody().stream().map(myrepository::save).collect(collectors.tolist()) ; 注意, 在这里我们使用了 Java 8 的 Steam 来做一些操作避免使用 for 循环 : 1. 通过 length 参数构建 payload(payload 由 length 个字符 a 构成 ) 2. 通过 size 参数构建 MyData 的 List 3. 在 RestTemplate 获取到 MyData 的 List 后, 把每一个对象交由 myrepository 的 save 方法来处理, 然后统一收集返回结果这些 Stream 的代码都是同步处理, 也不涉及外部 IO, 和非阻塞没有任何关系, 只是方便代码编写为了让代码可以运行, 我们还需要继续来配置下 Mongodb 的 Repository: package me.josephzhu.spring101webfluxmvc; import org.springframework.data.mongodb.repository.mongorepository; import public interface MyRepository extends MongoRepository<MyData, String> { 因为我们没有用到复杂的查询, 在代码里只是用到了 findall 方法, 所以这里我们无需定义额外的方法, 只是声明接口即可最后, 我们创建主应用程序, 顺便配置一下 Mongodb 和 RestTemplate: package me.josephzhu.spring101webfluxmvc; import com.mongodb.mongoclientoptions; import org.springframework.boot.springapplication; import org.springframework.boot.autoconfigure.springbootapplication; import org.springframework.boot.web.client.resttemplatebuilder; import org.springframework.context.annotation.bean; import org.springframework.context.annotation.configuration; import org.springframework.web.client.resttemplate;

5 public class Spring101WebfluxMvcApplication MongoClientOptions mongoclientoptions(){ return public RestTemplate resttemplate(resttemplatebuilder builder) { return builder.build(); public static void main(string[] args) { SpringApplication.run(Spring101WebfluxMvcApplication.class, args); 这里我们配置了 Mongodb 客户端使得之后在进行压力测试的时候能有超过 100 个连接连接到 Mongodb, 否则会出现无法获取连接的问题创建 WebFlux 版本的应用现在我们再来新建一个 webflux 模块 : <?xml version="1.0" encoding="utf-8"?> <project xmlns=" xmlns:xsi=" xsi:schemalocation=" <modelversion>4.0.0</modelversion> <groupid>me.josephzhu</groupid> <artifactid>spring101-webflux</artifactid> <version>0.0.1-snapshot</version> <packaging>jar</packaging> <name>spring101-webflux</name> <description></description> <parent> <groupid>me.josephzhu</groupid>

6 <artifactid>spring101</artifactid> <version>0.0.1-snapshot</version> </parent> <dependencies> <dependency> <groupid>org.springframework.boot</groupid> <artifactid>spring-boot-starter-data-mongodb-reactive</artifactid> </dependency> <dependency> <groupid>org.springframework.boot</groupid> <artifactid>spring-boot-starter-webflux</artifactid> </dependency> <dependency> <groupid>io.projectreactor</groupid> <artifactid>reactor-test</artifactid> <scope>test</scope> </dependency> </dependencies> <build> <plugins> <plugin> <groupid>org.springframework.boot</groupid> <artifactid>spring-boot-maven-plugin</artifactid> </plugin> </plugins> </build> </project> 这里可以注意到, 我们引入了 webflux 这个 starter 以及 data-mongodb-reactive 这个 starter 在之前的 Spring MVC 项目中, 我们引入的是 mvc 和 data-mongodb 两个 starter 然后, 我们同样需要创建一下 MyData 类 ( 代码和之前一模一样, 这里省略 ) 最关键的一步, 我们来创建三个 Controller 方法的定义 : package me.josephzhu.spring101webflux; import org.springframework.beans.factory.annotation.autowired; import org.springframework.http.mediatype; import org.springframework.stereotype.component; import org.springframework.web.reactive.function.client.webclient;

7 import org.springframework.web.reactive.function.server.serverrequest; import org.springframework.web.reactive.function.server.serverresponse; import reactor.core.publisher.flux; import reactor.core.publisher.mono; import java.time.duration; import java.util.uuid; import java.util.stream.collectors; import java.util.stream.intstream; import static public class MyHandler private MyReactiveRepository myreactiverepository; public Mono<ServerResponse> getdata(serverrequest serverrequest) { int size = Integer.parseInt(serverRequest.queryParam("size").orElse("10")); int length = Integer.parseInt(serverRequest.queryParam("length").orElse("100")); String payload = IntStream.rangeClosed(1,length).mapToObj(i->"a").collect(Collectors.joining()); Flux<MyData> data = Flux.fromStream(IntStream.rangeClosed(1, size).maptoobj(i->new MyData(UUID.randomUUID().toString(), payload, System.currentTimeMillis()))).delaySequence(Duration.ofMillis(100)); return ok().contenttype(mediatype.application_json).body(data, MyData.class); public Mono<ServerResponse> getdbdata(serverrequest serverrequest) { Flux<MyData> data = myreactiverepository.findall(); return ok().contenttype(mediatype.application_json).body(data, MyData.class); public Mono<ServerResponse> savedata(serverrequest serverrequest) { int size = Integer.parseInt(serverRequest.queryParam("size").orElse("10")); int length = Integer.parseInt(serverRequest.queryParam("length").orElse("100"));

8 Flux<MyData> data = WebClient.create().get().uri(builder -> builder.scheme("http").host("localhost").port(8080).path("data").queryparam("size", size).queryparam("length", length).build()).accept(mediatype.application_json).retrieve().bodytoflux(mydata.class).flatmap(myreactiverepository::save); return ok().contenttype(mediatype.application_json).body(data, MyData.class); 这里要说明几点 : 1. 在 WebFlux 中, 方式来定义 Controller, 也可以采用函数式方式来声明对外的 Endpoint, 也就是声明 Handler+Router 我们这里采用的是更有特色的后者来演示 2. 请你比较一下三个方法的实现对于两个版本的区别最主要的区别, 我们返回的实际数据是 Mono<> 和 Flux<>, 分别代表 0~1 个对象和 0~N 对象的响应式流 3. 在 savedata 方法中, 对于 Spring MVC 我们使用的是阻塞的 RestTemplate 来从远端获取数据, 对于 Spring WebFlux 我们使用的是非阻塞的 WebClient 来获取数据获取数据后, 我们直接使用 flatmap 获取到了所有的 MyData 转给我们的响应式的 Mongodb Repository 来处理数据 4. 对于 savedata 方法中插入 Mongodb 的操作, 这里和 MVC 的例子有很大的不同需要注意在 MVC 中, 我们把远程服务返回的结果转为 Stream 数据流, 同步依次调用 save 方法, 整个过程只会有占用一个 Mongodb 的连接而在这里, 直接对 Flux 流进行了 Map, 整个过程相当于并发进行了 Mongodb 的调用在之后做压测的时候, 我们会再次提到这点刚才有提到, 采用函数式声明对外的 Endpoint 的话除了定义 Handler, 还需要配置 Router 来和 Handler 关联, 配置如下 : package me.josephzhu.spring101webflux; import org.springframework.beans.factory.annotation.autowired; import org.springframework.context.annotation.bean;

9 import org.springframework.context.annotation.configuration; import org.springframework.web.reactive.function.server.routerfunction; import org.springframework.web.reactive.function.server.serverresponse; import static org.springframework.web.reactive.function.server.requestpredicates.get; import static public class RouterConfig private MyHandler public RouterFunction<ServerResponse> config() { return route(get("/data"), myhandler::getdata).androute(get("/dbdata"), myhandler::getdbdata).androute(get("/savedata"), myhandler::savedata); 这段代码没有太多需要说明, 这里我们定义了三个 GET 请求 ( 相当于 MVC 然后对应到注入的 myhandler 的三个方法上然后我们还需要创建 Mongodb 的 Repository: package me.josephzhu.spring101webflux; import org.springframework.data.mongodb.repository.reactivemongorepository; import public interface MyReactiveRepository extends ReactiveMongoRepository<MyData, String> { 以及配置和启动类 : package me.josephzhu.spring101webflux; import com.mongodb.connectionstring; import com.mongodb.async.client.mongoclientsettings; import com.mongodb.connection.clustersettings; import com.mongodb.connection.connectionpoolsettings; import com.mongodb.reactivestreams.client.mongoclient; import com.mongodb.reactivestreams.client.mongoclients; import org.springframework.boot.springapplication; import org.springframework.boot.autoconfigure.springbootapplication; import org.springframework.context.annotation.bean;

10 public class Spring101WebfluxApplication MongoClient mongoclient(){ return MongoClientSettings mongoclientsettings(){ return MongoClientSettings.builder().clusterSettings(ClusterSettings.builder().applyConnectionString(new ConnectionString("mongodb://localhost")).build()).connectionPoolSettings(ConnectionPoolSettings.builder().minSize(200).ma xsize(1000).maxwaitqueuesize( ).build()).build(); public static void main(string[] args) { SpringApplication.run(Spring101WebfluxApplication.class, args); 这里对 Mongodb 做了一些配置, 主要也是希望放大连接池这块的默认限制, 为今后的压测服务注意, 在这里配置的 Bean 是 com.mongodb.reactivestream.client 下的 MongoClient, 如下图所示, 还有其它两个 MongoClient, 如果修改了不匹配的 MongoClient 的话是不会有作用的, 我在这个坑里躺了两小时完成后可以打开浏览器测试一下接口 :

11 Spring MVC 还是 WebFlux? 下图是官网的一个图说明了两者的关系, 然后官网也给出了一些建议 : 1. 如果你现在的 Spring MVC 运行的没啥问题的话就别改了, 有大量的类库可以使用, 实现简单易于理解 2. 如果你希望实现轻量级的, 函数式 Web 框架, 那么可以考虑 WebFlux 的函数 Web 端点 3. 如果你依赖阻塞的持久化 API 比如 JPA 和 JDBC 那么也就只能选择 Spring MVC 了目前对于非阻塞的 JDBC 实现有一些早期的项目在探索, 但是没有到可以上生产的成熟度 4. 在 Spring MVC 应用程序中进行远程调用也是可以使用响应式的 WebClient 的 Spring MVC 也可以使用其它的响应式组件每次调用延迟越厉害受益越大 5. 对于大型应用程序要考虑到非阻塞方式实现的学习曲线最简单的起步方式就是使用 WebClient, 完全切换到非阻塞需要花时间熟悉函数式声明式的编程 API

官方的意思也是可以在一些小引用上尝试 WebFlux, 对于大型应用不建议冒然转到 WebFlux 观察线程模型我们知道对于阻塞的实现方式, 我们采用线程池来服务请求 ( 线程池中的会维护一组普通的线程, 线程池只是节省线程创建的时间 ), 对于每一个请求的处理, 至始至终都是在一个线程中进行, 如果处理的过程中我们需要访问外部的网络或数据库, 那么线程就处于阻塞状态,

12 官方的意思也是可以在一些小引用上尝试 WebFlux, 对于大型应用不建议冒然转到 WebFlux 观察线程模型我们知道对于阻塞的实现方式, 我们采用线程池来服务请求 ( 线程池中的会维护一组普通的线程, 线程池只是节省线程创建的时间 ), 对于每一个请求的处理, 至始至终都是在一个线程中进行, 如果处理的过程中我们需要访问外部的网络或数据库, 那么线程就处于阻塞状态, 这个线程无法服务其它请求, 如果当时还有更多的并发的话, 就需要创建更多的线程来服务其它请求这种实现方式是非常简单的, 应对压力的增长扩容方式也是粗暴的, 那就是增加更多线程对于非阻塞的方式, 采用的是 EventLoop 的方式,IO 操作的时候是不占用工作线程的, 因此只会创建一组和 CPU 核数相当的工作线程用于工作处理 (NodeJS 甚至是单线程的, 这种就更危险了, 就那么一个工作线程, 一旦被长时间占用其它请求都无法处理 ) 由于整个处理过程中 IO 请求不占用线程时间, 线程不会阻塞等待, 再增加超过 CPU 核数的工作线程也是没有意义的 ( 只会白白增加线程切换的开销 ) 对于这种方式在压力增长后, 因为我们不需要增加额外的线程, 也就没有了绝对的瓶颈试想一下在阻塞模型下, 对于 5000 的并发, 而且每一个并发阻塞的时间非常长, 那么我们其实需要 5000 个线程来服务 ( 这么多线程 99% 其实都是在等待, 属于空耗系统资源 ), 创建 5000 的线程不谈其它的, 如果线程栈大小是 1M 的话就需要 5GB 的内存对于非阻塞的线程模型在 8 核机器上还是 8 个工作线程, 内存占用还是这么小, 可以以最小的开销应对大并发, 系统的损耗很少非阻塞的 Reactive 模式是内耗非常小的模式, 但是这是有代价的, 在实现上我们需要确保处理过程中没有阻塞产生, 否则就会浪费宝贵的数目固定的工作线程, 也就是说我们需要依赖配套的非阻塞 IO 类库来使用

13 在默认情况下 tomcat 的工作线程池初始化为 10, 最大 200, 我们通过启动本文创建的 Spring101WebfluxMvcApplication 程序, 用 jvisualvm 工具来看下初始的情况 (35 个线程 ): 在项目的 application.properties 文件中我们配置 tomcat 的最大线程数 : server.tomcat.max-threads=250 在压力的情况下, 我们再来观察一下线程的情况 (272 个线程 ):

14 的确是创建多达 250 个工作线程这里看到大部分线程都在休眠, 因为我们这里运行的是刚才的 data() 方法, 在方法内我们休眠了 100 毫秒对于同样的压力, 我们再来看一下 Spring101WebfluxApplication 程序的线程情况 (44 个线程 ):

15 可以看到用于处理 HTTP 的 Reactor 线程只有 8 个, 和本机 CPU 核数量一致 ( 下面有十个 Thread 打头的线程是处理和 Mongodb 交互的, 忽略 ), 只需要这 8 个线程处理 HTTP 请求足以, 因为 HTTP 请求的 IO 处理不会占用线程使用 Gatling 进行压力测试我们可以使用 Gatling 类库进行压力测试, 我个人感觉比 Jmeter 方便配置很简单, 首先我们要安装 Scala 的 SDK, 然后我们新建一个模块 : <?xml version="1.0" encoding="utf-8"?> <project xmlns:xsi=" xmlns=" xsi:schemalocation=" <modelversion>4.0.0</modelversion> <groupid>me.josephzhu</groupid> <artifactid>spring101-webstresstest</artifactid> <version>0.0.1-snapshot</version> <packaging>jar</packaging> <name>spring101-webstresstest</name> <description></description>

16 <dependencies> <dependency> <groupid>io.gatling.highcharts</groupid> <artifactid>gatling-charts-highcharts</artifactid> <version>2.3.1</version> </dependency> </dependencies> <build> <plugins> <plugin> <groupid>io.gatling</groupid> <artifactid>gatling-maven-plugin</artifactid> <version>2.2.4</version> <configuration> <simulationclass>me.josephzhu.spring101.webstresstest.stresstest</simulationclass> <resultsfolder>/users/zyhome/gatling</resultsfolder> </configuration> </plugin> </plugins> </build> </project> 引入了 garling 的 maven 插件, 在这里配置了测试结果输出路径以及压测的类接下去创建一下这个 Scala 测试类 : package me.josephzhu.spring101.webstresstest import io.gatling.core.predef._ import io.gatling.core.scenario.simulation import io.gatling.http.predef._ class StressTest extends Simulation { val scn = scenario("data").repeat(1000) { exec( http("data").get(" "application/json").check(status.is(200)).check(substring("payload"))) setup(scn.inject(atonceusers(200)))

17 这段代码定义了如下的测试行为 : 1. 声明一个 data 测试场景, 重复进行 1000 次测试, 发起一个远程调用, 验证调用结果的响应状态码是 200 并且返回的结果包含字符串 payload 2. 测试启动的时候直接压上去 200 个用户, 每一个用户运行完这 1000 次测试后结束了, 所以这种方式一开始会是 200 用户到测试最后阶段用户数会慢慢减少当然还有其它一些测试方式 ( 比如慢慢递增用户的方式 ), 详见官网 : nothingfor(4 seconds), // 1 atonceusers(10), // 2 rampusers(10) over (5 seconds), // 3 constantuserspersec(20) during (15 seconds), // 4 constantuserspersec(20) during (15 seconds) randomized, // 5 rampuserspersec(10) to 20 during (10 minutes), // 6 rampuserspersec(10) to 20 during (10 minutes) randomized, // 7 splitusers(1000) into (rampusers(10) over (10 seconds)) separatedby (10 seconds), // 8 splitusers(1000) into (rampusers(10) over (10 seconds)) separatedby atonceusers(30), // 9 heavisideusers(1000) over (20 seconds) // 10 压力测试一先来进行第一个测试,1000 并发对 data 接口进行 100 次循环 ( 还记得吗, 接口有 100ms 休眠 or 延迟的 ): class StressTest extends Simulation { val scn = scenario("data").repeat(100) { exec( http("mvc data").get(" "application/json").check(status.is(200)).check(substring("payload"))) setup(scn.inject(atonceusers(1000)))

18 下面两个图分别是 MVC 和 WebFlux 的测试结果 ( 因为都是 8080 端口, 所以测试的时候记得切换重启两个应用哦 ):

19 可以看到 WebFlux 的吞吐几乎是 MVC 的翻倍, 平均响应时间少了两倍不止, 很明显, 在等待的时候,2000 个并发用户大大超过了我们配置的 250 个线程池的线程数量, 这个时候只能排队, 对于非阻塞的方式, 延迟是不会占用处理线程的, 在延迟结束后才会去占用处理线程的资源进行处理, 不会收到并发用户数受限于线程池线程数的情况我们把 Sleep 相关代码注释再进行一次测试看看情况, 分别是 MVC 和 WebFlux:

这个时候 WebFlux 优势没有那么明显了性能测试二现在我们来访问一下 http://localhost:8080/savedata?

21 这个时候 WebFlux 优势没有那么明显了性能测试二现在我们来访问一下接口往 Mongodb 来初始化 100 条数据, 然后修改一下测试脚本压测 dbdata 接口 : class StressTest extends Simulation { val scn = scenario("data").repeat(100) { exec( http("data").get(" "application/json").check(status.is(200)).check(substring("payload")))

22 setup(scn.inject(atonceusers(1000))) 下面看下这次的测试结果, 分别是 MVC 和 WebFlux:

23 吞吐量没有太多提高, 平均响应时间快不少性能测试三再来试一下第三个 savedata 接口的情况修改测试代码 : class StressTest extends Simulation { val scn = scenario("data").repeat(100) { exec( http("data").get(" "application/json").check(status.is(200)).check(substring("payload"))) setup(scn.inject(atonceusers(200)))

24 这里我们修改并发用户为 200, 每个用户进行 100 次测试, 每次测试存入 Mongodb 5 条 100KB 的数据, 一次测试后总数据量在 10 万条这次测试我们并没有使用 1000 并发用户, 原因是这个测试我们会先从远端获取数据然后再存入 Mongodb, 远端的服务也是来自于当前应用程序, 我们的 Tomcat 最多只有 250 个线程, 在启动 1000 个用户后, 一些线程服务于 savedata 接口, 一些线程服务于 data 接口 (savedata 接口用到的 ), 这样相当于造成了循环依赖问题, 请求在等待更多的可用线程执行服务 data 接口的响应, 而这个时候线程又都被占了导致无法分配更多的请求, 测试几乎全部超时下面看下这次的测试结果, 分别是 MVC 和 WebFlux:

25 WebFlux 也是并发略高, 性能略好的优势对于响应时间的分布我们再来细看下下面的图 :

26 第一个图是 MVC 版本的响应时间分布, 可以看到抖动比第二个图的 WebFlux 的大不少最后来看看测试过程中 MVC 的 JVM 情况 (263 个线程 ): 以及 WebFlux 的 (41 线程 ):

性能测试四我们来测试一下下面两种情况下对于 WebFlux 版本 Mongodb 侧的情况 : class StressTest extends Simulation { val scn = scenario("data").repeat(1000) { exec( http("data").get("http://localhost:8080/savedata?

27 性能测试四我们来测试一下下面两种情况下对于 WebFlux 版本 Mongodb 侧的情况 : class StressTest extends Simulation { val scn = scenario("data").repeat(1000) { exec( http("data").get(" "application/json").check(status.is(200)).check(substring("payload"))) setup(scn.inject(atonceusers(200))) 以及 class StressTest extends Simulation { val scn = scenario("data").repeat(1000) { exec( http("data")

28 .get(" "application/json").check(status.is(200)).check(substring("payload"))) setup(scn.inject(atonceusers(200))) 区别就在远程服务返回的 Flux<MyData> 是 1 个还是 5 个在 1 个的时候运行测试可以看到我们 Mongodb 有 64 个连接 ( 需要把之前连接池的配置最小设置为小一点, 比如 50): > db.serverstatus().connections { "current" : 64, "available" : 3212, "totalcreated" : 8899 在 size 为 5 的时候,Flux<Data> 返回的是 5 个对象, 使用这个请求压测的时候 Mongodb 的连接数如下 : > db.serverstatus().connections { "current" : 583, "available" : 2693, "totalcreated" : 这是因为 Flux 拿到的数据直接以响应式进入 Mongodb, 并没有等到所有数据拿到之后串行调用方法总结一下这几次的测试, 我们发现 WebFlux 方式对于 MVC 方式能有略微的性能提升, 对于请求阻塞的时候性能优势明显我本金的测试并没有看到现象中的几倍甚至几十倍的性能提升, 我猜原因如下 : 1. 本机有性能瓶颈了, 压测客户端 Mongodb 服务器服务端都在本机运行, 干扰因素太多,CPU 的使用你争我夺, 测试不公平 2. 测试的时候 CPU 永远是 100% 还死机好几次, 我根本无法测试更高的并发, 无法完全把非阻塞的性能压出来 3. 我本机测试的时候走的是 localhost 而不是内网, 不经过物理网卡, 可能无法体现非阻塞的性能如果有条件可以使用三台独立服务器在内网进行 1 万以上并发用户的性能测试或许可以得到更科学的结果总结本文我们创建了 WebFlux 和 MVC 两套应用对比演示了简单返回数据发出远程请求使用 Mongodb 等一些简单的应用场景, 然后来看了一下 ThreadPerRequest 和 EventLoop 方

29 式线程模型的区别, 最后使用 Gatling 进行了几个 Case 的压力测试并且观察结果我觉得 : 1. 非阻塞模型肯定是好东西, 在 IO 压力和 IO 延迟很大的情况下, 非阻塞模型因为不需要更多的线程, 内耗小, 性能略好, 而且也稳定, 所以更利于高并发 2. WebFlux 的函数式和声明方式实现需要有很高的 API 熟悉使用门槛, 对于复杂的逻辑这种方式的实现比回调地狱更容易绕晕, 而且容易产生 Bug( 或许以后有可能响应式的编程在 API 上有可能和传统方式进行统一 ) 3. 目前和 WebFlux 配套的其它一些 Reactive 的库还不是很全面成熟, 要对复杂的业务逻辑全面启用响应式编程有点难, 阻塞调用不是不能在 WebFlux 中混用, 但是这种方式还是采用了线程池来处理, 现在容器也是 NIO 的了, 有又多大区别 4. 采用阻塞方式实现, 由阻塞的线程进行天然背压进行流控, 非阻塞方式很直接一竿子到底, 从外部请求直接到最底层存储, 需要做好流控, 这是非常容易产生问题的一个点, 当请求的处理无需通过线程来承载的时候, 前端压力会直通最底层数据源, 不收任何扩容方面的限制, 直接击溃底层 5. 对于阻塞的方式, 多线程的调度天然就是一个任务的负载均衡, 并不会出现太严重的卡死工作线程的问题, 非阻塞应用编程我们要有意识代码在哪个线程上运行, 如果是 reactor 线程的话千万不能长时间阻塞综上所述, 使用 WebFlux 进行响应式编程我个人认为目前只适合做类 IO 转发的高并发的又看中资源使用效率的应用场景 ( 比如 Gateway 网关服务 ), 对于复杂的业务逻辑不太适合, 在 90% 的情况下响应式的编程模型和线程模型不会享受大幅性能优势, 更不建议盲目把现有的应用使用 WebFlux 来重写当然, 这肯定是一个会持续发展的方向, 可以先接触研究起来

Microsoft Word - 朱晔和你聊Spring系列S1E7：简单好用的Spring Boot Actuator.docx

Microsoft Word - 朱晔和你聊Spring系列S1E7：简单好用的Spring Boot Actuator.docx 朱晔和你聊 Spring 系列 S1E7: 简单好用的 Spring Boot Actuator 本文会来看一下 Spring Boot Actuator 提供给我们的监控端点 Endpoint 健康检查 Health 和打点指标 Metrics 等所谓的 Production-ready( 生产环境必要的一些 ) 功能监控端点我们先来新建一个模块 :