让我们定义以下 用例 ：

• 必须完成一个模拟任务，其中涉及[ 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）之类的服务间通信无关，它们都可以为该任务施加很大的网络负载。）