轴突框架和断路器

Question

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

所以我的问题是断路器模式是否适用于事件源微服务架构师？

Answer 1

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

---

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

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

---

更长的答案如下：

在Axon中有几个关键概念：

• 命令处理程序
• 事件存储+聚合
• 事件处理程序
• 查询处理程序

这个想法基本上是这样的：

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

要详细了解这些概念，请查看here。

---

另一方面，电路中断模式是一种允许应用程序内部弹性且不会因请求而变得不堪重负的模式。

---

有几种可能的情况，您可以在Axon中一起应用电路断路器：

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

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

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

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

---

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

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

  

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

和

  

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