随着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上还得费点气力。
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 = 200
payload {
eqLocations = []
opRateInLast30Days = []
myOrgs = [
["name": "org1", "admin": false]
]
}
}
}
动态Mock
动态Mock为那些返回动态结果（如某些情况下成功，某些情况下失败）的URL模拟提供了便利。
"/login" {
required = ["sub", "password"]
methods = [HttpMethod.GET, HttpMethod.POST]
expected {
statusCode = 200
payload = {
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配置方式。
好啦，本期内容就此结束，请保持关注，期待下期继续！
本系列其他文章：
网友评论