使用 WebFlux 的 Reactive 编程如何处理依赖的外部 api 调用 [英] How does Reactive programming using WebFlux handles dependent external api calls

查看:89
本文介绍了使用 WebFlux 的 Reactive 编程如何处理依赖的外部 api 调用的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我是响应式编程的新手,我想知道的一件事是,假设我们有一个 api,它在内部调用 3 个其他 api.其中第一个 api 的结果被送入第二个,而第二个 api 的输出被送入第三个.它不会减少到正常的基于单线程的执行.如果是,那么我们为什么要在这种情况下使用反应式编程.

I am new to reactive programming and one thing I wanted to know is, suppose we have an api which calls 3 other api's internally. In which the result of first api is fed into the second, while the output of second api is fed into third. Does it not reduces to a normal single thread based execution. If yes then why should we use reactive programming in such a scenario.

推荐答案

在这种情况下,响应式编程不会改变物理或逻辑定律:您仍然需要上一步的结果来生成下一个步骤.因此,使用阻塞 API 或响应式 API 执行该逻辑可能会花费同样多的时间.

In this scenario, reactive programming won't change the law of physics or logic: you'll still need the result of the previous step to produce the next one. So it's likely that executing that logic with a blocking API or a reactive will take as much time.

但是在阻塞 I/O API 的情况下,处理这个确实会使用一个线程来完成整个操作,即使服务器正在等待远程 API 响应.对您的 API 的数百次调用意味着数百个线程及其相关资源,在等待远程资源时通常什么也不做.

But in the case of a blocking I/O API, processing this will indeed use a thread for the whole operation, even when the server is waiting for the remote API to respond. Hundreds of calls to your API will mean hundreds of threads and their associated resources, often sitting down nothing while waiting for remote resources.

如果您改用响应式 API,您的服务器将使用更少的线程,并且在等待这些远程响应时不会继续使用资源.

If you're using a reactive API instead, your server will use fewer threads and will not keep using resources while waiting for those remote responses.

总而言之,虽然不会提高此用例的速度,但会提高服务的可扩展性并消耗更少的资源(内存和 CPU).

In summary, while not improving the speed of this use case, it will improve the scalability of your service and consume less resources (memory and CPU).

这篇关于使用 WebFlux 的 Reactive 编程如何处理依赖的外部 api 调用的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆