0

我们目前正在 Akka.NET 之上使用 DDD 原则构建一个演员系统。

在如何使我们的服务具有弹性方面，我们有几个缺失点：

  • 默认情况下，Actor 之间的 At-Most-Once-Delivery
  • 演员邮箱的弹性
  • FSMactor 正在存储无法立即处理的传入消息 - 弹性？
  • Pub/Sub 模式（和弹性）

如果某些消息丢失，我们不确定该怎么办，因此我们无法转换到下一个状态以完成涉及多个参与者的请求。

我的想法是使用像 kinesis 这样的事件流系统来传递消息。然后，我们到处都有弹性，只需要知道我们处理了流中的哪个事件。我还缺少其他东西吗？你认为这是个好主意吗？这是否违反了一些最佳实践？

4

1 回答 1

0

对于 Akka.NET（实际上是所有流行的分布式参与者模型实现），最多一次交付是经过深思熟虑的选择。过去，来自 JVM 的原始 Akka 在持久队列上实现了邮箱实现，但这个想法在几年前因为实验失败而被放弃。

  • Akka.NET 主要面向消息传递。对于每个用户请求，参与者之间可能会传递数十条（或数百条）消息以对其进行处理。使用内存消息，这既快速又简单（Akka.NET 可以在单台机器内传递数百万条消息/秒）。
  • 通常，当谈到可靠处理时，您想到的并不是可靠的、持久的邮箱，这很重要。线索是可靠地处理消息 - 您可以轻松地从队列或日志中删除消息，并且机器会在您完成处理之前中断。
  • 至少一次处理强制您能够识别重复项（除了重新交付之外，对于每个参与者来说，这并不是具有成本效益的），或者将您的所有处理逻辑设计为以幂等方式工作。

在某些情况下，确认就足够了，即用户发送请求并期望响应在某个超时时间内到达。如果回复没有到达，即因为一些消息丢失，只需向请求者返回失败（并可能要求他/她重试）。

另一种常见的模式是在特定的地方使用队列/日志，即作为你的actor系统前面的层。这样，所有用户请求首先发送到持久队列，然后由参与者系统逻辑从中获取。一旦内部的参与者完成处理请求，他们就可以提交它并从队列中删除。如果发生了一些失败，整个过程（或其中的一部分）会被简单地重试。

于 2018-01-21T16:24:46.323 回答