Vert.x入坑须知（3）

随着Vert.x进化到3.5.0，本系列也迎来了新篇章。

CORS的新变化

对于CORS，搞Web开发（不论你是前端，还是后端）的同志应该不陌生，尤其是如今微服务盛行的时代，CORS更是最常用的配置项之一。假若你对此还有一点点的疑问，不用问，你已经落伍了！

Vert.x很早就支持了CORS，但到了3.5.0，出于安全性上的考虑，它增加了一个限制：

当allowedOriginPattern为“*”时，allowCredentials不允许为“true”。

这个限制其实起源自协议的限制：

The string "*" cannot be used for a resource that supports credentials.The string "*" cannot be used for a resource that supports credentials.

即：Access-Control-Allow-Origin为“*”时，Access-Control-Allow-Credentials会被忽略，Credentials信息（一般是Cookie）也不会被user-agent发送。大家可以参考这篇文章（英文原版）了解如何安全地设置各个header。

在3.5.0时，当allowedOriginPattern为“*”和allowCredentials为“true”时，Vert.x会产生一个异常，若不处理会导致Verticle不能正常启动。在之前的版本中，不会出现这种情况。

CB for handler

断路器是个好东东，强烈建议在框架设计上就考虑它，以避免粗心的开发者写的代码扰乱其他好代码。在我写dgate和dfx时，对所有对外暴露的服务也都强加了这个限制。

既然CB这么好，是不是动过将其应用到普通Handler上的念头？不过由于Vert.x CB的文档示例中给出的都是清一色的HTTP请求的例子，要想将CB推而广之应用到普通的Handler上还得费点气力。

在dfx中我写了一个工具类，对此需求进行了封装：

public static void withCircuitBreaker(Vertx vertx, CircuitBreaker circuitBreaker, Accessible accessible, Map params, Handler<Map> successHandler, Handler<Throwable> failureHandler) {circuitBreaker.execute(future ->vertx.executeBlocking(f -> {try {f.complete(accessible.invoke(params));} catch (Throwable throwable) {f.fail(throwable);}}, result -> {if (result.succeeded()) {future.complete(result.result());} else {future.fail(result.cause());}})).setHandler(result -> {if (result.succeeded()) {successHandler.handle((Map) result.result());} else {logger.error("CB[{}] execution failed, cause: ", circuitBreaker.name(), result.cause());failureHandler.handle(result.cause());}});
}

它的使用很简单：

Utils.withCircuitBreaker(vertx, circuitBreaker, accessible, body.getMap(), result -> Utils.fireJsonResponse(response, 200, result), throwable -> Utils.fireSingleMessageResponse(response, 500, throwable.getMessage()));

各位可依葫芦画瓢将其改为自己的形式，其中的重点在于以“vertx.executeBlocking”方式来执行Handler的代码。

测试

在稍微正规的队伍中，自动化测试应该已经是一个标准实践了，并且Vert.x对于测试也提供了支持。

不过，我不喜欢。原因有几个：

Vert.x Unit是基于JUnit，而我已经有钟情的测试框架：Spock。相比起JUnit而言，后者简直可以说是Java测试领域的战斗机。
好的单元测试本来就是要尽量少的依赖所用框架，注意这一点之后，尽力将类设计得好测试，这样的结果就是普通的单元测试类编写。既然有让人爽的工具用，也就没有必要去用Vert.x Unit了。
对于集成测试，直接模拟实际的环境，再加上合适的timer，目前看来也还不错。而且Vert.x Unit中也一样需要用timer，这样一来，也就没有必要专门用它了。

为了证明我所言非虚，大家可以去看看dgate和dfx的测试代码。这里给出两个例子：

集成测试
单元测试

都是基于Spock写的，各位可以体验其酸爽度。

运行时外部配置

在本系列第一篇里，我就提出了一个钟意的工程结构组成，但里面没有提到“运行时外部配置文件”这一常见的实践。

经过若干项目的锤炼之后，目前对于这种运行时的外部配置文件，我基本形成了一个固定套路：Groovy DSL + Groovy ConfigSlurper。它俩简直是完成这一任务的绝配，比起Vert.x的提供的json配置文件要爽太多。

看看Gradle的build文件，你就可以知道这种DSL的灵活度可以到什么程度，更何况Groovy的语法对于Java开发者极其友好。

或许有人会觉得Groovy不酷，甚至有点鄙夷，言必称Scala、Clojure、Kotlin、Go或者Rust。对此，哥只想说：作为开发者，最让人鄙夷的是交不出活，客户才不关心你用什么语言呢！

配置DSL的例子：dgate配置

dgate是我写的一个基于vertx的轻量级网关，所有的配置全部通过配置文件来定义，无需数据库。关于它的详细介绍，可以参见其文档。为了说明上一节采用Groovy DSL的灵活度，这里展示几个dgate的配置例子。

静态Mock

利用dgate的mock功能，分离开的前后端开发人员可以并行工作，只需将mock响应配置到dgate的配置文件中就好。

"/summary" {expected {statusCode = 200payload {eqLocations = []opRateInLast30Days = []myOrgs = [["name": "org1", "admin": false]]}}
}

动态Mock

动态Mock为那些返回动态结果（如某些情况下成功，某些情况下失败）的URL模拟提供了便利。

"/login" {required = ["sub", "password"]methods = [HttpMethod.GET, HttpMethod.POST]expected {statusCode = 200payload = {JWTAuth jwtAuth = Utils.createAuthProvider(Vertx.vertx())JWTTokenGenerator tokenGenerator = new JWTTokenGenerator(jwtAuth)[token: tokenGenerator.token(["sub": "……", "name": "……", "role": "normal"], 200)]}}
}

上例将模拟一个实际的动态JWT，这样的好处在于，方便前端/移动端开发直接去完成刷新token或重新登录的过程，而不需要再针对此场景做其他特殊处理。

请注意，为了产生动态结果，此处的payload使用的是闭包，而不像前一例用的是Map。此时，闭包的返回值为Mock响应的结果。

以上的例子已经充分展现了将Groovy DSL作为运行时外部配置的能力，可以说是完胜Vert.x自带的json配置方式。

好啦，本期内容就此结束，请保持关注，期待下期继续！

本系列其他文章：

Vert.x入坑须知（1）
Vert.x入坑须知（2）