我们生活在一个软件开发的新时代，一个云原生应用的时代。为云交付而构建的应用程序必须具有高可传输性、非常松散的耦合、高弹性和极快的响应能力。这要求很多。将今天的开发环境与过去的开发环境进行比较，有助于解释所有这一切是如何成为可能的。1.事件驱动和微服务的区别微服务架构旨在将单个大型“单体”设计/系统分解为多个独立的组件/流程，从而使代码库更细化，更易于管理。微服务基本上是小型的、松散耦合的分布式服务。它是更广泛的微服务架构的一部分，由一组松散耦合的微服务组成，这些微服务一起运行以解决一个共同的目标。事件驱动架构(EDA)是一种解决耦合的方法，否则耦合会在较大系统中的组件通信时发生（微服务中就是这样）。当微服务通过API调用同步通信时，它们会变得相互依赖，使系统难以维护。EDA通过使用事件代理作为中介解决了这个问题，允许组件通过引发和响应事件进行通信。2.单体程序和服务独立性大多数给定的应用程序都是作为单个代码块编写的。每个函数、每个布尔选项、每个重复或迭代过程以及应用程序调用的每个服务都包含在该代码中。每个服务、进程、函数、子例程和库之间的通信是代码处理中固有的。在这样一个完整的单体应用程序中，如果代码中的任何地方出错，整个应用程序将彻底崩溃。程序错误……致命错误……致命错误……没有一个是令人愉快的，而且通常不容易修复。如果任何服务中的缺陷导致整个应用程序崩溃，逻辑解决方案是通过单独和独立运行来隔离每个服务。任何服务中的故障只会导致该进程停止运行，而不会导致整个应用程序停止运行，整个应用程序将继续运行，直到失败的服务重新实例化并变得可用。为了提高每个服务的隔离性，微服务在容器内的自己的进程中运行，其中包括服务的代码、配置、所有依赖项、库和运行代码所需的其他资源。容器化服务可以单独测试并作为容器化图像的实例部署到主机操作系统。将应用程序创建为独立容器化微服务的集合有几个显着优势：由于它们各自独立执行，因此每个微服务可以包含不同的代码——在不同平台上创建不同的依赖关系。微服务无需修改即可部署在不同的环境中。容器直接在操作系统上运行，占用的空间比VM映像少得多。通过为各种任务创建新容器可以轻松实现横向扩展。新图像的实例化（创建容器的过程）与实例化服务或Web应用程序没有什么不同。容器提供独立性、隔离性、可移植性、可伸缩性和控制。3.新的关联微服务、容器、DevOps、持续改进、持续开发和部署（CI/CD）、事件驱动架构（EDA）等都围绕着实现更高的敏捷性进行组合。容器中的每个微服务都独立于所有其他微服务，通过启用分段部署来提高应用程序的弹性。如果需要对任何特定的微服务进行更改，则无需重建甚至停止整个应用程序。这也允许简化维护。开发者也可以分工协作，组成小团队来构建和维护特定的服务。他们甚至可以用任何语言构建这些服务，因为每个服务都独立于所有其他服务运行。将所有这些放在一起，容器化微服务符合敏捷性的核心概念。它们的耦合非常松散，因此更改一个微服务不需要更改另一个。由于微服务易于复制，因此它们也具有高度可扩展性。如果需要更改，只需要修改需要更改的服务。容器其实就是应用服务粒度的定义。4.事件驱动微服务架构感知事件驱动指示一个简单的事件通常需要复杂的响应。如上图所示，房屋传感器检测到昂贵戒指被盗。像这样的事件处理者提供了必要的指导，通过发出警报来提供威慑，同时通知戒指的主人和警察，以便他们做出回应。这些通知都不需要知道其他通知，也不需要等待它们发生再执行。此序列提供的即时操作证明了松散耦合的价值。5.云原生应用程序互连的容器化微服务创建了云原生应用程序，这些应用程序可以轻松传输到网络上需要的任何地方。为了可靠和一致地运行，他们必须有一个可以自动化所有潜在响应的通信平台（例如：Istio）。这很难通过经典的整体式应用程序实现，因为它们既不能很好地扩展也不能提供所需的弹性。然而，云原生应用程序利用EDA使它们能够促进定义DevOps目标的敏捷性——在高度促进持续开发和部署的动态环境中实现持续改进。综上所述，微服务和EDA是互补的，但也可以独立存在。微服务不必使用EDA构建。同样，EDA在不使用微服务的系统中也可以独立存在，但随着云原生的普及和应用，两者的关系越来越“亲密”。
