构建事件驱动微服务, 2nd Edition

第 17 章 集成事件驱动和请求响应微服务 整合事件驱动型和请求-响应型微服务

本作品已使用人工智能进行翻译。欢迎您提供反馈和意见：[e-mail]

事件驱动型微服务模式虽然功能强大，但并不能满足企业的所有业务需求。请求-响应通信在事件驱动型微服务中很常见，你经常会在以下场景中遇到它们：

• 从外部来源收集指标，如用户手机上的应用程序或物联网（IoT）设备

• 与其他请求-响应服务集成，尤其是与组织外部的第三方服务集成

• 向网络和移动设备用户实时提供内容

• 根据位置、时间和天气等实时信息提供动态请求

事件驱动模式在这一领域仍然发挥着重要作用，将它们与请求-响应解决方案集成将有助于您充分利用两者的最佳特性。

注意

在本章中，术语 "请求-响应服务"是指通过调用彼此的 API 直接进行通信的服务。通过 HTTP 通信的两个服务就是请求-响应通信的典型例子。通信可以是同步的（调用服务等待），也可以是异步的（调用服务在等待回调时执行其他工作）。

本章涵盖三个主要主题，包括

• 将请求转化为事件

• 将事件驱动型微服务与第三方 API 相集成

• 构建微前端

将请求转化为事件

许多系统和服务在很大程度上依赖于通过 RPC 或 HTTP 通信的请求-响应架构。有时，您会发现自己需要将这些请求中发送的数据打包成事件，然后写入各自的事件流中。

要做到这一点，有两种常见的方法：一是使用专用端点，二是使用 REST 代理。让我们依次检查每种方法。

将请求转化为事件的一种方法是使用专用端点。客户端向后端服务器发送请求，报告其发现，而后端服务器负责将其写入事件流。专用端点可为客户端提供极高的吞吐量和负载隔离，非常适合数据量巨大的情况（例如每秒数千个事件）。

考虑一下像 Netflix 这样安装在智能电视或手机上的流媒体服务，该应用会产生一些事件，其中包含观众已经开始观看哪部电影、观看到什么程度、是否已经停止观看等信息。例 17-1展示了一个点击事件的 Protobuf 版本，该事件通常用于分析目的。

例 17-1. MediaClick 事件的 Proto3 示例

message MediaClick {
  // Account Id
  string id = 1;

  // When the click happened
  Timestamp time = 2;

  // The media Id that the user clicked on
  int32 mediaId = 3;

  enum Media {
    Movie = 0;
    Show = 1;
    MovieTrailer = 2;
    ShowTrailer = 3;
  }

  // The type of media
  Media mediaType = 4;
}

如图 17-1 所示，客户端将数据编码为 Protobuf 格式，并将其序列化，然后发送到后端服务器。

图 17-1. 在客户端序列化MediaClick 数据

客户端完成了生成事件、填充 Protobuf 模式和序列化数据以发送到后端的所有工作。在这种情况下，这是一个合理的要求，因为客户端已经相对较重，可以处理额外的处理要求。

但是，如果您想从限制较多的环境（如嵌入浏览器或微型微控制器）中发送事件，该怎么办呢？由于资源限制，通常无法打包生成 ...