algorithm - 微服务和发布状态与状态变化

Question

假设我想要一个系统，其中服务 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算法没有bug

而如果整个状态都已发布，则

• 如果以错误的顺序消费了 2 个已发布的事件，则发布第 3 个事件可以纠正一切
• 如果已发布的事件未能被使用，则发布第三个事件可以纠正一切
• 没有增量算法，因此发布服务的复杂性和计算资源更少

我能想到的一些解决方案可以使 delta 方法更加稳健，但增加了很多复杂性:

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

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

Answer 1

这是一个很好的问题。如果您想进一步阅读，发布增量的语义本质上就是创造事件驱动架构的东西。

事件(增量，在您的定义中)给您带来的主要优势是透明度。事件很小且受限，因为它们定义了系统中发生的事情并且是可追踪的。如果您需要捕获其他行为，则可以添加事件类型。当状态发生变化时，它对发生的事情缺乏透明度；您可能必须回溯到所有不同的状态并弄清楚发生了什么，如果它们出现问题，则可能很难推理。

还有以下几点，

跟踪增量

There is no bug in the delta algorithm

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

跟踪状态

If a published event fails to be consumed then publishing a 3rd corrects everything

如果负责状态更改的服务有错误并将记录更新为无效状态怎么办？发布相同的第三状态将反射(reflect)依赖于状态更改的下游系统中的一致错误。使用此处的事件可以分离这两种语义，本质上是状态和发生的事情。