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