在异步微服务上向客户端确认

Question

我到处都读到，服务到服务的调用在微服务中应该是异步的。当请求必须经过 2 个或多个异步服务时，我们如何进行客户端确认？

这是我的实时场景。我们正在我们的组织中开发电子邮件发送功能。我们计划按以下顺序为此提供 4 API 项服务。

1. Public API - 将电子邮件功能公开给 public
2. 验证API - 验证电子邮件和其他字段的真实性
3. 模板获取API - 从database/CMS获取电子邮件模板并准备要发送的最终内容
4. 邮件发送API - 将收到收件人和邮件内容

问题是，如果成功，我们必须使用某个 id 确认发起请求的客户端，否则必须 return 错误代码。如果我们必须采用将异步服务应用于服务调用的最佳实践，我们如何才能通过电子邮件发送 API(final API) 来确认客户端？

Answer 1

简单的方法是创建一个 token 客户端可以在以后检查请求的状态。您需要将 GetStatus 方法添加到 public API 到 return 请求时的状态。

在收到初始请求时创建一个 GUID，return 此 令牌 到调用客户端。这将是他们确认已收到请求。保留 token 并将其与请求的当前状态一起记录，该状态最初将被接收。使用请求调用验证 API 并包含 令牌 。

当验证 API 完成其工作时，它将更新请求的状态。如果存在验证问题，它将使用适当的错误消息更新状态，否则会将状态更新为已验证，然后调用模板 API，传递请求和 token。

使用模板 API 和发送 API 重复上述操作。当发送 API 完成其工作时——它应该简单地将请求的状态更新为完成。

客户端可以随时调用 API 上的 GetStatus 方法，只需提供由其初始请求提供的 令牌 return。如果提供了不存在的 GUID，该方法应该只是 return 请求的状态或未找到状态。

这样做的好处是您不必陷入回调和其他疯狂的事情，调用客户端只需担心两件事：发出请求并检查其状态。客户可以根据自己的意愿关心或不关心状态。它还允许您在链中添加更多服务，而无需重写外部接口。

细微差别涉及如何以及多长时间保持请求状态。这实际上取决于系统需求和可用资源。可以是数据库、缓存或某种组合。