使用消息队列的微服务架构和事件驱动的架构是否相同

Question

编辑v1： 我一直在看一些系统设计视频，并使用消息队列和事件驱动的体系结构了解了微服务体系结构。

但是我似乎没有发现两者之间有任何实质性的区别。 两者都有不同的组件/服务发布或订阅到 eventBus / messagingQueues ，并执行与已发布事件关联的任务。

带消息传递的微服务体系结构是事件驱动体系结构的子集，还是我需要弄清楚的更多东西。

---

原始V0： 我一直在看一些系统设计视频，并了解了微服务架构和事件驱动的架构。

但是我似乎没有发现两者之间有任何实质性的区别。 两者都有不同的组件/服务发布或订阅到 eventBus / messagingQueues ，并执行与已发布事件关联的任务。

微服务体系结构是事件驱动体系结构的子集，还是我需要弄清楚的更多事情。

Answer 1

简短回答：否，这些不一样，也不是子集。

  

两者都有不同的组件/服务来发布或订阅eventBus / messagingQueue，并执行与已发布事件关联的任务。

这是错误的。对于事件和发布/订阅，微服务不是必需的。

Answer 2

事件驱动架构是一种系统设计概念，我们在其中使用“技术”在系统中实现同步或异步通信。我们极有可能想要异步通信。

这类技术可以是发布/订阅，长时间轮询，排队，网络套接字等。

微服务是一种设计系统的方法，在该系统中，我们使服务彼此分离，或者至少我们会尽力而为。例如，Facebook的新闻源服务独立于其他服务，例如个人资料，照片和消息传递。这样的好处之一是“关注点分离”，因此，例如，如果新闻源出现问题，我们仍然可以继续上传照片并与朋友聊天。如果FB是“整体”，则一项服务故障可能会破坏整个站点。微服务的另一个好处是可部署性，服务越小，测试和部署速度就越快。

让我们以比萨饼为例，确定是将其切成正方形还是三角形，或者切成薄片的大小考虑微服务。首先和下一个应该吃的是事件驱动型思维。您会选择大片，混合片，小片还是肉片？就像我们的系统如何智能地决定下一步触发什么事件一样。

请记住，这些概念可以帮助您了解现有系统，或帮助您决定如何构建系统。在现实世界中，当您加入新公司时，会发现自己在问类似问题

• 系统如何面向服务？
• 数据流有多重要？

---

简短的回答 ...您的问题不一定相关，但是在扩展一个或另一个时，我们不可避免地将它们一起实现。

以这种微服务架构为例

 [checkout service] ---> [email service]

比方说，用户等待很长时间才能结帐并发送电子邮件。 90％的等待来自电子邮件服务。实际上，用户在等待电子邮件的同时应该能够继续浏览其他页面。

在此示例中，我们通过添加队列解决了漫长的等待时间

 [checkout service] ---> [Queue] ---> [email service]

我们通过使微服务更具事件性来改善了用户体验。当用户单击“签出”按钮时，将立即返回响应，允许用户在将“电子邮件事件”发送到队列时继续浏览。

Answer 3

在这种情况下，维基百科解决了这个问题。

  

从形式上讲，生产，发布，传播，   检测到或消耗的是一条（通常是异步的）消息，称为   事件通知，而不是事件本身，即状态   触发消息发出的更改。活动不进行，他们   刚发生。但是，事件一词通常是指代   表示通知消息本身，这可能导致   混乱。这是由于事件驱动架构经常被   设计在消息驱动的架构之上   模式要求输入之一为纯文本，即消息，以   区分应该如何处理每种沟通。

https://en.wikipedia.org/wiki/Event-driven_architecture

老实说，在设计和编写代码时，我会一视同仁。但是我想从技术上讲，按照上面引用的段落会有区别。

Answer 4

从技术上讲，在这种情况下，我们不能使用单词“ Same”。下面将给出这些工件之间的明确关系：

事件驱动的微服务依赖消息队列（用于存储/转发消息）发送/接收事件，并封装在消息中。

Answer 5

事件驱动体系结构通常利用消息传递技术，以便将过去发生的信息从一个地方传输到另一个地方或其他许多地方。

消息队列还可以用于非事件驱动的体系结构，例如，执行异步请求/响应通信。

此外，当使用事件驱动的方法时，所传输的信息通常是不同的，这仅表明发生了什么（业务）事件，而信息通常少于 normal 消息所提供的信息。

例如，您可以发送消息以在网上商店系统中创建新订单，并且该消息可能包含接收者处理该订单所需的所有信息。同样重要的是，有专门的邮件接收者。

在事件驱动的方法中，某些组件宁愿发送一些请求的订单结帐事件（或类似的事件），而无需知道其他什么组件或其他什么组件（认为是发布/订阅机制） *针对该事件并执行相应的操作。在这种架构中，在实际结帐之前发送其他事件也很有意义，例如已创建新购物车或添加到购物车中的项目< / em>事件。

因此，事件驱动的方法还暗示着微服务之间的某种编排，其中更复杂的业务运营可以包括由不同组件发布和处理的许多事件，而没有一个中央组件来协调谁以什么顺序获取什么信息。 / p>

当然，根据我的经验，根据用例，将事件驱动的编排和非事件驱动的编排结合在微服务体系结构中是非常有意义的。