当我们提到 SOA 或中间件时，通常在应用程序和企业集成的情况下，我想知道消息驱动环境和事件驱动环境之间是否有明显的区别。我知道用户界面类似于事件驱动模型，我们的系统在其中拦截用户的操作。
同样很明显，消息传递支持基于发布/订阅、同步或异步通信、事务等的系统。
但是中间件/soa/应用程序集成上下文有区别吗？ （架构级别）。我正在尝试查阅维基百科等来源（here 和 here），但我仍然有些困惑。开发人员何时应该更喜欢一种解决方案？
是否存在一种方法比另一种方法更有意义的示例或案例？或者任何综合资源和实施指南？
非常感谢您的任何见解。
【问题讨论】：
标签： events integration soa messaging middleware
对“是否有明显区别”的简短回答是“否”。
这些术语不能完全互换，但暗示相同的基本架构 - 特别是您将触发事件或消息。
您引用的第一篇文章是关于代表您传输消息的低级管道、MOM 或 pub-sub“总线”。事件驱动架构是您在该框架之上构建的。
术语事件驱动虽然也适用于 GUI 代码，但并不是真正处于同一抽象级别。在这种情况下，与按照消息/事件驱动线构建整个企业相比，这是一种小型模式。
【讨论】：
事件驱动架构可以在有或没有消息的情况下实现。消息传递是以可靠、有保证的方式将生产者提出的事件传达给消费者的一种方式。特别是当生产者和消费者真正解耦并且可能托管在不同的服务器/虚拟机/环境上并且不能直接访问任何共享内存时。
但是在特定情况下——当事件的消费者是在同一个应用程序本身注册的函数/回调时，或者当消费者需要同步执行时，则可以在没有消息传递的情况下实现事件订阅。
【讨论】：
正如this 文章中所说的那样，为了理解事件驱动设计，我们必须观察它隐藏的内容，而不是查看它所呈现的内容，这只不过是编程的基础； “调用堆栈”。
在事件驱动设计中，方法调用的定义直接出现在窗口之外。没有更多的调用者和被调用者。那是对顺序和秩序的吻别。系统不需要知道事情必须以什么顺序发生。因此， 作为调用堆栈的先决条件的共享内存空间变得不必要了。
然而，在调用堆栈环境中，调用者不仅必须知道接下来会发生什么，而且还必须能够将功能与方法名称相关联。
默认情况下，面向消息的应用程序会删除共享内存。发布者和订阅者不需要共享内存空间。另一方面，所有其他特性（即顺序、方法名称耦合等）都不是必需品。
如果消息传递的设计是为了符合事件驱动架构的公理，那么它们可以被认为是相同的。否则它们之间会有很大的不同。
【讨论】：
如果我们使用事件驱动的方式，我们通常希望在这个事件中发送源对象——发布事件的组件。所以在订阅者中我们不仅可以获取数据，还可以知道谁发布了这个事件。例如。在移动开发中，我们会收到 View，它可以是 Button、Image 或一些自定义 View。根据这个视图的类型，我们可以在订阅者中使用不同的逻辑。在这种情况下，我们甚至可以添加一些后处理，修改源组件 - 例如为这些源视图添加动画。
当我们使用消息驱动的方法时，我们只想发布带有一些数据的消息。发布此消息的订阅者无关紧要，我们只想接收数据并以某种方式处理它。
【讨论】：
这里是 Typesafe/Reactive 关于 Jonas Bonér 问题的观点。来自this blog post第三段：
不同之处在于消息是定向的，事件不是——一条消息有一个明确的可寻址接收者，而一个事件只是发生给其他人 (0-N) 观察它。
【讨论】：
事件驱动架构和消息驱动架构是两个不同的东西，解决两个不同的问题。
事件驱动架构的重点是如何触发系统运行。在 EDA 上下文中被视为事件的大多数触发器是通过键盘和鼠标以外的方式生成的事件。如果它能让我们明确地考虑事件生成器、事件通道、事件处理引擎，那么它就是一个 EDA。
键盘和鼠标是显而易见的事件生成器，但这些事件的处理已经由各种框架或运行时负责，作为架构师，我们无需担心。还有其他特定于特定领域的事件是 Architect 应该考虑的。示例 - 供应链管理事件 - 拣货、包装、发货、分销、零售商、销售等。从工业物联网类型应用程序的技术角度来看，事件是 - RFID 读取、生物识别读取、传感器数据、条形码扫描、系统生成的事件是需要明确注意的事件，因为这些事件会驱动系统的功能。
消息驱动架构的重点是通过使用标准的面向消息的中间件将消息从一个模块传递到系统的另一个模块来集成分布式系统。
【讨论】：
这个问题是很久以前提出的。我认为Reactive Manifesto 中的Message-Driven (in contrast to Event-Driven) 给出了更现代、更清晰的回应：
消息是发送到特定目的地的数据项。事件是组件在达到给定状态时发出的信号。在消息驱动的系统中，可寻址的接收者等待消息的到达并对它们做出反应，否则就处于休眠状态。在事件驱动的系统中，通知侦听器附加到事件源，以便在事件发出时调用它们。这意味着事件驱动的系统专注于可寻址的事件源，而消息驱动的系统则专注于可寻址的接收者。消息可以包含编码事件作为其有效负载。
【讨论】：
假设您正在为电子商务网站构建支付服务。下订单后，订单服务将要求您的支付服务授权客户的信用卡。只有在信用卡获得授权后，订单服务才会将订单发送到仓库进行包装和运输。
您需要就如何将信用卡授权请求从他们的服务发送到您的服务与处理订单服务的团队达成一致。有两种选择。
事件驱动方法的一个优点是其他服务也可以订阅各种事件。例如，可能有一个 RevenueReporting 服务订阅 AuthorizationAccepted 事件并为财务团队创建报告。
事件驱动方法的一个缺点是整个系统变得有点难以理解。例如，假设处理 Order 服务的团队要求您根据信用卡被拒绝的原因（没有资金、帐户关闭、帐单地址不正确等）用不同的事件替换 AuthorizationDeclined 事件。如果您停止发布 AuthorizationDeclined 事件，那会破坏其他一些服务吗？如果您有很多活动和服务，这可能很难追踪。
【讨论】：
消息概念是抽象的，更具体的消息类型是事件和命令。
虽然消息根本没有特殊意图，但事件会告知已经发生和已经完成的事情（过去）。命令触发了应该发生的事情（将来）。
【讨论】：
在OO中，调用者和被调用者之间通过消息方式进行交互...在GUI中，我们总是说事件驱动。我们可以看到，如果我们需要管理发布者和订阅者的关系，我们应该使用事件驱动。如果我们管理上游和下游底层更抽象，没有强依赖（比如上游不知道下游），我们应该使用消息驱动。所以在 Message-Middleware 上下文中，并没有明显的区别，是构造上的区别，而不是设计上的区别。
【讨论】：
据我说：
【讨论】：
我在谷歌搜索时遇到了这个线程，以区分消息和事件之间的差异。在阅读了上述所有回复后，我仍然没有找到答案。
然后我尝试了更多谷歌搜索并为我找到了答案，所以我将把它留在这里，希望对喜欢我的人有所帮助。
消息是发送到特定地址的一些数据。在消息驱动系统中，每个组件都有一个唯一的地址，其他组件可以向其发送消息。这些组件或收件人中的每一个都在等待消息并对它们做出反应。
事件是组件发出的一些数据，供任何收听的人使用。
【讨论】：