摘要：主要是避免引入太多的復(fù)雜性，并且出于靈活部署的需要。以應(yīng)用為例，由于實際上是在上執(zhí)行，若它被阻塞，即導(dǎo)致后續(xù)請求全部無法得到處理。因此，最合適的做法就是對于簡單業(yè)務(wù)，采用異步庫。本系列其他文章入坑須知入坑須知入坑須知

最開始覺得這個系列也就最多3篇了不起了（因為事不過三嘛），沒曾想居然迎來了第四篇！

由于最近決定投身到區(qū)塊鏈的學(xué)習(xí)當(dāng)中的緣故，出于更好的理解它的基本概念，自己動手參考文章寫了一個迷你區(qū)塊鏈的例子。采用了kotlin + vertx的工具選擇。這次嘗試再次驗證了我在本系列一開篇所說：建議以Java語言開發(fā)為主。原因很簡單，因為這個是基礎(chǔ)，所以各方面支持（包括文檔和功能方面）肯定是Java語言優(yōu)先。

在做這個區(qū)塊鏈的例子時，Vertx Kotlin的文檔讓我有極為糟糕的體驗：從整篇文檔中，你找不到一個完整的用kotlin書寫Verticle的例子，閱讀的時候就感覺內(nèi)容有跳躍。雖然你可以猜出應(yīng)該是繼承AbstractVerticle，但你肯定還是希望文檔中明確指出來。

當(dāng)然啦，盡管有這樣的問題，寫代碼的體驗還是不錯的。就build.gradle而言，跟Java + Groovy組合的差別不大。唯一需要注意的是，你可能需要將kotlin的jvmTarget設(shè)置為“1.8”。具體的配置可以參考工程的build.gradle。

總之，發(fā)現(xiàn)文檔有問題，就先查Java文檔。

上面的區(qū)塊鏈的例子由兩部分組成：前端靜態(tài)頁面 + 后端的Verticle，前端靜態(tài)頁面通過Ajax請求與后端的Verticle交互。這其實就是通過Vertx-Web的StaticHandler來實現(xiàn)的，很簡單。這里只提兩個需要留心的小地方。

首先，靜態(tài)資源的根路徑默認(rèn)情況下是：src/main/resources/webroot。即當(dāng)你請求“http://localhost:8080/index.html”時，其實對應(yīng)的是：src/main/resources/webroot/index.html。

其次，目前的Web應(yīng)用的URL很少會直接出現(xiàn)“……/xxx.html”。按照向Spring MVC或Grails這里框架的做法，一般是經(jīng)過一個action，然后將瀏覽器導(dǎo)向某個頁面。在做這個例子時，其實沒有這么復(fù)雜的邏輯，讓瀏覽器直接去加載某個頁面（如configure.html）就可以了。但這樣會出現(xiàn)一個讓人很不爽的Path：“/configure.html”，而其他的路徑因為主要是負(fù)責(zé)處理Ajax請求，都是形如“/mine”這樣的路徑。

為了統(tǒng)一路徑風(fēng)格，這里采用了一個小技巧：RoutingContext.reroute。參考代碼如下：

router.get("/configure").handler({ rc: RoutingContext -> rc.reroute("/configure.html") })

Vert.x JDBC client缺省的連接池提供者是c3p0，但它也支持其他其他的連接池，比如大名鼎鼎的Hikari。但遺憾的是，文檔中沒有給出一個完整的代碼示例。對于想換用其他連接池的同學(xué)，可以參考下面的代碼：

JDBCClient.createShared(vertx, new JsonObject()
                .put("provider_class", "io.vertx.ext.jdbc.spi.impl.HikariCPDataSourceProvider")
                .put("driverClassName", "org.postgresql.Driver")
                .put("jdbcUrl", jdbcUrl)
                .put("username", username)
                .put("password", password)
                .put("maximumPoolSize", maximumPoolSize)
                .put("minimumIdle", minimumIdle)
                .put("cachePrepStmts", true)
                .put("prepStmtCacheSize", 250)
                .put("prepStmtCacheSqlLimit", 2048));

對于用Postgresql的同學(xué)，還可以看看Reactive Postgres Client，一個高性能的輕量級jdbc client同時自帶連接池，作者也是vertx的貢獻(xiàn)者。

使用Vert.x的最大好處就是極大簡化了多線程編程的復(fù)雜性，大部分時候你幾乎不需要去操心，這部分內(nèi)容分別在文檔的Standard verticles和Worker verticles有描述。

但文檔中并沒有專門闡述這一原則是否對于回調(diào)函數(shù)也適用，畢竟回調(diào)函數(shù)執(zhí)行的時機不確定并且典型的Vert.x程序充斥著回調(diào)。對于這個問題，簡單地說：同樣適用。下面的示例代碼可以驗證這一點：

public class Vert1 extends AbstractVerticle {

    long count = 0;

    @Override
    public void start() {
        HttpClient httpClient = vertx.createHttpClient();

        for (int i = 0; i < 20; i++) {
            httpClient.getAbs("http://www.baidu.com/", response -> {
                count++;
                System.out.println(count);
            }).end();
        }
    }

}

從輸出來看，完全正確。作為對比，你可以在groovyConsole中運行下面的代碼（多按幾次ctrl - r）：

int count = 0
def c = { 
    10.times { 
        count++
        println count }
}
def t1 = new Thread(c)
def t2 = new Thread(c)
t1.start()
t2.start()

并且，通過調(diào)研Vert.x源代碼，你可以（在HttpClientRequestBase中）發(fā)現(xiàn)：

  void handleResponse(HttpClientResponseImpl resp) {
    synchronized (getLock()) {
      // If an exception occurred (e.g. a timeout fired) we won"t receive the response.
      if (exceptionOccurred == null) {
        long timeoutMS = currentTimeoutMs;
        cancelOutstandingTimeoutTimer();
        try {
          doHandleResponse(resp, timeoutMS);
        } catch (Throwable t) {
          handleException(t);
        }
      }
    }
  }

很明顯，Vert.x內(nèi)部已經(jīng)為你提前預(yù)防了，這就是框架的力量！如果你還在用Netty，不妨考慮Vert.x這個建構(gòu)于它之上的高層工具吧。

Subrouter是個好東東，可API設(shè)計有個問題：只有mount，沒有unmount！一般情況下，unmount的確用不上，但你一旦想實現(xiàn)動態(tài)路由時，它就是萬萬不可缺少的了。

好在我自己摸索出了下面的方法：

public static void unMountSubRouter(Router router, String root) {
    router.getRoutes().stream()
            .filter(route -> route.getPath() != null && route.getPath().startsWith(root))
            .forEach(route -> route.remove());
}

有趣的是，Vert.x的開發(fā)者曾經(jīng)覺得subrouter用處不大，并動了把它在未來拿掉的念頭。當(dāng)這個想法被提出來征求社區(qū)意見時，立馬有人跳出來說：“subrouter的設(shè)計非常好，哥的程序嚴(yán)重依賴它，請繼續(xù)保留。”

我曾經(jīng)不止一次看到初學(xué)者在問類似這樣的問題：

應(yīng)該創(chuàng)建多少Verticle實例？

Vert.x的應(yīng)用該怎么去設(shè)計？

怎么跟現(xiàn)有的框架結(jié)合？

……

要回答這些問題，需要首先搞清楚幾個事實。

不要將Verticle和Thread混為一談，它們不是一類東西。簡單的說，可以這樣理解：Verticle由Thread來執(zhí)行。

Vert.x中的Verticle由種類之分，不同類型的Verticle適用于不同場景，這一點在文檔中已經(jīng)有詳細(xì)的闡述。

Vert.x本身是一個庫，并不妨礙它跟其他框架（如Grails）的結(jié)合。只不過就我個人而言，更偏好將Vert.x應(yīng)用多帶帶使用。主要是避免引入太多的復(fù)雜性，并且出于靈活部署的需要。

并且，通過觀察其他人寫的Vert.x代碼（包括Vert.x自己的那些子項目），可以總結(jié)出來幾個套路。

這是最常見的結(jié)構(gòu)：

標(biāo)準(zhǔn)Verticle，負(fù)責(zé)接收外部請求，完成請求分派和結(jié)果收集

Worker Verticle，負(fù)責(zé)臟活累活

標(biāo)準(zhǔn)Verticle和Worker Verticle之間通過eventbus進(jìn)行交互，整個架構(gòu)其實也很簡單：

request <---> standard verticles <---> worker verticle

這里的一個典型反模式，尤其是初學(xué)者會大概率犯的錯誤：將本該worker干的活，交給了標(biāo)準(zhǔn)verticle，即將圖中后兩個組件合二為一。這種情況在寫Vertx Web時非常容易出現(xiàn)，尤其受傳統(tǒng)MVC框架的影響，無意識地將原來的編程套路給照搬過來了：在Handler中進(jìn)行了大量操作。我自己也不例外，走過這段彎路。

Don"t block me！

以Vert.x Web應(yīng)用為例，由于Handler實際上是在eventloop上執(zhí)行，若它被阻塞，即導(dǎo)致后續(xù)請求全部無法得到處理。因此，最合適的做法就是：

對于簡單業(yè)務(wù)，采用異步庫。

對于復(fù)雜業(yè)務(wù)，干脆交給worker去處理。

利用Vert.x的特點，將IO操作封裝成異步庫。

用Vert.x將業(yè)務(wù)功能封裝成微服務(wù)，然后利用現(xiàn)成的基礎(chǔ)設(shè)施與其他應(yīng)用交互：

利用kafka隊列實現(xiàn)服務(wù)間的交互

利用TCP Bridge實現(xiàn)與tcp client的交互

利用Eventbus Bridge實現(xiàn)與頁面的交互

利用數(shù)據(jù)庫實現(xiàn)與應(yīng)用的簡單交互

……

這也是我最喜歡用的模式，輕量，簡單，部署方便。我不太喜歡在一個本來就已經(jīng)含有復(fù)雜業(yè)務(wù)邏輯的Grails應(yīng)用中再包含一個Vert.x Verticle了。

或許有同學(xué)對于上面的最后一項，感到疑惑。其實這個很簡單，以Postgresql為例，可以采用兩種模式：

簡單的“定時任務(wù)+表”的方式，通過表的某個字段實現(xiàn)服務(wù)間的集成

利用PG自身支持的pub/sub功能

行了，本篇寫到這里也差不多了。最后給大家推薦一個網(wǎng)頁：Awesome Vert.x，上面有不少不錯的資源。

本系列其他文章：

Vert.x入坑須知（1）

Vert.x入坑須知（2）

Vert.x入坑須知（3）