微服务架构，用于频繁访问数据；在内存解决方案中？

Question

让我们定义以下 用例 ：

• 必须完成一个模拟任务，其中涉及[ day1，day2，…，dayN ]上的迭代/模拟。迭代的每个步骤都取决于先前的步骤，因此顺序是预先定义的。
• 任务具有由 Object1 表示的状态，该对象将在迭代的每个步骤中更改。
• 迭代步骤涉及2个不同的任务： Task1 和 Task2 。
• 为了完成 Task1 ，需要来自 Database1的 数据。
• 为了实现 Task2 ，还需要来自其他数据库（即 Database2）的 外部数据。
• 经过 任务1 完成， 任务2 需要应用。
• Task1 和 Task2 也需要访问 Object1
• 完成这两项任务后， Object1 的状态将更改，并且一个迭代步骤已完成。

该迭代/模拟任务平均涉及 10,000个迭代* 步骤。并且平均需要 同时 由多个最终用户启动的 100个迭代/仿真 任务。 *

现在，由于生产中应用程序所需的 可伸缩性* ，我们讨论了该问题的 微服务架构 。出于开发目的，这也是至关重要的，因为 最近向
Task1和Task2 添加了新功能/参数， 并且 在开发中 具有 不同的缩放比例 。
*

因此，为避免出现 网络瓶颈 ，包括每次迭代中对数据库的持续访问以及Task1和Task2之间的发送数据，什么样的系统架构才适合解决此问题？

对于Task1和Task2，是否应该至少有 两种不同的服务
，甚至对于实际的迭代/仿真状态控制，甚至应该有一项？有人可以告诉我们更多有关使用内存数据网格解决方案（如 hazlecast）
或仅使用内存数据库（如 redis） 来解决此问题的信息吗？

这里的主要问题是可能由于通信/网络瓶颈而导致微服务体系结构的参数是什么？加快速度的唯一方法是在内存中生成模拟任务所需的所有数据，并始终将其保存在那里，以避免网络瓶颈？

感谢您的回答和宝贵的意见。

（此问题与诸如消息传递或REST http（发布/订阅或req / resp）之类的服务间通信无关，它们都可以为该任务施加很大的网络负载。）

Answer 1

现在，由于生产中应用程序所需的可伸缩性，我们讨论了该问题的微服务架构。出于开发目的，这也至关重要，因为最近已向Task1和Task2添加了新功能/参数，并且在开发中具有不同的缩放比例。

这正是流处理平台的优势所在。我建议使用类似Apache Kafka或Apache
Pulsar的系统
来解决此问题。

对于Task1和Task2，是否应该至少有两种不同的服务，甚至对于实际的迭代/仿真状态控制，甚至应该有一项？

Task1和Task2是所谓的 流处理器 ，它们读取（订阅）一个 主题 ，进行一些操作/转换，然后写入（发布） 另一个主题 。

这里的主要问题是可能由于通信/网络瓶颈而导致微服务体系结构的参数是什么？加快速度的唯一方法是在内存中生成模拟任务所需的所有数据，并始终将其保存在那里，以避免网络瓶颈？

同样，这正是Apache Kafka或Apache Pulsar之类的系统运行良好的问题。要在流处理系统中 扩展 读写，您可以对 主题 进行
分区 。 __