Vert.x入坑須知（3）

CollinPeng 發布于2019-08-16 10:56 / 749人閱讀

摘要：對于集成測試，直接模擬實際的環境，再加上合適的，目前看來也還不錯。這里給出兩個例子集成測試單元測試都是基于寫的，各位可以體驗其酸爽度。好啦，本期內容就此結束，請保持關注，期待下期繼續本系列其他文章入坑須知入坑須知

隨著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 successHandler, Handler 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配置方式。

好啦，本期內容就此結束，請保持關注，期待下期繼續！

本系列其他文章：

Vert.x入坑須知（1）

Vert.x入坑須知（2）

文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。

轉載請注明本文地址：http://m.specialneedsforspecialkids.com/yun/70756.html

Vert.x入坑須知（4）

摘要：主要是避免引入太多的復雜性，并且出于靈活部署的需要。以應用為例，由于實際上是在上執行，若它被阻塞，即導致后續請求全部無法得到處理。因此，最合適的做法就是對于簡單業務，采用異步庫。本系列其他文章入坑須知入坑須知入坑須知最開始覺得這個系列也就最多3篇了不起了（因為事不過三嘛），沒曾想居然迎來了第四篇！ Kotlin 由于最近決定投身到區塊鏈的學習當中的緣故，出于更好的理解它的基本概念，自...

summerpxy 2019-08-15 15:45 評論0 收藏0
Vert.x入坑須知（1）

摘要：輕量級，部署簡單。此外，本文也不是入門文檔，而是為了預防陷坑而給出的指導意見，故在閱讀本文之前還請先仔細閱讀的文檔。可視作的一個最小部署和運行單元，簡單的說，可類比為。，主，負責部署程序中其他的。嚴格來講，之后，上述第一點并不完全正確。一直以來早有將這些年用Vert.x的經驗整理一下的想法，奈何天生不是勤快人，直到最近扶墻老師問起，遂成此文。選擇理由現在想想，我們應該算是國內用V...

Turbo 2019-08-14 17:35 評論0 收藏0
Vert.x入坑須知（2）

摘要：這一點其實是非常不妥的，有潛在的安全問題。這次，在項目中終于采用了以它為基礎的集群方案。相反，使用一個周期，但針對每個生成一個一次性的，模擬隨機發送。同時，要記得用完之后立即釋放。當初創建簡書賬號的時候曾立下宏愿，希望保持周更，無奈現實殘酷，整個5月都處于忙忙碌碌的狀態，居然令這個本來并不算太宏偉的目標難以為繼，最終導致5月份交了白卷！【好吧，我承認，是我意志不夠堅定，太懶了，;)】...

xialong 2019-06-21 16:35 評論0 收藏0
使用Vert.x構建Web服務器和消息系統

摘要：而不是開始，將服務使用多線程的請求重量級的容器。是啟動多個輕便單線程的服務器和流量路由到他們。亮點應用程序是事件驅動，異步和單線程的。通過使用事件總線傳遞消息通信。為了建立一個消息系統，則需要獲得該事件總線。摘要如果你對Node.js感興趣，Vert.x可能是你的下一個大事件：一個建立在JVM上一個類似的架構企業制度。這一部分介紹Vert.x是通過兩個動手的例子（基于Vert.x...

DrizzleX 2019-08-14 14:06 評論0 收藏0
Vert.x Blueprint 系列教程(二) | Vert.x Kue 教程（Web部分）

摘要：上部分藍圖教程中我們一起探索了如何用開發一個基于消息的應用。對部分來說，如果看過我們之前的藍圖待辦事項服務開發教程的話，你應該對這一部分非常熟悉了，因此這里我們就不詳細解釋了。有關使用實現的教程可參考藍圖待辦事項服務開發教程。上部分藍圖教程中我們一起探索了如何用Vert.x開發一個基于消息的應用。在這部分教程中，我們將粗略地探索一下kue-http模塊的實現。 Vert.x Kue ...

Kerr1Gan 2019-08-14 14:21 評論0 收藏0