Vertx聚类替代方案

问题描述 投票:1回答:1

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

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

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

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

任何人都可以推荐适合我们用例的vertx集群管理器吗?

cluster-computing hazelcast vert.x
1个回答
1
投票

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

Zookeeper / Vertx multi-server architecture

以下是我们决定的背景:

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

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

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

请注意,我们已尝试在多个服务器之间使用Vertx事件总线,并将事件总线扩展到浏览器/ javascript中,但在这两种情况下都发现它更简单/更健壮,可以明确地将消息从服​​务器路由到服务器并具有写入的Verticle专门为此目的。

所以新计划(经过几年Vertx开发),鉴于我们的5个生产/开发服务器的环境,但是vertx eventbus总是限于单个服务器,是在所有5个服务器上实现一个Zookeeper集群,所以我们得到了Zookeeper native弹性良好,并配置每个生产服务器使用不同的znode根(默认为'io.vertx',但这是一个简单的配置选项)。

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

© www.soinside.com 2019 - 2024. All rights reserved.