webflux的探索与实战 - 零：技术选型

法欧特斯卡雷特_Official
1,011 阅读7分钟

零

上回书讲到了项目的意义与业务主题，那么这次就来简单讲讲有关这个项目的技术选型。

知其愚者，非大愚；知其惑者，非大惑也。

技术选型

很明显，这次我也打算长篇大论了。这篇章节我不仅会简单介绍一下技术选型，还会简单讲一讲其中一部分技术选型的过程。

首先，整个服务端的主要技术我倒是在一开始就想好了：

  • Gradle + kotlin dsl script 构建项目。
  • 使用Java17。
  • 使用SpringCloud，毕竟要做的是微服务架构。
  • 使用Spring Webflux。
  • R2DBC + MySQL
  • 使用Nacos作为配置中心，进行服务发现。
  • 喜闻乐见Lombok。

Gradle + kts

首先，讲讲为什么要用Gradle。其实最开始选择Gradle的原因非常简单：我想学。

Maven是有极限的。我从漫长的项目构建过程中学到一件事......越是想要灵活的进行项目配置，就越会发现Maven是有极限的......除非超越XML配置。因此————！

因此我选择了使用Gradle。大家都知道，Maven与Gradle最大也是最显著的区别就是他们的配置方式。Maven使用较为传统的XML文件进行配置。尽管Maven有很多插件可以使用，但是依旧有着很大的局限性。

而Gradle使用脚本文件进行项目配置，其灵活度是很高的。你可以编写代码写更加复杂灵活的逻辑，而不是被限制在pom.xml中既定的选项中。

那么第二个问题：什么是kts？其实就是kotlin为gradle服务的dsl脚本。最简单的来说，就是使用kotlin语法来代替groovy的语法，把项目中的 build.gradle 文件变成了 build.gradle.kts。

至于我为什么要选择这个，理由也很简单：我更熟悉kotlin。至于kts的构建和groovy脚本的构建之间其他更深层的区别和各自的优势，说实话，我的确没有认真的调研过。不过，不也挺好的吗？

Java17

为什么选用Java17？这是一个好问题。问这个问题之前，首先反问一下自己：为什么不用Java17？

Java17是目前最新的LTS版本，上一个是11，再上一个是8。我听说，Spring 6 以及 Springboot 3 未来也都会基于Java17，而且它还支持免费商用。至少我觉得使用Java17没有什么问题。

当然了，调侃归调侃，我自己对Java17的了解也不够深。毕竟这是一个学习项目，首要目的就是学习。

68ed6884de90d2a59708732f974fea82.gif

Spring Cloud

没什么好说的。毕竟为了学习和找工作的项目，肯定要用写大家都爱看到的。而且对于微服务的项目架构设计也是一个很好的挑战。

7a2ddda7b3087ee91cab4ddf2a7af332.jpeg

Spring Webflux

这就是个比较有意思的话题了，为什么要用Spring Webflux。首先什么是Spring Webflux，对它感兴趣的可以去阅读下 官方文档[1] 的说明和概述，配合翻译软件实际上应该还是挺好懂的。

简单来说，Webflux就是一种非阻塞的响应式框架。不同于传统的基于Servlet API设计的Spring Web MVC，是完全非阻塞的，在Netty、Undertow和Servlet 3.1+容器等服务器上，并能够更加有效的利用各种资源，比如你宝贵的线程。

当然，对Spring Webflux感兴趣的原因之一也是我对于kotlin协程愈发的熟悉以及对响应式编程的感兴趣。实际上，Spring也早已对kotlin进行了各种方面的支持[2][3]。我虽然非常想直接使用Kotlin进行Spring的响应式编程（这样也可以更好的使用Kotlin平台下的非阻塞ORM库了），但是这次的主题是使用Java，所以我只能忍痛割爱了。😭

其实webflux大家也未必完全未接触过，Spring Cloud Gateway就是使用的Spring webflux。如果感兴趣，你可以参考阅读它的官方文档[4]。而且顺便一提，这个项目所要使用的网关就是Spring Cloud Gateway。

[1]Spring Webflux : docs.spring.io/spring-fram…

[2]Spring对Kotlin的支持 : docs.spring.io/spring-fram…#kotlin

[3]Spring对Kotlin协程的支持 : docs.spring.io/spring-fram…#coroutines

[4]Spring Cloud Gateway : spring.io/projects/sp…

R2DBC + MySQL

实际上，现在从百度上搜索诸如“Spring webflux 实战 项目”之类的关键字，鲜有干活可寻。绝大多数文章都是顶着“入门”的帽子教你写一个简单的Controller Demo就草草了事，最多最多给你一个整合redis的示例，就难以深入了。更有甚者，Demo里用了各种奇奇怪怪的方式，经常会误导后来者（比如曾经的我）。

af97aa330796369dbc227aa41d1d9cb6.png

搜索结果

f47cffa9047d899d3b2c8545eacf31bc.png

只讲了redis

3a9449b1beb88f74088621df478f99b7.png

假的数据访问层

4fc39ffcc749af32fadfa30682ce23f4.png

“干货”视频

也许，依然会有干货满满的知识分享贴，只不过我没有找到，但是实在也是没有耐心继续翻找下去了。

这是为什么呢？或许是Spring webflux实际上本身属于一个较为颠覆性的技术（相对于传统阻塞式的servlet），又相对比较新颖，因此乐意研究使用它的人本身就少，愿意为其写篇文章的人则更是少之又少。当然这只是一些不靠谱的猜测，真正的原因我肯定是不知道了。也许对于一些培训机构来讲可能会有收费课程，但是对于网络上的文章来讲，你其实很难发现一些有价值的内容。

那么回到副标题，什么是R2DBC？首先，你可以参考它们的官方网站[1]。引用它们的介绍原文和译文：

原文：The Reactive Relational Database Connectivity (R2DBC) project brings reactive programming APIs to relational databases.

译文：反应式关系型数据库连接（R2DBC）项目为关系型数据库带来了反应式编程API。(via DeepL.)

说白了，传统的JDBC是一套阻塞的数据库API，那么R2DBC就是一套适应响应式编程的响应式API。那么为什么会提到这个R2DBC呢？

在使用JDBC的时候（当然你有可能不直接使用JDBC），Spring-Data家族里有一员叫做 Spring-Data-JDBC[2]。说到这里，我想你应该知道我想说什么了吧，对的，Spring-Data同样为了响应式框架提供了一个 Spring-Data-R2DBC[3]，来提供对数据库的响应式操作的支持。有了R2DBC，就能够愉快的在Spring Webflux中使用数据库了。

根据官方文档的指引，要想通过 Spring-Data-R2DBC 操作MySQL，我们需要一个实现了R2DBC的数据库驱动。我选择了官方所列举出的驱动之一： dev.miku:r2dbc-mysql[4] 。

[1]R2DBC : r2dbc.io/

[2]Spring-Data-JDBC : spring.io/projects/sp…

[3]Spring-Data-R2DBC : spring.io/projects/sp…

[4]dev.miku:r2dbc-mysql : github.com/mirromutth/…

Nacos

想必各位对Nacos应该已经不是很陌生了。当然，如果陌生也没有关系，你可以前往官方网站[1] 对其进行一个简单的了解。

引用其官方的一句话就是：

一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台。

是的，一个用于动态服务发现、配置管理、服务管理的平台。你可以简单的理解为配置中心和服务注册中心。

其实Nacos我曾经对其的使用也不过只是简单的服务注册中心，这一次作为配置中心使用还是第一次呢。

026b3fa7142282a5958ec8d7928e148c.jpeg

[1]Nacos : nacos.io/zh-cn/index…

Lombok

没什么好说的，懒人标配。“干货”视频

收尾

第零章第二篇到这里就结束了，以上就是大部分的技术选型以及选择它们的原因了。不知道你是否能看到这里呢？如果看到了，那么十分感激。

对于所有的技术总结文章，我也会像本篇一样，尽可能的附上所有我有所参考的文档链接，供大家参阅。

就是这样，感谢您的阅读，我们下一篇再见。

avatar
文章
阅读
粉丝