Vertx 聚类替代方案

Question

任何人只要有Vertx集群管理的实战经验，其他比Hazelcast对低于我们要求的建议？

对于我们（实时传感器数据）系统，我们有数百个在多个JVM verticles的，但我们确实没有需要，或想，在eventbus跨越多个物理服务器。

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

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

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

Answer 1

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

以下是我们做出决定的背景：

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

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

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

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

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

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