对异步微服务客户端的确认 [英] Acknowledgement to clients on asynchronous microservice
问题描述
我到处都读到，微服务中的服务到服务调用应该是异步的.当请求必须通过 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.
- 公共 API - 将电子邮件功能公开
- 验证 API - 验证电子邮件和其他字段的真实性
- 模板获取 API - 从数据库/CMS 中获取电子邮件模板并准备要发送的最终内容
- 电子邮件发送 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)?
推荐答案
简单的方法是创建一个令牌，客户端可以在以后使用它来检查请求的状态.您需要将 GetStatus 方法添加到公共 API 以在请求时返回状态.
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，将此令牌返回给调用客户端.这将是他们对收到请求的确认.保留 令牌 并将其与请求的当前状态一起记录，该状态最初将是 Received.使用请求调用验证 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.
当验证 API 完成其工作时，它将更新请求的状态.如果存在验证问题，它将使用适当的错误消息更新状态，否则将状态更新为已验证，然后调用模板 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.
使用模板 API 和发送 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.
这篇关于对异步微服务客户端的确认的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
