对异步微服务的客户的确认

Question

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

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

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

问题是，如果成功，我们必须确认发起请求的客户端有一些id，否则必须返回错误代码。如果我们必须调整为服务调用提供异步服务的最佳实践，我们如何通过电子邮件发送API（最终API）来确认客户端？

Answer 1

简单的方法是创建一个令牌，客户端可以使用它来稍后检查请求的状态。您需要向公共API添加GetStatus方法，以便在请求时返回状态。

收到初始请求时创建GUID，将此令牌返回给主叫客户端。这将是他们确认已收到请求。保留令牌并使用请求的当前状态进行记录，该状态最初将为已接收状态。使用请求调用Validation API并包含令牌。

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

使用Template API和Sending API重复上述步骤。当发送API完成其工作时 - 它应该只是将请求的状态更新为完成。

客户端可以随时通过提供初始请求返回的令牌来调用API上的GetStatus方法。如果已经提供了不存在的GUID，该方法应该只返回请求的状态或Not Found状态。

这样做的好处是你不必进入回调和其他疯狂，而主叫客户只需要担心两件事：提出请求并检查其状态。客户可以对其想要的状态感到担忧或不关心。它还允许您在链中添加更多服务，而无需重写外部接口。

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