本文介绍了在异步微服务上向客户端的确认的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

I read everywhere that service to service calls should be asynchronous in microservices. When the request has to pass through 2 or more async services, how can we do the client acknowledgement?

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

Here is my real time scenario. We are developing an email sending functionality in our organisation. We are planning to have 4 API services for this in the following order.

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

问题是,如果成功,我们必须以某个id确认发起请求的客户端,否则必须返回错误代码.如果我们必须使使异步服务适应服务调用的最佳实践,那么如何从电子邮件发送API(最终API)中确认客户端?

The problem is, we have to acknowledge the client who initiated the request with some id if successful, otherwise have to return the error code. If we have to adapt the best practice of making asynchronous service to service call, how we can acknowledge the client from Email sending API(final API)?

推荐答案

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

The simple approach is to create a token that the client can use to check the status of the request at a later time. You will need to add a GetStatus method to the public API to return the status when requested.

在收到初始请求时创建一个GUID,将此令牌返回给主叫客户端.这将是他们对收到请求的确认.坚持使用令牌并将其记录为请求的当前状态,该状态将首先被接收.随请求一起调用Validation API,并包含令牌.

Create a GUID when the initial request is received, return this token to the calling client. This will be their acknowledgement that the request was received. Persist the token and record it with the request's current status, which will initially be Received. Call the Validation API with the request and include the token.

Validation API完成其工作后,它将更新请求的状态.如果存在验证问题,它将使用适当的错误消息更新状态,否则将状态更新为已验证",然后调用Template API,同时传递请求和令牌.

When the Validation API has completed its work, it will update the status of the request. If there is a validation issue, it will update the status with an appropriate error message, otherwise it will update the status to Validated and then call the Template API, passing along the request and the token.

使用Template API和Sending API重复以上操作.发送API完成工作后,只需将请求的状态更新为完成"即可.

Repeat the above with the Template API and Sending API. When the Sending API has completed its work -- it should simply update the request's status to Complete.

客户只需提供最初请求返回的令牌,即可随时在API上调用GetStatus方法.如果提供了不存在的GUID,则该方法应该仅返回请求的状态或未找到"状态.

The client can call the GetStatus method on the API at any time simply by supplying the token returned by their initial request. The method should simply return the request's status or a Not Found status if a non-existent GUID has been supplied.

这样做的好处是您不必陷入回调和其他疯狂的情况,并且调用客户端仅需要担心两件事:发出请求和检查其状态.客户可能对自己想要的状态感到关注或不关心.它还使您可以在链中添加更多服务,而不必重写外部接口.

The advantages of this is that you don't have to get into callbacks and other craziness and the calling client only needs to worry about 2 things: making a request and checking its status. The client can be as concerned or unconcerned about the status as it wants to be. It also lets you add further services in the chain without having to rewrite the external interface.

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

The nuances involve how and how long to persist the request statuses. Which really depend on system demand and available resources. Could be a database, a cache or some combination.

这篇关于在异步微服务上向客户端的确认的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持!

09-22 08:18