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

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

理论上可以创建优化。但是我认为必须保证的几件事是

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

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

• 如果以错误的顺序消耗了2个已发布事件，那么发布第3个事件将纠正所有情况
• 如果已发布的事件无法使用，则发布第3条会纠正所有问题
• 没有增量算法，因此降低了发布服务的复杂性和计算资源

我可以想到一些使增量方法更加健壮的解决方案，这会增加很多复杂性：

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

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

Answer 1

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

事件（定义中的增量）为您提供的主要优势是透明性。事件很小且受限制，因为它们定义了发生在您系统中的事件并且可追溯。如果您需要捕获其他行为，则可以添加事件类型。当状态发生变化时，它缺乏所发生事件的透明性。您可能必须追溯到所有不同的状态并弄清楚发生了什么，如果它们出故障了，可能就很难推理了。

还有以下几点，

跟踪增量

  

增量算法中没有错误

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

跟踪状态

  

如果已发布的事件无法使用，则发布第3条事件会纠正所有问题

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

Answer 2

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

当然，最复杂，效率最低的解决方案是让消费者按计划盲目从生产者那里提取数据。