通过手动轮询从Rest API更改的实体来对事件流进行建模

我的任务是创建一个事件流,从而使我有一个自动轮询器(以10分钟为间隔设置)以检索最近10分钟内所有已更改的实体。

现在,业务逻辑要求我们仅在实体中的特定字段发生更改时才创建新的更新事件。由于没有关于特定字段更改的粒度(我们只知道更改了某些内容),因此我必须创建一种执行以下操作的微分方法:

  1. 获得先前的实体状态
  2. 将此先前状态与最新状态(即diff)进行比较
  3. 如果业务逻辑确定重要的至少一个字段之一,则创建一个更新事件
  4. 如果已创建更新事件,则将前一个实体状态替换为最新状态

鉴于此体系结构问题,是否存在已知的模式或模式集,或有关如何构建此类系统的指南?

yaobaoshun 回答:通过手动轮询从Rest API更改的实体来对事件流进行建模

看看observer patterniterator pattern,以及reactive programming的范例。

请注意,这些是解决状态更改(或事件)处理的通用方法。实现取决于您所使用的编程语言和操作环境。您应该真正寻找现有的框架和库,例如ReactiveX(跨平台)或Spring WebFlux(Java)。

Here is关于概念之间关系的有趣讨论。

,

对此问题的一种规范解决方案将其推倒了:系统应该首先产生更改事件,而不是在更改完成后检测。否则,该API不允许存储新实体版本;相反,它只能允许应用更改。从系统设计的角度来看,向后工作(在完成更改后进行检测)会创建一个更复杂的系统,因为它包含更多步骤。

此方法的最常见实现是Event Sourcing,它也非常适合CQRS。通常将两者放在一起。适当地实现事件源可能是一项艰巨的任务,并且没有充分的理由(当然,您的用例肯定听起来像是一个案例)也不应该使用它。根据产生变更的位置,您可以考虑使用有助于变更跟踪的框架(例如,UI层中的Redux)。


我知道,可能需要将此修改添加到围绕存储实体版本而设计的系统中。在这种情况下,一种可能的解决方案是在两个世界之间建立隔离级别:系统中的一个层,它将实体版本转换为更改流。例如,保留现有的 interface ,但将其 implementation 替换为基于事件的接口。尽早创建事件,而不是混合使用两种方法。

希望这很有道理。

本文链接:https://www.f2er.com/3153055.html

大家都在问