在云用户中，对“混合云”和“多云”这两个术语评估的两极分化水平较为重大。从之前的状况来看，混合云的应用表明工作负载正在从公有数据中心转移到公共云。当初，它意味着本地应用程序与云中的服务之间的集成。
多云的起源状况相似——最后是工作负载依据价格和性能等状况从一个云迁徙到另一个云。然而，这些用例却难以被发现。当初，多云只是意味着用户正在应用多个云平台。
在大多数企业中，公司都在应用来自多个云的服务。只有有一种办法能够集成服务并在没有过多工具的状况下治理它们，工作负载在哪里运行就变得简直无关紧要。
高质量云服务的遍及使用户可能应用来自最佳提供商的服务来满足其特定需要。它可能是来自亚马逊的对象存储、来自谷歌的计算、来自 Salesforce 的 CRM 以及来自 Splunk 和 Datadog 的治理服务。涣散耦合的服务创立的应用程序是云服务的交融，通过网络组合，成为云原生应用程序。
该设计模式与 90 年代前期提倡的面向服务的架构 (SOA) 十分类似。只管它们变成事件驱动，而不仅仅是 API 驱动的。
当互联网的应用在 20 世纪 90 年代首次呈现快速增长时，大多数用户的带宽极低，人们在电子邮件和网络之外应用的服务数量也很少。当工夫来到 2022 年，当初咱们领有速度极快的互联网、有数的云服务、智能设施，以及对最新信息的一直谋求。
API 与事件驱动架构
云中有两种风行的交互模型。第一个是 REST API（或 RESTful API）。REST 局部代表具象状态转换，API 代表应用程序编程接口。RESTful API 是零碎互相交互的一种形式，就像对话一样。在 RESTful 架构中，有申请和响应并重复进行，始终继续到确定信息为止，这须要同步通信。
相比之下，事件驱动的架构就像从水龙中喝水——其中事件是异步流式传输的，用户基于公布 / 订阅模型（称为 Pub/Sub）生产主题。
事件驱动架构能够采纳多种形式，但最常见的两种是 Webhook 和流式传输。在事件驱动的架构中，数据是实时提供的，而不是作为对查问的响应（与 API 办法一样）。
例如，在 Webhook 的状况下，咱们要求事件的生产者通知咱们工作何时实现，而后咱们会在事件产生时收到告诉，这就是异步通信。
在流式传输的状况下，咱们会随着状态的变动接管事件。这些事件可能是对数据库的更改、将文件上传到存储 blob 或实现无服务器性能。
事件驱动架构的衰亡
为什么事件驱动很重要？因为这些事件用于触发和通信解耦的服务。事件只是零碎中状态的变动，它能够携带状态或标识符。这些事件可用于触发工作流。云之间的这些工作流突破了孤岛，提供数据同步或简单工作的实现。
云中的事件驱动架构
当初，云的构造曾经变成了 Kubernetes。它无处不在，并容许在容器中运行的应用程序的可移植性。用户通常在容器或无服务器性能中部署全时运行的微服务。这些函数可能应用事件互相通信。有许多事件流技术，一些能够逾越多个云，而另一些则特定于每个云。
Amazon Kinesis 提供了一种在 AWS 中治理事件流的办法。Eventarc 是 Google Cloud 的解决方案，用于将事件从 Google 服务发送到能够从 Pub/Sub 主题接管音讯的指标或服务。Microsoft Azure 的事件网格在 Azure 云中治理从源到目的地的事件路由。这些解决方案是繁多云事件流解决方案的示例。
如果想做多云应该怎么办？Apache Kafka 是一个开源的分布式事件流平台。现在，它宽泛用于流式传输本地事件或来自云基础设施。
从多云 / 混合云到集成
云用户须要在所有云中都统一的工具，只管治理无服务器性能的部署相当容易，然而提供云服务之间通信的统一形式并不容易。
通过与云服务的用户继续交换，咱们得出的论断是云架构师正在致力解决的问题是，不仅要在云服务之间进行通信，还要晓得如何路由事件流——有时甚至能够将这些事件从一种格局转换给另一个。
例如有大型银行心愿过滤从 Azure 到 Splunk 的事件，以升高存储老本。这些心愿通过 Apache Kafka 服务的事件流集成 Salesforce 及其现有 ERP 零碎的人示意，像甲骨文这样的云计算工具比三大云提供商少。他们须要将云指标流式传输到 Datadog。所有这些问题都是集成问题，源和指标位于云端和本地。
通过一系列的整合工作，当初，咱们认为 HashiCorp 的 Terraform 基础设施即代码之类的工具（用于部署云基础设施）须要为集成而存在（咱们称之为集成即代码），这就是为什么服务存在于哪里并不重要，因为它只须要易于集成。