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

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

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

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

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

總之，發現文檔有問題，就先查Java文檔。

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

首先，靜態資源的根路徑默認情況下是：src/main/resources/webroot。即當你請求“http://localhost:8080/index.html”時，其實對應的是：src/main/resources/webroot/index.html。

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

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

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

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

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的同學，還可以看看Reactive Postgres Client，一個高性能的輕量級jdbc client同時自帶連接池，作者也是vertx的貢獻者。

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

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

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()

并且，通過調研Vert.x源代碼，你可以（在HttpClientRequestBase中）發現：

  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內部已經為你提前預防了，這就是框架的力量！如果你還在用Netty，不妨考慮Vert.x這個建構于它之上的高層工具吧。

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

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

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的開發者曾經覺得subrouter用處不大，并動了把它在未來拿掉的念頭。當這個想法被提出來征求社區意見時，立馬有人跳出來說：“subrouter的設計非常好，哥的程序嚴重依賴它，請繼續保留。”

我曾經不止一次看到初學者在問類似這樣的問題：

應該創建多少Verticle實例？

Vert.x的應用該怎么去設計？

怎么跟現有的框架結合？

……

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

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

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

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

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

這是最常見的結構：

標準Verticle，負責接收外部請求，完成請求分派和結果收集

Worker Verticle，負責臟活累活

標準Verticle和Worker Verticle之間通過eventbus進行交互，整個架構其實也很簡單：

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

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

Don"t block me！

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

對于簡單業務，采用異步庫。

對于復雜業務，干脆交給worker去處理。

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

用Vert.x將業務功能封裝成微服務，然后利用現成的基礎設施與其他應用交互：

利用kafka隊列實現服務間的交互

利用TCP Bridge實現與tcp client的交互

利用Eventbus Bridge實現與頁面的交互

利用數據庫實現與應用的簡單交互

……

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

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

簡單的“定時任務+表”的方式，通過表的某個字段實現服務間的集成

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

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

本系列其他文章：

Vert.x入坑須知（1）

Vert.x入坑須知（2）

Vert.x入坑須知（3）