首页 > 解决方案 > Vertx 聚类替代方案

问题描述

除了 Hazelcast之外,任何具有 Vertx 集群管理器实际经验的人都可以对我们的以下要求提出建议?

对于我们的(实时传感器数据)系统,我们在多个 JVM 中有数百个 Verticle,但我们不需要或不希望事件总线跨越多个物理服务器。

我们在多台服务器上运行 Vertx,但如果我们不在所有服务器之间汇集单个事件总线,我们的平台就不那么复杂(我们更愿意明确地在服务器之间传递消息)。

Hazelcast 对我们来说是错误的集群管理器。我们不需要它在服务器之间的对等发现,但至关重要的是,Hazelcast 的任何版本更改都意味着客户端无法与运行先前版本的现有运行客户端加入集群,因此将使用 vertx 3.6.3 编译的新 Verticle 引入现有集群除非我们停止整个集群并重新编译所有 Verticle 到 3.6.3,否则这是不可能的。这严重影响了我们的发展。verticles 更加即插即用是有帮助的,vertx 可以做到这一点,但 Hazelcast 不能(由于版本不兼容)。

谁能推荐一个适合我们用例的 vertx 集群管理器?

标签: cluster-computinghazelcastvert.x

解决方案


我现在有时间回顾 Vertx 作为“集群管理器”直接支持的每个替代方案(Hazelcast、Zookeeper、Ignite、Infinispan),我们正在为我们的系统使用 Zookeeper 架构,以取代 Hazelcast:

Zookeeper / Vertx 多服务器架构

以下是我们决定的背景:

我们从一个相当典型的(如果有的话)Vertx 开发开始,在 JVM 中使用多个 Verticle 来响应在事件总线上发布的外部事件(城市传感器数据进入我们的 java/vertx 提要处理程序),并且数据在许多情况下被异步处理其他 vertx verticles,通常涉及它们将新的派生数据发布为新的异步消息。

很快我们就想使用多个 JVM,主要是为了将 feedhandler 与其余代码隔离开来,因此如果出现问题,feedhandler 将继续运行(作为故障保护,它们会保存数据并发布数据)。所以我们(轻松地)添加了 Vertx 集群,以便同一台机器上的 JVM 可以通信,并且所有 Verticle 可以在同一系统中发布/订阅消息。我们使用默认的集群管理器 Hazelcast,并修改了配置,因此 vertx 集群仅限于单个服务器(我们在不同的服务器上运行整个平台的多个版本,并且不希望它们相互混淆)。我们在六个 JVM 中有数百个 Verticle。

我们的环境(搜索 SmartCambridge vertx)是相当动态的,具有快速的开发周期(例如,创建一个新的 feedhandler 并让它在 eventbus 上发布它的数据),意味着我们通常希望启动一个包含这些新 Verticle 的 JVM 并让它加入一个现有的 vertx 集群,可能是永久的,也可能只是一段时间。Vertx/Hazelcast 加入(vertx)集群是一项相当严肃的操作,即 Hazelcast(我相信)有 Hazelcast 集群成员和 Hazelcast 客户端的概念,客户端可以轻松进出,但作为成员加入 Hazelcast 集群要求现有集群和新成员之间有相当大的代码兼容性。每次我们升级 Vertx 库时,Hazelcast 库版本都会发生变化,这使得新编译的 vertx verticle 无法加入现有的 vertx 集群。

请注意,我们已经尝试让 Vertx 事件总线在多个服务器之间流动,并将事件总线扩展到浏览器/javascript,但在这两种情况下,我们发现明确地从服务器到服务器的路由消息并编写了 verticles 更简单/更健壮专门为此目的。

因此,新计划(经过几年 Vertx 开发),考虑到我们的 5 个生产/开发服务器环境,但 vertx 事件总线始终仅限于单个服务器,是在所有 5 个服务器上实现一个 Zookeeper 集群,因此我们获得 Zookeeper 本地弹性优势,并将每个生产服务器配置为使用不同的 znode 根(默认为“io.vertx”,但这是一个简单的配置选项)。

这种设计在单个服务器(即 Zookeeper + Vertx)上具有有吸引力的简单最小构建,因此仍然可以在随机机器(例如笔记本电脑)上进行临时开发,但我们可以将我们的平台扩展为在单个 vertx 集群中拥有多个服务器很简单通过设置一个公共 znode 根。


推荐阅读