事件驱动的体系结构的一些想法

本文只是有关事件驱动的体系结构的一些想法。 这里没有代码，只有观察和建议。 明确地说，我将使用事件驱动一词，但如果您阅读上面的Wikipedia参考，则会发现我也错误地混入了消息驱动系统。

TLDR；

这是关于复杂性的讨论，显然是说，强大的力量伴随着巨大的责任。

基于事件的架构

基于事件的体系结构范式的核心是事件的产生，检测，消耗和反应的解耦。它们应该在反映这一点的代码中进行组织，即与生产，检测，消耗和反应相关的代码应分别分组，并且通常还通过多个应用程序进行分发。尽管事情是有条理的，并且肯定有明确的因果关系，但通过系统的分派机制进行的每次转换都会充当信息壁垒。在许多体系结构中，如果您从第一段代码开始，则可以跟踪在给定情况下从头到尾遵循的代码路径，通常可以使用调试器实时进行。使用基于事件的系统，通过事件分配器的第一跳更有可能使您感冒。您立即面临一个问题，即许多现有的听众/订户中的哪些人将对事件做出响应，他们是否都在此过程中进行响应，是否可以保证收据，以及确定性发生的顺序？

它实际上是一个公开喊价（outcry）系统，在通常情况下，出价（通话）和要约（响应）易于观察和配对，但是在混乱的时期，以观察员的身份进行的所有呼喊变得几乎不可能。

我指的是我正在替换的当前事件驱动系统，称为弹球机，因为球会大量涌入，在周围疯狂反弹，有的会导致奖品弹出，而有的则会消失殆尽。 您必须是粒子物理学家才能认为系统是可预测的和可理解的。

级联混沌的真实示例

我记得读过一次关于航空公司系统停机的事后调查，我相信那是英国航空公司的UPS故障，恢复工作花了几天的时间。为什么？他们的系统都是事件驱动的，并挂在一条通用的消息总线上。随着时间的流逝以及通过企业收购，IT系统的有机增长意味着他们根本不知道到底在听什么，而且系统实施在容错方面也不一致。许多系统需要重新启动以重新建立通信，并且尽管UI可以快速检测和处理，但在不能解决所有问题时，他们显然会蛮力地"重新启动所有"。但是，由于系统之间的相互依赖性以及几乎同时进行的重启，因此并非所有重启均能正常工作。只是随着时间的流逝，通过注意到非功能性功能才发现了一些问题。例如，也许您可以预订航班，选择座位，登记行李，但行李标签不会在希思罗机场的柜台打印。因此，他们必须确定应该发生什么事件链，哪些链断裂了，没有发生什么事件反应以及最后应该由哪个系统执行。

我是否要注意事件驱动系统？

不。它们功能强大，并且在许多情况下绝对是正确的解决方案。 哎呀，我们正在用另一种事件驱动的架构替换弹球机。 什么？！ 是的，这是我们方案中的正确工具。

因此，如果我不是说不使用事件驱动的体系结构，那是什么意思？

确保它们是可追踪的

从第零天开始进行跟踪和恢复：

· 将关联标识符和发起者信息维护到事件中。

· 统一审核/记录命令和事件。

· 请勿使用Blob或任何方案文本（如JSON）。 您希望始终使用通用语言，因为许多分布式部分正在监听。 集中定义事件，并在所有地方使用这些定义。 您想知道更改对整个系统的影响。 提前计划事件的演变变化。 在可能的情况下，请避免对现有字段进行结构更改，而应采用"狂暴/吹扫"方法，在这种情况下，您仅进行累加并直到要清理。

· 研究Zipkin和监视工具之类的东西，以显示跟踪信息。

· 如果另一个系统取决于您的事件，但又不能订阅您的调度程序，而是从某个持久性日志中扫描事件，请确保它们也遵循这些规则，不要在异构边界上停止这些最佳做法。

这些建议似乎过于严格，但是我一次又一次地看到人们认为他们可以在获得一定收入后再解决这些问题，然后当问题确实出现时，发现没有APM或快速解决方案可以追溯地真正修复生态系统。