微服务:异步 API 反馈
我不太清楚如何从异步 api 获取反馈响应。
我的意思是,异步服务会响应任何类型的响应,例如:“好的,已收到”。
我知道有多种方法可以轮询任何操作状态(长轮询、服务器发送事件、websockets...)。
对我来说,这种获取反馈的方式同时也是一种超载服务的方式。
我的意思是,我正在构建一个异步服务以优化操作,但同时,我需要处理大量“检查状态”请求。
另一方面,当我的老板向我询问“异步操作失败怎么办”时,我可以对他说哪些句子?那么客户反馈如何呢?
I don't quite to figure out how to get feedback response from an async api.
I mean, an async service responds with any type of response like: "ok, received."
I know that there are several ways to poll about any operation status (long poll, server-sent events, websockets...).
For me, this way to get feedback is at the same time a way to overloading service.
I mean, I'm building an async service in order to optimize operations, but at the same time, I need to handle a lot of "check state" requests.
By other hand, which sentences could I do to my boss when he's requesting me about "what about is async operation fails"? How client is feedback then?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(2)
您可以使用回调机制(即发即忘)来处理此问题。
You can handle this using Callback mechanism (fire and forget ) .
这是一个非常普遍的问题理论只是一个好的答案的基础!
异步
调用适用于大多数情况下
不需要实时反馈或关注的事件或调用。因此,它们的处理应该(或可以)在队列中按顺序或按时间进行。客户端反馈点
一旦收到请求并发送进行处理,我们当然可以使用接受消息(
带或不带响应正文)进行恢复。在您的情况下,您肯定需要另一个端点/服务/等,具体取决于设计来检查状态,因为这是我们在 API 世界(REST 或 SOAP)中请求
资源
的唯一方式!如果异步操作失败怎么办
你肯定必须选择一个更好的异步支持者(例如,你可以选择哪个更一致,
fault taulerant
,Kafka(i会更喜欢这个),RabbitMQ
,其他一些MQ等)因为大多数这些系统都经过了良好的测试,具有更高的吞吐量,您可以阅读并比较它们的架构!所以最终这取决于你如何设计和构建。选择您的系统最需要的!
This is a very common concern & theory only would be a foundation to a good answer!
Asynchronous
calls are meant to be for events or calls whichmostly doesn't
require a realtime feedback or attention. Hence, their processing should (or can be done) in queues, sequentially or with time.Client feedback point
We can certainly revert with an accept message (
with or without reponse body)
once the request is received and sent for processing. In your case, you'd definitely require another endpoint/service/etc depending on design to check for status since that is the only way you would we requesting aresource
in API world (REST or SOAP)!What if async operation fails
You'll definitely have to choose a better async supporter ( For e.g. You may choose which is more consistent and
fault taulerant
,Kafka (i'll prefer this), RabbitMQ
, some other MQ etc) Since most of these systems are tested well with higher throughputs and you may read and compare their architectures!So ultimately it depends on how you design & choose what is best needed for your systems!