Axon框架和断路器

Question

我一直在探索轴突框架和事件源。我现在有一个问题。是否有可能在事件源设计模式（例如轴突）中使用hystrix实现断路器模式？我也一直在研究hystrix，从中可以理解，最好在具有使用REST进行相互通信的微服务体系结构的情况下使用，但是在发生事件保证的情况下，我们没有这种情况。

所以我的问题是断路器模式对事件源微服务架构师有效吗？

Answer 1

首先是一个伟大而有趣的问题！

---

简短回答：断路器和CQRS是两种完全不同的模式，可以解决不同的问题，因此，可以独立使用，也可以一起使用，具体取决于要解决的问题。无论是Axon模式还是事件源模式都不表明您具有或不具有基于微服务的体系结构。

Axon是一个非常灵活的框架，它[[既适合简单的单片应用程序，也适合基于分布式微服务的]架构。

---

下面是更长的答案：

在Axon中有几个关键概念：

命令处理程序
• 事件存储+聚合
• 事件处理程序
• 查询处理程序
• 这个想法基本上是这样的：

您可以分派
1. Command，该命令基于指定的Command Handler，将：从
2. 事件存储
加载Aggregate，并通过一些验证，将应用该事件，然后您的所有
3. 事件处理程序
将触发。查询处理程序是故事的另一面，这基本上意味着您的某些组件希望获取一些数据，并且对此类数据的每个请求都分派到一个或多个查询处理程序。
4. 有关这些概念的更详细概述，请看here。

---

另一方面，

Circuit Breaking

模式是一种允许应用程序内部弹性且不允许请求被淹没的模式。

---

有几种可能的情况，您可以在Axon中一起应用Breaking Breaking：

太多的
1. 数据请求可能会使您的查询处理程序不堪重负（请考虑DDoS尝试或流量突然增加），并且您可能没有能力扩展基础基础结构。但是，如果您有一些默认值可以用作替代查询处理程序，则可以使用这些默认值。

在查询处理中使用断路器的示例情况可以作为推荐引擎，当断路器打开时，您将提供一些默认产品，而不是提供个性化产品。

类似地，如果您有太多命令，则您的基础架构也可能无法处理该命令。每个命令通常都需要从事件存储中加载Aggregate，应用一些验证，甚至可能进一步向事件处理程序触发一些事件。如果输入的命令过多，则基础事件存储和事件处理程序可能会崩溃或停止运行，这是您可以应用Circuit Breaker模式的另一个地方。

在CQRS命令处理中使用断路器的示例情况可以是一个简单的系统，您可以在其中允许用户创建其帐户，更改其名称并删除其帐户。如果有任何一组特定用户不时地开始更改其名称，则完全可以。但是，如果突然之间，用户决定每秒更改10000次用户名，这对于您的基础数据库可能就太大了。这就是为什么如果您检测到这种行为，则可以为该特定用户应用断路器模式，并让他们“冷静下来”，以使您的正常流量不受干扰。

---

这只是一些简单的场景，在这些场景中可以一起使用CQRS和Circuit Breaker模式，但可能性无限。

最后一点

是resilience4j作为Hystrix的替代产品，因为近年来它的用户群和采用率迅速增长，并且比Hystrix轻巧得多。此外，如Hystrix's github page中所示：

Hystrix不再处于主动开发中，并且当前处于维护模式。

和

[在类似Hystrix的情况下，我们打算继续将Hystrix用于现有应用程序，并将诸如resilience4j之类的开放式活动项目用于新的内部项目。我们开始建议其他人也这样做