本文属于机器翻译版本。若本译文内容与英语原文存在差异，则一律以英文原文为准。
# 异步通信
相反，在异步通信中，客户端向服务发出请求，但无法立即收到响应。这种情况下，客户端通常只会收到请求已被接受的确认信息。
同步通信的优势包括：
+ **事件驱动型架构支持** – 天然契合事件溯源与命令查询责任分割（CQRS）模式。
+ **资源管理更出色** – 服务能够根据其容量处理请求。
+ **故障隔离经改进** – 服务解耦，可防止级联故障。
+ **峰值负载处理** – 通过消息队列更好地处理流量峰值。
缺点包括复杂性。例如：
+ 如果客户端需要获取异步操作的结果，则需要付出更多努力，才能实施获取或接收该结果的机制。
+ 对异步操作进行故障排查可能更加困难，因为故障排查需要检查多个系统的日志。
+ 测试异步操作可能更加困难，因为需要协调多项系统和服务，才能执行测试。
异步通信的方法包括即发即弃、声明检查、回调和双向通信。
## 即发即弃
在即发即弃模式中，客户端向服务器发出请求并同步收到一条确认消息，表明服务器已收到消息并将对其进行处理。然而，实际处理尚未进行，客户端无法知晓处理将在何时以何种方式完成。下图阐明了此模式。
在此情况下，服务**不应**在对象被持久化保留之前发送确认。这种持久化可以作为数据库写入操作实施，也可以通过将项目放入队列来实施。
其他注意事项：
+ 实施幂等性以处理重复消息。也就是说，每则消息只能被处理一次。
+ 考虑针对处理失败的情况使用[死信队列](https://aws.amazon.com/what-is/dead-letter-queue/)。
+ 监控消息处理成功率。
## 声明检查
如果客户需要服务调用的结果，则可以构建服务，使其在收到请求时发出*声明检查*。下图阐明了此模式。声明检查充当服务在其确认中返回的标识符。客户端可以在后续阶段使用此标识符查询请求状态，并在请求完成时检索结果。
客户端必须实施一种机制来轮询结果。这可以是自动的（例如，可以每 *n* 分钟执行一次检查），也可以是手动的，即为了响应其他事件或用户操作而执行检查。实施声明检查模式的服务应明确声明检查的有效时间。
最佳实践：
+ 为轮询实施指数回退。
+ 为声明检查设置适当的生存时间（TTL）。
+ 提供状态端点用于跟踪进度。
## 回调
在回调模式中，客户端向服务发起请求，并提供一个位置供服务在处理完成后联系。客户端不会等待结果，处理仍将继续。服务负责在处理完成后联系该位置并提供结果。常见的响应位置类型是 REST APIs 或队列。下图展示了此回调模式。
实施：
+ 为失败的回调实施重试机制。
+ 像保护其他服务一样保护回调位置。
+ 处理回调超时。
## 双向通信
要实施双向通信，必须在客户端与服务之间建立有状态的连接，这样客户端与服务都可以发送和处理消息。此过程如下图所示。尽管通信是异步的，但服务必须能够支持每个客户端的开放连接。
实施的注意事项：
+ 消息排序
+ 序列号
+ 分区策略
+ 消息排序
+ 状态管理
+ 事件溯源模式
+ 状态协调
+ 一致性模型
+ 错误处理
+ [死信队列](https://aws.amazon.com/what-is/dead-letter-queue/)
+ 重试策略
+ [断路器](https://docs.aws.amazon.com/prescriptive-guidance/latest/cloud-design-patterns/circuit-breaker.html)
+ 回退策略
+ 监控和可观测性
+ 相关性 IDs
+ 消息跟踪
+ 性能指标
+ 系统运行状况指标