现代数字业务实时运作。当它们发生时，它会向感兴趣的各方通报感兴趣的事物。它可以从越来越多的资源中获取并获得洞察力。它学习，预测并且聪明。从本质上讲，它是事件驱动的。
事件是捕获事实陈述的一种方式。事件发生时，事件会连续发生。通过利用这种连续流，应用程序可以根据过去发生的事情对未来作出反应和推理。
对于企业IT团队而言，采用事件驱动的开发是下一代数字业务应用程序的基础。 IT团队必须以云原生样式设计，开发，部署和运营事件驱动的解决方案。
事件驱动的体系结构和反应式编程模型不是新概念。但是，当您迁移到具有微服务，基于容器的工作负载和无服务器计算的云原生架构时，您可以在云原生环境中重新访问事件驱动的方法。将事件驱动的体系结构视为将云原生体系结构的弹性，敏捷性和可扩展特性扩展为具有响应性和响应性。
云原生架构的两个方面对于开发事件驱动架构至关重要：
- 微服务提供松散耦合的应用程序体系结构，支持以高度分布的模式进行部署，以实现弹性，灵活性和扩展性。
- 具有容器和无服务器部署的云原生平台提供了实现微服务架构的弹性，灵活性和可伸缩性的应用程序平台和工具。
事件驱动架构（EDA）是一种应用程序部署模式，至少在20年前创建并被许多公司使用。 通过混合云本机实现和微服务采用，EDA通过帮助解决微服务的松散耦合需求并避免复杂的通信集成而获得了新的关注点。 采用发布/订阅通信模型，事件源，命令查询责任隔离（CQRS）和Saga模式有助于实现支持云部署的高可扩展性和弹性的微服务。 EDA正在成为敏捷架构的强制方法，并为开发事件和处理事件流以添加人工智能服务提供机会，从而获得分析。 ----- Jerome Boyer，STSM，云架构解决方案工程
事件
事件是状态变化的通知。发布或发布通知，感兴趣的各方可以订阅并采取行动。通常，通知的发布者不知道采取了什么动作，并且没有收到通知被处理的相应反馈。
通常，事件代表业务感兴趣的事物的状态变化。事件是发生的事情的记录。它们无法改变。你无法改变过去发生的事情。
事件流
事件流是一系列连续无限的事件。在开始处理流之前，可能会启动流的开始。流的结尾在未来的某个未知点。
事件按每个事件发生的时间排序。在开发事件驱动的解决方案时，通常会看到以下两种类型的事件流：
- 其事件被定义并作为解决方案的一部分发布到流中的流。
- 连接到事件流的流。示例包括来自物联网（IoT）设备的事件流，来自电话系统的语音流，视频流，或来自全球定位系统的船或平面位置。
命令
命令是做某事的指令。通常，命令指向特定的消费者。消费者运行所需的命令或过程并将确认传递回发行者。确认表明该命令已被处理。
事件和消息
消息传递在IT系统中有着悠久的历史。您可以在消息传递系统和消息的上下文中看到事件驱动的解决方案和事件。但是，这些特性值得考虑：
- 消息传输有效负载并持续存在直到它们被消耗。消息使用者通常直接被定位并且与关心消息被传递和处理的制作者相关。
- 事件将作为可重播的流历史记录保留。事件消费者与生产者无关。事件是发生事件的记录，因此无法更改。
松耦合
松耦合是事件驱动处理的主要优点之一。它允许事件生成器发出事件，而不知道谁将使用这些事件。同样，事件使用者不需要知道事件发射器。由于松耦合，事件消耗模块和事件生成器模块可以用不同语言实现，或者使用不同且适合特定作业的技术。
松散耦合的模块更适合独立发展。当它们正确实现时，松散耦合的模块会导致系统复杂性显着降低。
然而，松耦合并不意味着“没有耦合”。事件使用者使用有助于实现其目标的事件，并且这样做可以确定所需的数据以及该数据的类型和格式。事件生产者发布它希望被消费者理解和使用的事件，与潜在消费者建立隐含的合同。
例如，XML格式的事件通知必须符合消费者和生产者必须知道的某个模式。在事件驱动的系统中减少耦合可以做的最重要的事情之一是减少在模块之间流动的不同事件类型的数量。要减少事件类型的数量，请注意这些模块的内聚性。
凝聚
内聚是相关事物封装在同一软件模块中的程度。出于本讨论的目的，模块是具有高内聚性的可独立部署的软件单元。 Cohesion与耦合有关，因为高度内聚的模块与其他模块的通信较少，减少了系统中事件和事件类型的数量。
模块之间相互作用的频率越低，它们的耦合就越少。在优化模块尺寸以实现灵活性和适应性的同时实现软件的凝聚力是困难的，但是需要努力。设计凝聚力始于理解问题领域和良好的分析工作。有时，您还必须考虑支持软件环境的约束。避免使用过于细粒度的单片实现和实现。
下一步是什么
既然您已了解事件驱动解决方案的概念和价值，那么请学习如何在事件驱动的参考架构中构建一个。
原文：https://www.ibm.com/cloud/garage/architectures/eventDrivenArchitecture
本文：
讨论：请加入知识星球或者小红圈【首席架构师圈】