选择事件驱动的体系结构和消息传递解决方案
近年来，大多数复杂的系统都作为一组单独的服务实现，而非单一的单体应用程序。 此方法有助于让系统具备可管理性、可伸缩性和多功能性。 借助云原生微服务，该方法达到了可在云主机上良好运行的高级阶段。 但是，微服务必须相互通信，才能生成对用户请求的响应。 通过使用消息队列或事件总线，可以使这些通信更加可靠。
在全球自行车零售商的场景中，面向客户的网站是通过微服务构建的云原生应用程序。 它使用 Google Pub/Sub、Google Eventarc 和 Google Cloud Functions 来保证服务的可靠性。 你正在评估是否将系统迁移到 Azure，并且想要了解等效的消息处理服务。
在本单元中，你将了解 Azure 和 Google Cloud 中的消息队列系统和事件驱动的体系结构。
事件驱动的体系结构和消息传递体系结构分别是什么？
在分布式系统中，组件通常是分离的服务，它们必须进行协作才能生成对用户请求的响应。
例如，开发人员可能会创建一个 Web 前端服务，向客户提供自行车产品目录。 当用户将自行车添加到购物车时，前端可能会向购物车服务发送一条消息，内附要添加的产品 ID 和编号。 用户完成购买后，购物车服务可能会提醒库存管理服务减去库存数量并请求安排发货。 完成后的系统需要更多服务，且这些服务之间需要进行更多通信。
可以选择直接调用其他服务，但在需求高时或服务面临暂时中断时，这种方法可能会变得难以管理。 消息传递服务和事件中心可顺利应对这类困难。 消息传递服务和事件中心可维护消息队列或事件流。
这两种方法相似，但着重点不同。 事件驱动的体系结构：
- 推动事件的生成、检测、使用和反应。 事件是组件中发生的状态变化或重要情况。
- 包括发布事件及其特征的事件生成者。
- 让事件使用者侦听和响应事件。
- 使用事件存储来管理事件流。
- 支持实时数据处理和即时响应。
消息传递体系结构：
- 侧重于组件与消息之间的通信。 消息可以是服务之间传输的数据的任何部分。
- 包括发送消息及其内容的消息生成者。
- 具有接收和处理消息的消息使用者。
- 使用消息代理维护消息队列，供使用者提取消息。
- 支持在分离组件（如微服务）之间进行可靠通信。
比较事件驱动的体系结构服务
Google Cloud 事件驱动的服务包括 Pub/Sub，它用于事件引入和交付。 Eventarc 是一项服务，用于将事件从各种源路由到 Cloud Run、Cloud Function 或 Workflows。 让我们将这些服务与 Azure 等效服务进行比较：
| 用途 | Azure | Google Cloud | 注释 |
|---|---|---|---|
| 事件路由 | Azure 事件网格 | Eventarc | 事件网格是一项完全托管的事件路由服务，它使用发布和订阅模型进行近实时处理。 借助它，可通过将事件从任何源路由到任何目标来生成基于事件的体系结构。 事件网格提供与 Azure 服务更深度集成的体验。 |
| 事件响应 | Azure Functions | Cloud Functions | Azure Functions 是一项无服务器计算服务，可用于按需运行代码，其运行由来自各种源的事件触发。 借助 Google Cloud Functions，也可运行无服务器按需代码。 |
| 事件处理 | Azure 事件中心 | 适用于 Apache Kafka 的 Pub/Sub 或托管服务 | 事件中心是一个大数据流式处理平台，也是一项事件引入服务，每秒可处理数百万个事件。 事件中心提供与 Apache Kafka 具有兼容性和奇偶校验的 API。 |
比较消息服务
可以使用 Google Cloud Pub/Sub 服务来托管事件驱动的体系结构和消息传递体系结构。 Azure 不采用此方法。 若要在 Azure 中生成消息传递，请使用以下服务而不是事件网格：
| 用途 | Azure 服务 | 注释 |
|---|---|---|
| 消息队列 | Azure 队列存储 | Azure 队列存储是一项简单的队列服务，用于应用程序组件之间的大容量消息传递。 |
| 消息代理 | Azure 服务总线 | Azure 服务总线是一种包含消息队列和发布/订阅主题的企业消息代理。 |