异步通信 - AWS 规范性指导

本文属于机器翻译版本。若本译文内容与英语原文存在差异,则一律以英文原文为准。

异步通信

相反,在异步通信中,客户端向服务发出请求,但无法立即收到响应。这种情况下,客户端通常只会收到请求已被接受的确认信息。

同步通信的优势包括:

  • 事件驱动型架构支持 – 天然契合事件溯源与命令查询责任分割(CQRS)模式。

  • 资源管理更出色 – 服务能够根据其容量处理请求。

  • 故障隔离经改进 – 服务解耦,可防止级联故障。

  • 峰值负载处理 – 通过消息队列更好地处理流量峰值。

缺点包括复杂性。例如:

  • 如果客户端需要获取异步操作的结果,则需要付出更多努力,才能实施获取或接收该结果的机制。

  • 对异步操作进行故障排查可能更加困难,因为故障排查需要检查多个系统的日志。

  • 测试异步操作可能更加困难,因为需要协调多项系统和服务,才能执行测试。

异步通信的方法包括即发即弃、声明检查、回调和双向通信。

即发即弃

在即发即弃模式中,客户端向服务器发出请求并同步收到一条确认消息,表明服务器已收到消息并将对其进行处理。然而,实际处理尚未进行,客户端无法知晓处理将在何时以何种方式完成。下图阐明了此模式。

异步通信中的即发即弃模式。

在此情况下,服务不应在对象被持久化保留之前发送确认。这种持久化可以作为数据库写入操作实施,也可以通过将项目放入队列来实施。

其他注意事项:

  • 实施幂等性以处理重复消息。也就是说,每则消息只能被处理一次。

  • 考虑针对处理失败的情况使用死信队列

  • 监控消息处理成功率。

声明检查

如果客户需要服务调用的结果,则可以构建服务,使其在收到请求时发出声明检查。下图阐明了此模式。声明检查充当服务在其确认中返回的标识符。客户端可以在后续阶段使用此标识符查询请求状态,并在请求完成时检索结果。

异步通信中的声明检查模式。

客户端必须实施一种机制来轮询结果。这可以是自动的(例如,可以每 n 分钟执行一次检查),也可以是手动的,即为了响应其他事件或用户操作而执行检查。实施声明检查模式的服务应明确声明检查的有效时间。

最佳实践:

  • 为轮询实施指数回退。

  • 为声明检查设置适当的生存时间(TTL)。

  • 提供状态端点用于跟踪进度。

回调

在回调模式中,客户端向服务发起请求,并提供一个位置供服务在处理完成后联系。客户端不会等待结果,处理仍将继续。服务负责在处理完成后联系该位置并提供结果。常见的响应位置类型是 REST APIs 或队列。下图展示了此回调模式。

异步通信中的回调模式。

实施:

  • 为失败的回调实施重试机制。

  • 像保护其他服务一样保护回调位置。

  • 处理回调超时。

双向通信

要实施双向通信,必须在客户端与服务之间建立有状态的连接,这样客户端与服务都可以发送和处理消息。此过程如下图所示。尽管通信是异步的,但服务必须能够支持每个客户端的开放连接。

异步通信中的双向通信模式。

实施的注意事项:

  • 消息排序

    • 序列号

    • 分区策略

    • 消息排序

  • 状态管理

    • 事件溯源模式

    • 状态协调

    • 一致性模型

  • 错误处理

  • 监控和可观测性

    • 相关性 IDs

    • 消息跟踪

    • 性能指标

    • 系统运行状况指标