使用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上，使用方法如下：
HttpServer server = vertx.createHttpServer();
Router router = 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是一个函数式接口，定义如下：
@FunctionalInterface
public interface Handler<E> {
/**
* Something has happened, so handle it.
*
* @param event the event to handle
*/
void handle(E event);
}
可见，vertx添加请求处理器的过程非常简单，而且写起来也很爽。
不过这里还是会有一个问题，我们的服务会有大量的Handler, 大量的路由，这时候就只能在这里罗列一堆方法调用吗？当然不用，这些重复性的工作一定是可以在框架层面处理掉的，比如，你可以选择使用我写的 spring-boot-starter-vertx, 用了以后就可以像SpringMVC里@Controller注解一样直接定义Handler了，starter会在启动时自动扫描添加，像这样：
@Component
// @BlockedHandler
@Slf4j
public class DemoHandler implements Handler<RoutingContext> {
@Override
public void handle(RoutingContext route) {
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线程池中执行。下面我们用代码说话。
假设我们需要做两次数据库查询，只有拿到两次查询的结果才能执行后面的逻辑，这种情况在业务系统中是非常常见的。用回调方式的代码长这样：
@Override
public void handle(RoutingContext route) {
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 -> {
String result = demoService.blockingLogic(1); // (2)
fut.complete(result); // (3)
},
fut1.completer() // (4)
);
// 执行block调用
route.vertx()
.executeBlocking(
fut -> {
String result = 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查询。麻雀虽小五脏俱全！