微服务架构，用于频繁访问数据；在内存解决方案中？
让我们定义以下 ：
- 必须完成一个模拟任务，其中涉及[ ]上的迭代/模拟。迭代的每个步骤都取决于先前的步骤，因此顺序是预先定义的。
- 任务具有由 表示的状态，该对象将在迭代的每个步骤中更改。
- 迭代步骤涉及2个不同的任务： 和 。
- 为了完成 ，需要来自 数据。
- 为了实现 ，还需要来自其他数据库（即 外部数据。
- 经过 完成， 需要应用。
- 和 也需要访问
- 完成这两项任务后， 的状态将更改，并且一个迭代步骤已完成。
该迭代/模拟任务平均涉及 由多个最终用户启动的 任务。 *
现在，由于生产中应用程序所需的 。出于开发目的，这也是至关重要的，因为
Task1和Task2 并且 。 *
因此，为避免出现 ，包括每次迭代中对数据库的持续访问以及Task1和Task2之间的发送数据，什么样的系统架构才适合解决此问题？
对于Task1和Task2，是否应该至少有
，甚至对于实际的迭代/仿真状态控制，甚至应该有一项？有人可以告诉我们更多有关使用内存数据网格解决方案（如
或仅使用内存数据库（如 来解决此问题的信息吗？
这里的主要问题是可能由于通信/网络瓶颈而导致微服务体系结构的参数是什么？加快速度的唯一方法是在内存中生成模拟任务所需的所有数据，并始终将其保存在那里，以避免网络瓶颈？
感谢您的回答和宝贵的意见。
（此问题与诸如消息传递或REST http（发布/订阅或req / resp）之类的服务间通信无关，它们都可以为该任务施加很大的网络负载。）
回答：
现在，由于生产中应用程序所需的可伸缩性，我们讨论了该问题的微服务架构。出于开发目的，这也至关重要，因为最近已向Task1和Task2添加了新功能/参数，并且在开发中具有不同的缩放比例。
这正是流处理平台的优势所在。我建议使用类似Apache Kafka或Apache
Pulsar的系统来解决此问题。
对于Task1和Task2，是否应该至少有两种不同的服务，甚至对于实际的迭代/仿真状态控制，甚至应该有一项？
Task1和Task2是所谓的 流处理器 ，它们读取（订阅）一个 主题 ，进行一些操作/转换，然后写入（发布） 另一个主题 。
这里的主要问题是可能由于通信/网络瓶颈而导致微服务体系结构的参数是什么？加快速度的唯一方法是在内存中生成模拟任务所需的所有数据，并始终将其保存在那里，以避免网络瓶颈？
同样，这正是Apache Kafka或Apache Pulsar之类的系统运行良好的问题。要在流处理系统中 扩展 读写，您可以对 主题 进行
。 __
以上是 微服务架构，用于频繁访问数据；在内存解决方案中？ 的全部内容， 来源链接： utcz.com/qa/409322.html
