使用Vert.x + SpringBoot编写业务系统 - 知乎

这一期文章主要为大家介绍如何将Vert.x与SpringBoot结合起来编写最最最常见的业务系统，即数据库增删改查。

谈两句SpringBoot

SpringBoot大家都很熟了，一个快速开发框架，其最大的特点是可将Spring应用打成可执行jar包，从而不再依赖外部容器，如Tomcat。可能绝大多数人在使用SpringBoot时一定离不了嵌入式Tomcat, 从而造成了一想到SpringBoot就会将其与SpringMVC联系在一起的现象。其实我们可以 只使用SpringBoot的一键执行和提供Spring环境的特性，Web层直接替换成Vert.x. 此外，一些短时执行的任务也可以用这种方式来写，简直不能更爽。

Vertx-web的请求路由

上一篇写的Http Server是没有路由的，所有的请求都会由同一个Handler处理。如果是只提供一个简单的API服务这样是没有问题的，但在实际业务系统中一般接口数量都比较多，这时候就需要一个路由组件来将不同的Path, Method映射到不同的handler上，使用方法如下：

          HttpServerserver=vertx.createHttpServer();Routerrouter=Router.router(vertx);// (0)router.route("/a/b/c/path")// (1).handler(BodyHandler.create())// (2).handler(demoHandler)// (3).blockingHandler(blockHandler);// (4)server.requestHandler(router::accept)// (5).listen(8080);

(0): 构造一个Router。

(1): 添加对 /a/b/c/path的路由。这里也可以使用重载的带有HTTP Method的方法。

(2): 当收到path为 /a/b/c/path的请求时，先调用 BodyHandler。这里 BodyHandler是Vert.x提供的处理器，只有在请求处理链路的开头添加了此Handler我们才能在后续的Handler中拿到请求体。

(3): 添加我们的业务处理器, 此处理器会在NIO线程中执行。

(4): 添加含有阻塞调用的业务处理器，此处理器会在worker线程池中执行，不会block NIO线程。

(5): 将Router的Handler设为整个HTTP Server的Handler。

其中Handler是一个函数式接口，定义如下：

          @FunctionalInterfacepublicinterfaceHandler<E>{/*** Something has happened, so handle it.** @param event  the event to handle*/voidhandle(Eevent);}

可见，vertx添加请求处理器的过程非常简单，而且写起来也很爽。

不过这里还是会有一个问题，我们的服务会有大量的Handler, 大量的路由，这时候就只能在这里罗列一堆方法调用吗？当然不用，这些重复性的工作一定是可以在框架层面处理掉的，比如，你可以选择使用我写的 spring-boot-starter-vertx, 用了以后就可以像SpringMVC里 @Controller注解一样直接定义Handler了，starter会在启动时自动扫描添加，像这样：

          @Component// @BlockedHandler@Slf4jpublicclassDemoHandlerimplementsHandler<RoutingContext>{@Overridepublicvoidhandle(RoutingContextroute){log.info("invoke DemoHandler, path: {}",route.request().path());route.response().end("ok");}}

如果Handler需要在worker线程池中调用，那么只需要添加一个 @BlockedHandler注解即可。

是不是很方便？

如何处理数据库查询

数据库查询操作其实代表的是阻塞调用。在Vert.x Web应用中，我们有两种方式来处理block调用，一种就是像上面说的那样，将含有block调用的代码集中到一个Handler中然后注册成blockingHandler; 另一种则是像node.js那样使用回调。其中回调又可以分成两类，一是使用 vert.x封装好的异步JDBC，里面所有的block操作都会多一个注册回调方法的参数。这种方式我个人觉得如果你是刚刚入坑vert.x话那就很不推荐，因为它会让你对回调产生恐惧。这里建议使用更传统点的方法，即继续使用你喜欢的持久化框架，只不过是在调用时将这部分代码提交到worker线程池中执行。下面我们用代码说话。

假设我们需要做两次数据库查询，只有拿到两次查询的结果才能执行后面的逻辑，这种情况在业务系统中是非常常见的。用回调方式的代码长这样：

          @Overridepublicvoidhandle(RoutingContextroute){log.info("invoke DemoHandler, path: {}",route.request().path());// (0)Future<String>fut1=Future.future();Future<String>fut2=Future.future();// 执行block调用route.vertx()// (1).executeBlocking(fut->{Stringresult=demoService.blockingLogic(1);// (2)fut.complete(result);// (3)},fut1.completer()// (4));// 执行block调用route.vertx().executeBlocking(fut->{Stringresult=demoService.blockingLogic(2);fut.complete(result);},fut2.completer());// 组合结果CompositeFuture.all(fut1,fut2).setHandler(ar->{// (5)if(!ar.succeeded()){// (6)log.error("",ar.cause());route.response().end("error");return;}log.info("final step");List<String>resultList=ar.result().list();// (7)route.response().end(resultList.toString());});}

(0): 构造两个Future对象，用来协调、同步两个异步调用

(1): 从一下文中获取vertx对象，调用 executeBlocking()方法向worker线程池中提交任务

(2): 调用会发生阻塞的数据库查询方法

(3): 调用传进来的Future对象的 complete()方法通知vert.x业务逻辑成功完成，并将执行的结果对象传递进来

(4): 将我们定义的Future对象标记为成功或失败。如果(2)或(3)抛出了异常，那么fut2会被标记为失败，反之成功

(5): 使用 CompositeFuture工具类的 all()方法将上面定义的两个Feature组合起来，并注册一个回调方法，此方法会在fut1, fut2全部成功或有一个失败时触发。

(6): 回调触发后，要先判断结果是成功还是失败

(7): 取出两个DB查询的结果

可以看到，业务逻辑被各种回调分散到了不同的Handler中。这就是使用异步框架最主要的工程代价。

组合起来

我写了一个Demo web项目，它基于上面提到的 spring-boot-starter-vertx项目，提供一个 GET /user?username=xxx查询接口，使用Mybatis做持久化层实现DB查询。麻雀虽小五脏俱全！

https://github.com/wanghongfei/all-about-vertx-4