问用Kafka实现传奇

EN

这篇来自今年DDD的演讲是我在事件驱动/ eXchange系统中遇到的最好的资源：https://skillsmatter.com/skillscasts/9853-long-running-processes-in-ddd (需要注册一个免费的帐户才能查看)

显示的演示位于github上：https://github.com/flowing/flowing-retail

我给它一个旋转，我很喜欢它。我建议先看视频，然后再做准备。

尽管所显示的方法是消息总线不可知的，但演示使用Kafka让流程管理器向其他有界上下文发送命令并侦听来自这些上下文的事件。它不使用Kafka Streams，但我不明白为什么它不能插入到Kafka Streams拓扑中，并成为更广泛架构的一部分，就像您引用的Commander演示文稿中描述的那样。

我希望根据我们自己的需要进一步研究这一点，所以请在Kafka用户邮件列表上自由地开始一个线程，这是一个很好的地方来合作这些模式。

希望这能有所帮助:-)

我想在这里补充一些关于sagas和Kafka的东西。

总体而言

一般来说，Kafka与普通队列略有不同。它在可伸缩性方面尤其出色。这实际上会导致一些复杂的情况。

Kafka是实现伸缩的一种方法，它使用数据流的分区。数据放在分区中，可以按自己的速率使用，独立于同一主题的其他分区。这是关于它的一些信息：how-choose-number-topics-partitions-kafka-cluster。我会回来解释为什么这很重要。

要确保Kafka中的顺序，最常见的方法是：

• 使用1个分区作为topic
• 使用partition message键将消息“分配”给topic

在这两种情况下，按时间顺序排列的消息都需要流经同一主题。

此外，正如@pranjal thakur指出的那样，请确保将传递方法设置为“恰好一次”，这会影响性能，但会确保您不会多次收到消息。

注意事项

现在，需要注意的是:当更改分区的数量时，分区上的消息分布(当使用键时)也会发生变化。

在正常情况下，这可以很容易地处理。但是，如果您有一个高流量的情况，迁移到不同数量的分区可能会导致在某个时刻，在多个分区上处理saga-“流”，并且在该点上不能保证顺序。

这是否会成为您的场景中的一个问题由您决定。

以下是您可以询问的一些问题，以确定这是否适用于您的系统：

• 如果您需要使用Kafka将数据迁移/复制到新系统，会发生什么情况？

(高流量scenario)

• Can您将数据发送到1个主题？

• 在您的saga服务临时中断后会发生什么？

(当您需要重放一大堆消息时，会出现低可用场景/高流量scenario)

• What？

(如果我们需要增加分区，是否会出现高流量scenario)

• What？

(高流量情况/停机和恢复情况)

另一个选择

如果你正在考虑建立一个基于步骤的传奇，就像状态机一样，我建议你重新考虑一下你的设计。

我举个例子：

让我们考虑一个预订酒店房间的流程：

简而言之，它可能包含以下步骤：

• 处理预订的房间(传入event)
• Handle房间已付费(传入事件)
• 发送预订确认(在已付费和一些处理之后)

现在，如果你的saga不能处理付款，如果预订还没有到来，那么你就依赖于事件的顺序。

在这种情况下，你应该问自己:什么时候会崩溃？

如果你得出结论，你想要避免时间依赖性；考虑一个没有saga的系统，或者一个不依赖于事件顺序的saga -即:接受所有消息，即使还没有轮到他们。

下面是一些例子：

作为业务流程的

• aggregators
• Modeled : parallel gateways (parallel process flows)

请注意，在这样的设置中，更重要的是每个操作都有一个实现的补偿操作(回滚操作)。

我知道这通常很难做到；但是，如果你从小事做起，你可能会开始喜欢它:-)