问反应式编程和事件驱动架构有什么区别？

EN

反应编程

许多人已经认识到，对某种现代大规模软件系统来说，某种所需属性的组合越来越重要。同时，这些属性满足了典型的与可伸缩性、灵活性、健壮性、资源消耗等相关的非功能需求。这种新出现的概念被发明为反应性，而构成反应系统的属性集已在反应宣言中定义。其主要特点是:响应性、弹性、弹性和消息驱动能力.目前，这可能是最广泛的反应系统的定义。基于这种反应系统的一般概念，可以假定反应性编程是指任何有助于在软件中实现这些特性的范式、模式或技术。

尽管如此，在更技术性的层面上，反应性编程目前被理解为一种编程模型，传统上被称为数据流编程，它正在复兴，因为它在越来越多的编程语言、框架和库中被用来提供上述属性。

构成反应系统特性的系统通常使用数据流编程的一个变体，其中明确处理组件之间的消息有助于容错、处理背压，并通过非阻塞通信在高度动态的设置中有效地使用资源。

事件驱动体系结构

事件驱动的体系结构是一个定义相当模糊的体系结构模式的总称，某些人认为它对某些应用程序越来越有用。在这种情况下，这一概念很大程度上源于企业软件社区中出现的模式，在这种模式中，微服务作为一种分解和部署模式出现，以提供某些组织效益，即帮助在大型项目中分配工作。

虽然软件开发中的许多经典概念，例如面向对象的编程，可以被认为是事件驱动的--参与者之间的通信可以被看作是事件--尤其是通过将事件视为当前被理解为事件驱动的基本构建块来设计应用程序的化身。通常，人们还会联想到几种扩展这一基本概念的模式，比如事件源，以及CQRS，以提供一些目前看来对某些应用程序有利的好处。

比较

相比之下，这两个概念的核心是异步通信以使组件解耦。事件和信息是相关的概念，主要是每个术语所强调的意图不同。因此，它们是两个概念的共同组成部分。从严格意义上说，今天的事件驱动是作出反应的先决条件。就我个人而言，我可以想象其他范例可能会出现，以实现再生系统所期望的行为特性。

反应宣言强调了与系统在运行时的行为和动态响应有关的上述质量属性，而事件驱动的体系结构则侧重于系统如何被分解，以及系统的各个部分是如何交互的。从这个意义上说，反应系统的观点是一个相当行为主义的观点，尽管它具有与其内部行为有关的某些性质，但我的印象是，这些内部性质在性质上可能是偶然的，即可以通过不同的手段来实现所希望的行为特性。

目前，每个概念在软件系统上都有不同的视角，具有不同的典型关联，强调不同的方面，并侧重于实现不同的目标。然而，随着概念的发展，它们可能会不断地被重新调整，并可能出现分歧或趋同。

事件驱动体系结构(EDA)是一种促进事件产生、检测、消费和反应的体系结构模式。它们通常通过通知消息广播。这就解释了为什么EDAs常常利用消息传递集成风格，它依赖某种消息代理来实现称为集线器和辐式的拓扑。有许多著名的RabbitMQ、NATS、Kafka、IBM (前MQSeries)、MSMQ、Amazon和SNS、等著名示例。

反应性编程是实现事件驱动编程的一种方式吗？

是的，虽然不是唯一的。反应性编程是一种声明式的、事件驱动的编程范式，涉及到数据流和变更的传播.驱动逻辑前进的是新信息的可用性，而不是由执行线程驱动的控制流。它支持将问题分解为多个离散步骤，其中每个步骤都可以以异步和非阻塞的方式执行，然后组成以生成一个工作流--可能在其输入或输出中没有限制。

2011年，微软( Microsoft )的埃里克·梅耶尔( Erik Meijer )创建了一种名为“反应性扩展”( .NET )的反应性编程框架，这套工具允许命令式编程语言对数据序列(数据流)进行操作，而不管数据是同步的还是异步的，它开始受到主流的特别关注。在几年内，反应性扩展(也称为Rx)被移植到几种语言和平台上，包括JavaScript、Python、C++、Swift和Java。

在JVM世界中，反应流在2013年底开始作为Pivotal (现在的VMware)、Netflix和Typesafe (现在的亮点)的工程师之间的一项倡议。

反应性编程背后的基本思想是，事件是数据，数据是事件。

反应性编程是一个可以用于实现构建块的范例，因此它的范围在组件/服务中。EDA是一种体系结构风格，它涉及组件/服务之间的交互。

。

反应性编程--在抽象级别--使用异步数据流处理解耦流。然而，几乎所有实现异步数据流的行业标准都是通过事件驱动的范式来实现的，而且大多数的反应性实现都使用这种方法。

如果有更好的方法来创建解耦的流，那么使用这种方法的反应性编程也是可能的。