具有不同可伸缩性级别的故障转移的 Java 程序答案

【问题标题】：Java programs with failover at different levels of scalability具有不同可伸缩性级别的故障转移的 Java 程序
【发布时间】：2020-05-03 21:07:57
【问题描述】：

本着使我的问题的措辞简洁明了的精神，我尽量避免使用诸如“冗余”、“分布式”、“集群”、“协调”、“容错”、“容器'

如果我要写作

，两个非常相似的程序，每个都是多线程的

我的目标是以这样的方式编写 A 和 B，当 A 意外终止时，B 将运行。由于 A 和 B 共享一个集中式数据库，因此数据的完整性不是这里的主要关注点。

问题 1：在以下每个可扩展性级别启用“监控”机制以检测 A 的终止和“唤醒”B 所需的最简单和最优雅的方法是什么？

1 级： A 和 B 各自在同一处理器和 RAM 上运行的一个实例（例如，我应该使用 JMXConnector 吗？）

2 级： A 和 B 各自的一个实例在 LAN 内的不同处理器和 RAM 集上运行，例如家里有两台笔记本电脑。（例如使用 RMI、Docker、Kubernetes？）

3 级： A 和 B 各自的一个实例在 WAN 上的不同处理器和 RAM 集上运行，例如我的笔记本电脑和远程位置的 PC

第 4 级（是的，在概念上可能与第 2 级和第 3 级重叠）： A 和 B 的多个实例在 AWS Cloud 和 Google Cloud 等云服务的不同节点上运行。（例如使用 RMI、Docker、Kubernetes？）

问题 2：如果我的最终目标是按照第 4 级，但我将首先在笔记本电脑上开始开发 A 和 B，类似于第 1 级，那么整体上做这件事的好方法是什么？开发/部署周期？

【问题讨论】：

我投票给@willrof 作为答案，因为我认为总体而言它是非常合理的。但是对于我来说，使用容器化路线的一个问题是，添加到每个需要故障转移功能的应用程序实例中的容器的额外填充的影响。就我而言，该应用程序对延迟非常敏感，类似于高频交易系统。大家有没有这种情况下的cmet？
我编辑了我的答案给你一些背景:)

【解决方案1】：

Kubernetes 因其弹性而成为一个不错的选择：从单主机单节点到大型部署。

对于您的 1 级场景，您可以在 Minikube 上使用虚拟化运行 Kubernetes。

对于您的 2、3 和 4 级方案，您可以使用 KubeAdm 设置您的 Kubernetes 控制平面：它会创建主节点并为您提供加入密钥，因此您可以根据需要添加更多主机计算机（节点） .

在 minikube 上的初始阶段之后，您可以轻松导出配置的 yaml，以便在更大的本地集群、混合集群或 100% 在云上运行。

编辑：

Kubernetes 平台是否适合在其中运行类似高频交易 (HFT) 的应用程序，这是另一个话题，需要在 SO 上打开一个单独的线程。
我只能在这里提醒一下，Kubernetes 的设计受到了 Google 的 Borg 系统的影响，而 Borg 系统又被用于处理短期的延迟敏感请求（例如网络搜索）。查看维基百科以了解有关此主题的更多信息。
如今，在 Kubernetes 上运行的应用程序可以使用本机底层硬件。例如，直接连接到工作节点（如 NVMe SSD 驱动器）或 GPU 资源的本地存储，它们分别提供为您的应用程序提供始终如一的高性能磁盘 I/O 操作，并且可以加速计算密集型任务。

【讨论】：