事件驱动架构和微服务架构的区别与联系

[[436447]]

1、事件驱动和微服务的区别

微服务架构旨在将单个大型“单体”设计/系统分解为多个独立的组件/流程，从而使代码库更加细化和易于管理。甲微服务基本上是小的，松散耦合的分布式服务。它是更广泛的微服务架构的一部分，由一组松散耦合的微服务组成，这些微服务一起运行以解决一个共同的目标。

事件驱动架构(EDA)是一种解决耦合的方法，否则会在较大系统中的组件进行通信时发生(这就是微服务中发生的情况)。当微服务同步通信时，通过API调用，它们会变得相互依赖，导致系统难以维护。EDA通过使用事件代理作为中介，允许组件通过引发和响应事件进行通信来解决这个问题。

2、单体巨石程序与服务独立性

大多数给定应用程序都是作为单个代码块编写的。每个函数、每个布尔选项、每个重复或迭代过程以及应用程序调用的每个服务都包含在该代码中。每个服务、进程、函数、子例程和库之间的通信是代码处理中固有的。

在这样一个完整的单体应用程序中，如果代码中的任何地方出现任何问题，整个应用程序都会完全崩溃。程序错误……严重错误……致命错误……它们都不是令人愉快的，而且通常不容易解决。

如果任何服务中出现的缺陷会导致整个应用程序瘫痪，那么合乎逻辑的解决方案是通过单独和独立运行来隔离每个服务。任何服务中的故障只会导致该进程停止运行，而不是整个应用程序停止运行，整个应用程序将继续运行，直到重新实例化失败的服务并变为可用为止。

为了提高每个服务的隔离度，微服务在容器内的自己的进程中运行，该容器包括服务的代码、其配置、所有依赖项、库以及运行代码所需的其他资源。容器化服务可以单独测试并作为容器化镜像实例部署到主机操作系统。

将应用程序创建为独立容器化微服务的集合有几个显著的优势：

由于它们各自独立执行，因此每个微服务可以包含不同的代码——在不同的平台上创建不同的依赖项。

• 微服务无需修改即可部署在不同的环境中。
• 容器直接在操作系统上运行，比VM映像占用的空间小得多。
• 通过为各种任务创建新容器，可以轻松实现横向扩展。
• 新映像的实例化(创建容器的过程)与实例化服务或Web应用程序没有什么不同。
• 容器提供独立性、隔离性、可移植性、可扩展性和控制性。

3、新的关联关系

微服务、容器、DevOps、持续改进、持续开发和部署(CI/CD)、事件驱动架构(EDA)等都围绕实现更高的敏捷性而结合在一起。

容器中的每个微服务都独立于所有其他微服务，从而通过启用分段部署来提高应用程序的弹性。如果需要对任何特定微服务进行更改，则不需要重建甚至停止整个应用程序。这也允许简化维护。

开发者还可以享受分工协作，组成小团队来构建和维护特定的服务。他们甚至可以用任何语言构建这些服务，因为每个服务都与所有其他服务分开运行。

将所有这些结合在一起，容器化微服务符合敏捷性的核心概念。它们是非常松散耦合的，因此更改一个微服务不需要更改另一个。而且由于微服务易于复制，因此它们的可扩展性也很高。如果需要更改，只需修改需要更改的服务。容器实际上是应用服务粒度的定义。

4、事件驱动的微服务架构

 

 

传感事件驱动示意

一个简单的事件通常需要复杂的响应。所上图所求，房屋传感器检测到昂贵的戒指被盗的事件。诸如此类的事件处理器通过发出警报同时通知戒指的所有者和警察以便他们能够做出反应来提供必要的指导以提供威慑。这些通知中没有一个需要知道其他通知，也不需要在执行之前等待它们发生。此序列提供的即时操作展示了松散耦合的价值。

5、云原生应用

互连的容器化微服务可创建云原生应用程序，这些应用程序可轻松传输到网络上需要的任何位置。为了可靠和一致地运行，他们必须拥有一个能够自动执行所有潜在响应的通信平台(如：Istio)。

经典的单体应用很难实现这一点，因为它们既不能很好地扩展，也不能提供所需的弹性。然而，云原生应用程序利用EDA使它们能够促进定义DevOps目标的敏捷性——在高度促进持续开发和部署的动态环境中实现持续改进。 

总之，微服务和EDA是互补的，但也可以独立存在。微服务不必使用EDA构建。同样，EDA可以独立存在于不使用微服务的系统中，但随着云原生的推广应用，两者之间的关系越来越“亲密无间”。