Algorithm 微服务和发布状态与状态更改

假设我想要一个系统，其中服务

B

的状态应该根据服务

a

状态的变化进行更新。当

A

的状态更改时，它可以发布

• 整个州
• 只有它的状态变化

比如说，

A

在时间点上的状态

 t0  | [ ]
------------------
 t1  | [X,  Y]
------------------
 t2  | [X', Y]
------------------
 t3  | [X', Y, Z]
------------------
 t4  | [X',    Z]

它可以发布当前状态的每个快照（右列），也可以只发布以下更改

-----------------------
 delta(t0, t1)| +X, +Y
-----------------------
 delta(t1, t2)| X->X'
-----------------------
 delta(t2, t3)| +Z
-----------------------
 delta(t3, t4)| -Y

这在理论上可以创造一个优化。但我认为必须保证的几件事是

• 已发布的事件按正确的顺序使用
• 服务“遗漏”的已发布事件需要识别并以某种方式补偿
• delta算法中没有错误

而如果整个州都公布了

• 如果以错误的顺序使用了两个已发布的事件，则发布第三个事件将更正所有问题
• 如果发布的事件无法使用，则发布第三个事件将更正一切
• 没有增量算法，因此发布服务的复杂性和计算资源更低

我可以想出一些解决方案，使delta方法更加健壮，增加了很多复杂性：

• 发布整个状态的更改和指向上一个事件的指针。使用事件的服务可以确定是处理增量还是整个数据集
• 发布增量和整个状态之间的“循环”。也许发布更改9/10次，然后在另外1/10的时间发布整个状态，只是为了帮助纠正错误

---

这两种感觉都很奇怪。我感兴趣的是，是否存在一个健壮的解决方案，用于通知“添加、删除和修改”，同时确保系统中的最终一致性。

这是一个非常好的问题。如果您想进一步阅读，发布增量的语义本质上是由事件驱动体系结构创造的

事件（Delta，在您的定义中）给您带来的主要优势是透明度。事件是小的和受限的，因为它们定义了发生在系统上的事件，并且是可跟踪的。如果需要捕获其他行为，可以添加事件类型。而随着国家的变化，它对所发生的事情缺乏透明度；你可能需要追溯到所有不同的州，弄清楚发生了什么，如果它们不正常，可能很难推理

并就以下几点,

跟踪三角洲 delta算法中没有错误

我认为这并不难设想。实现将相当简单，因为您将检查事件类型并对其进行操作，因此分支中的处理应该非常小，难以处理

跟踪状态 如果发布的事件无法使用，则发布第三个事件将更正一切

---

如果负责状态更改的服务出现错误并将记录更新为无效状态，该怎么办？发布相同的第三状态将反映依赖于状态更改的下游系统中的一致错误。在这里使用事件将这两种语义分离开来，本质上是状态和发生的事情。

第三个选项是发布的事件不包含任何状态信息，事件使用者负责从生产者中提取状态。事件可能包含对生产者的回调和/或已更改数据的ID

当然，对于消费者来说，最不复杂、效率最低的解决方案是盲目地按计划从生产者那里获取数据