桌面分布式应用程序架构

Question

我有一些.NET应用程序很旧（需要大量支持），我打算将其替换为新的。该应用程序具有一些关键功能：

• 外部API同步后，它必须具有脱机工作能力，再次联机后，它必须与外部API同步。
• 它必须在局域网中的设备之间同步状态（应用程序使用虚拟现金实现某种交易）
• 性能和应用责任很重要

当前的应用程序架构如下：

• 我们有例如。 3个相同的设备（D1，D2，D3）
• 一个称为“主机”（D1）的设备负责外部API数据同步。
• 其他设备（D2，D3）使用存储在D1设备上的数据库

...一切都很好-但仅在“良好”环境中有效。

-最有问题的是，即使客户只想使用一台设备，例如D2，他还必须打开D1。  -另一件事是，当D1断开时，它们会松开所有零件（由于设备质量不是很好，这是一个非常普遍的问题）

我的客户不是IT的“专家”，即使他们想要使用“仅一个”设备（无论谁联系过），他们也无法理解哪个是“主”设备以及为什么必须打开另一台设备支持热线知道我在说什么;））

因此，我的想法是使客户（以及我自己）的一切变得容易。我认为这样的架构可能会有所帮助：

• 每个应用都可能成为“主”（整个网络中仍然只有一个）并进行API同步
• 数据实时复制到每台设备上（我正在考虑使用Apache Ignite，但不知道它是否过大）

我看到一些优点：

• 没有“主人”，没有“奴隶”
• 数据冗余（在应用案例中，安全性比存储更重要）
• 没有一台中央服务器的同步

但是我也可以看到一个很大的缺点-在客户端使用例如仅D1一段时间（不运行任何其他设备），然后他仅运行D2，数据将不会同步（很明显；）。 为了解决该问题，我认为我们能够在应用程序退出时将上次关闭的设备状态与外部API同步（但我真的不知道这是一个好主意）。

这是我的问题，您如何看待我的想法？也许我看不到其他缺点（或优点？）？或者，也许您有解决当前架构问题的另一个想法？

预先感谢您的帮助。

Answer 1

对于整体架构，我没有任何建议，但是我将尝试列出在这种情况下使用Apache Ignite的利弊。

优点：

• Ignite将非常轻松地解决您的复制任务，只需10行代码。只要在每个应用程序中运行它，它就会发现其他正在运行的实例并与它们同步，或者如果没有其他实例，则可以独自工作。
• 对磁盘的持久性是自动的
• 内置了高性能二进制序列化，因此您也不必为此担心。

缺点：

• 点火器比较耗资源。最初，您至少需要约300Mb的RAM，再加上数据的大小，再加上一些开销，具体取决于数据格式。
• 启动和发现其他实例可能需要3到10秒，具体取决于硬件

总体而言，我会尝试一下，因为它不需要花费很多时间来实现。