如何解决在事件驱动的微服务架构中维护远程状态的最佳实践是什么？
- 假设我有一个包含复杂域对象（例如用户、项目、事务等）的 Web 应用程序，因此每个对象都有多个嵌套字段、嵌套子对象数组等。 这些对象的（可变）状态是通过像 MongoDB 这样的文档存储来维护的。
- 假设我希望将 域 事件触发到事件总线（例如 Kafka） - 例如，“付款已支付”或“帐户试用开始”或“项目分叉”等。
- 假设我希望外部服务使用这些域事件并对其进行操作 - 但具有自己的状态。例如，某些外部服务可能希望聚合每个用户的所有交易（匹配某些业务逻辑条件），并在新事件到达时不断更新此聚合。
- 假设我想对这种聚合状态的变化实时做出反应，例如，我可能希望在用户交易超过 100 万美元时发送警报。
现在，问题是：
考虑到原始对象的复杂结构以及需要应用任意业务逻辑的多种方式，我如何在流上下文中可靠地维护远程服务上的状态聚合？
例如，我可能决定将用户居住在加拿大且迄今为止交易少于 19 笔的情况排除在警报通知之外，除非这些交易中有 5 笔是通过信用卡支付的-卡片，由名为“Joe”的人提供
如果这只是原始数据库的简单复制（由“哑巴”CDC 流持续提供），我可以通过 sql 对静态数据轻松地制定查询，但那样我就会失去效率流处理 - 即 - 在新事件到达时仅计算现有状态的增量 - 并实时对其做出反应。
但是，为了在非复制存储（无论是否在内存中）中保持这种状态，我需要手动制作和维护我的复制“版本”原始网络应用程序，我在其中描述了每个事件如何改变对象的状态。例如，这种重复的逻辑可能是：“如果项目所有权从一个用户转移到另一个用户，请转到该项目的每个关联子对象，并相应地更新它们，更改字段、updated_at 日期等。”>
即使我放弃支持“任意查询或条件”的想法并将自己限制在预定义的集合中，这似乎也是正确的...
查看有关该主题的文献和资源，我只能找到有关如何处理涉及琐碎逻辑的简单事件（例如“对过去一小时内每个用户的交易求和”）的模糊参考 - 或 - 关于如何处理的建议插件CDC，基本上是将整个DB复制到另一个地方
我如何克服这种权衡：
- 对静态数据进行批处理 - 通过 CDC 从原始数据复制 - 创建数据简单可靠，对数据做出反应并重新计算聚合速度缓慢且效率低下
- 对移动中的数据进行流处理 -- 极难重新创建原始业务逻辑以支持某些类型的查询，但是 - 计算本身是本地的，仅适用于增量，因此非常高效
这是考虑到我们希望流处理的范围是整个历史，而不是某个“最近的时间窗口”
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。
