Vert.x入坑须知（1）

2023年9月10日 264次阅读 来源: SQL

一直以来早有将这些年用Vert.x的经验整理一下的想法，奈何天生不是勤快人，直到最近扶墙老师问起，遂成此文。

选择理由

现在想想，我们应该算是国内用Vert.x的最早一批人，版本大概是1.2.x吧，当时Vert.x内置了一个比较坑爹的模块系统，看似不错，但其实很坑爹。但即使这样，我们当时还是在技术选型上采用了它。理由大致如下：

  • 性能，它的底层是netty，并且编程模型跟node.js如出一辙，可算得上是“node on JVM”。同时，性能评测上比node还高出不少。
  • 简单，它比netty更简单，而且可以轻易的支持cluster。
  • Actor模型，Verticle + Eventbus，降低了并发编程的难度。
  • WebSocket，恰好当时的项目需要这样的方案，服务器主动向前台推。并且Vert.x提供的EventbusBridge让前端js的组织更好。
  • 支持Groovy，用过的都知道，这里就不展开了。
  • 轻量级，部署简单。

于是乎，它顺利成章地成为了我们当时系统接入层的中流砥柱，在实践中也确实发挥了很好的作用。

踩坑指南

鉴于Vert.x当前的版本是3.3.3，因此本文的内容也主要针对这个版本而言，一些我们遇到并且已经修复的bug，也就不会也没有必要在此啰嗦了。

此外，本文也不是入门文档，而是为了预防陷坑而给出的指导意见，故在阅读本文之前还请先仔细阅读Vert.x的文档。

编程语言

虽然Vert.x的一大亮点号称是支持“多语言”，即同一个工程内可以同时用Java、Groovy、Javascript等不同语言编写Verticle，但我还是建议采用Java为主，最多辅以Groovy。原因是：我发现很多新出的Vert.x模块还是对Java支持最好，对于其他的则就相当一般了，起码不会让你感觉特意针对这个语言而开发的。加上本来Java 8之后支持lambda，Java程序员的苦逼生活其实已经改善不少。

在dgate中，我主要采用Java + Groovy的方式，两者分工也很明确：前者用于数据处理，后者则用于DSL和数据类。

此时，由于混用了两者，并且可能会出现Groovy类要用到程序中Java类的情况，那么就要用到joint compile。在build.gradle中需要配置如下：

sourceSets.main.java.srcDirs = []
sourceSets.main.groovy.srcDirs += ["src/main/java"]

即，将Java类也交由Groovy编译器来编译。

工程结构

虽然Vert.x可以内嵌到其他框架中，但在实际项目上我还是偏爱单独部署，项目的构建方式则为：gradle + fatjar。具体例子，可以参见这个build.gradle文件。

我在Vert.x邮件组中经常看到有新人问关于Vert.x的组织方式，其实这是没有理解Vert.x的本质：Verticle。Verticle可视作Vert.x的一个最小部署和运行单元，简单的说，可类比为Servlet。因此，整个应用可以这样来划分：

  • Launcher，程序入口，负责调起Vert.x的环境。
  • MainVerticle，主Verticle，负责部署程序中其他的Verticle。
  • Verticle，程序处理逻辑，调用其他POJO/POGO。
  • POJO/POGO，普通类，供Verticle使用。

前两者负责初始化，Verticle则类似Servlet一样等待被触发（来自TCP/Eventbus/HTTP的Request），在实际处理时会调用到其他类。

这也就是为何在上面的build.gradle中有这样关键的两行的原因：

manifest {
    attributes 'Main-Class': '……'
    attributes 'Main-Verticle': '……'
}

Logging

Vert.x默认支持JUL，对于其他Logging框架也有支持。但我嫌每次运行要敲那么多命令很烦，那么可以在Launcher中强制设置环境变量：

System.setProperty("vertx.logger-delegate-factory-class-name",
                "io.vertx.core.logging.SLF4JLogDelegateFactory");

可参见dgate的Launcher代码。

部署Verticle

跟Servlet类似，多个Verticle之间也会有依赖关系，存在先后部署的需要。

对于单个Verticle之间的依赖，如A依赖B，很简单，利用deployVerticle的回调就很好解决。因为代码简单，这里就不再单独列出，还是那句话，看文档。

对于依赖多个Verticle，如A依赖B和C，则需要有点技巧了：

  • 第一也是最差的方式，就是采用callback hell方式，层层递进。
  • 第二种方法采用rxJava，利用Observable的运算来完成。
  • 第三种方式，利用Java的Atom对象，示例代码（Groovy）如下：
private void deployVerties(List<Map> verticles, Closure completeHandler = null) {
    AtomicInteger count = new AtomicInteger(0)
    verticles.each { verticle ->
        vertx.deployVerticle(verticle.name, verticle.option ?: [:]) { result ->
            if (result.succeeded()) {
                if (count.incrementAndGet() == verticles.size()) {
                    if (completeHandler) {
                        completeHandler.call()
                    }
                }
            } else {
                exit(verticle.name, result.cause())
            }
        }
    }
}

看到Atom对象，你是否觉得也可以采用CountDownLatch对象？很不幸，不行。我当时做过尝试，整个代码立马被Block住，直到我按了Ctrl-C。原因在于：Block住了EventLoop。

至于deployVerticle()，它可以接受字符串和类实例。当使用字符串时，若是非Java类，如Groovy，需要采用这样的格式：”语言前缀:类全限定名”。如：

'groovy:hawkeyes.rtds.processor.MailMan'

此外，部署的Verticle实例并非越多越好，还跟CPU的核数相关。

Block操作

Vert.x应用最忌讳Blocking操作，对此有多种处理：

  • 采用Worker Verticle
  • 使用executeBlocking函数

凡是涉及IO的操作，都请考虑一下。

EventBus

EventBus相当于Vert.x应用的神经系统，但有几点需要注意：

  • 若想给部署在另一台机器上的Verticle发消息，这两个Verticle必需是在一个集群中。
  • 拦截EventBus的消息需要注意一下这个小地方。

严格来讲，3.2之后，上述第一点并不完全正确。这两个Verticle之间可以采用TCP EventBusBridge来进行通信，具体参见这篇文章。

Cluster和内存计算

Cluster是当时我选择Vert.x的一个重要考量，而且将Vert.x应用单独打成fatjar还有一个附带好处就是Vert.x的cli都可以直接使用，其中就包括cluster命令。

Vert.x的集群建立在Hazelcast之上，除了集群调度，它本身还能做内存存储，即具备了Redis的主要功能。并且查询语法也比Redis（2.x）的要灵活，支持类SQL语法。更重要的是，其ReadThrough特性让人欲罢不能，简化了编程。当然，还包括其他如分布式锁、队列、任务等等。

所谓ReadThrough，即“若内存中没有，则查询将下传到下一级（通常是DB）”。Hazelcast的ReadThrough可通过实现MapLoader接口来实现。这个例子很简单，故可查看Hazelcast的文档了解。这里重点讲一下如何在Vert.x中去配置，因为Vert.x没有对此提供直接支持。

首先，cluster.xml即为一个标准的Hazelcast配置文件，故可在此配置相应的MapLoader即可：

<map name="map_name">
  <map-store enabled="true">
    <class-name>xxxLoader</class-name>
  </map-store>
</map>

在从未给集群Map赋过值且第一次运行下列代码时，注意两个名字要相同，则触发ReadThrough：

vertx.sharedData().getClusterWideMap("map_name") {……}

如果想在Vert.x中获得Hazelcast实例，则可以直接使用下面代码：

Set<HazelcastInstance> instances = Hazelcast.getAllHazelcastInstances()
hz = instances.first()

这样便可利用Hazelcast的其他功能。在3.3.3之后，Vert.x集群支持Ignite，它是比Hazelcast更强大的内存计算工具。而且，在Vert.x 3.4-beta1中已经不再是技术预览版，日后我肯定会全面拥抱它。

Ignite/Hazelcast不像Redis那样曝光率那么高，但鉴于其本身都是老牌内存计算软件，且在开源之前都在高强度生产环境（没记错的话是银行系统）实战演练过，同时对比一下两者之间的功能列表，你会发现这些工具其实更强大，尤其是Ignite。它们的文档都不错，值得一看。

Handler

最后说一说Handler中需要注意的地方，它非常适合写Restful API。

之前用Vert.x写接入层代码，主要集中在Core、Groovy和Shell部分。这次写dgate，算是扎扎实实用了一下Web部分。至于历史，我就不详细说了，总之一句话：哥是看着它长大的，;)。

Handler其实很简单，只需要注意几点：

  • Vert.x request Handler除了处理功能，还兼具Filter的功能。若处理完毕，请求不想让下一个request handler处理，则直接返回即可；否则，需要调用：routingContext.next()。
  • 对于同一个URL可以注册多个handler，以调用顺序为准。故，想先处理的，如验证，往前放。

至于其他，没啥可说的，都很简单。

写在最后

最后，来句鸡汤：遇坑不可怕，还得勇于尝试方能有所收获，希望对各位有帮助！

    原文作者：SQL
    原文地址: https://segmentfault.com/a/1190000008441871
    本文转自网络文章，转载此文章仅为分享知识，如有侵权，请联系博主进行删除。
点赞