The asynchronous implementation of Dubbo 2.7

[SparksDing]

Pre-check

• I am sure that all the content I provide is in English.

Apache Dubbo Component

Java SDK (apache/dubbo)

Details

dubbo 2.7的异步化实现：

用户发起远程调用时，客户端通过Netty发送消息给服务端。服务端Netty收到请求后将任务提交到线程池。当服务端线程池里的任务执行完成时，服务端通过Netty发送Response消息给客户端，客户端将处理Response的任务提交到线程池。当客户端线程池里的任务执行完成时，触发CompletableFuture完成的动作，此时客户端可以拿到同步结果。

• 如果服务端暴露的接口返回值类型为CompletableFuture，那么客户端通过Netty发送消息给服务端完成后，返回CompletableFuture对象给用户，用户负责同步等待结果。
• 如果服务端暴露的接口返回值类型非CompletableFuture，那么客户端通过Netty发送消息给服务端完成时，通过AsyncToSyncInvoker帮助用户完成同步等待，最终给用户返回同步后的结果。

（For English speaker）The asynchronous implementation of Dubbo 2.7:

When a user initiates a remote call, the client sends a message to the server through Netty. Upon receiving the request, the server's Netty submits the task to a thread pool. When the task in the server's thread pool is completed, the server sends a Response message to the client via Netty, and the client submits the task of processing the Response to a thread pool. When the task in the client's thread pool is completed, it triggers the completion action of CompletableFuture. At this point, the client can obtain the synchronous result.

• If the return type of the interface exposed by the server is CompletableFuture, the client sends a message to the server through Netty upon completion, and returns the CompletableFuture object to the user, who is responsible for synchronously waiting for the result.

• If the return type of the interface exposed by the server is not CompletableFuture, the client sends a message to the server through Netty upon completion, and uses the AsyncToSyncInvoker to help the user achieve synchronous waiting, ultimately returning the synchronous result to the user.

问题

dubbo 2.7以上有异步化特性，在客户端实现异步转同步，那么生产中用户在调用的时候还有必要再包一层CompletableFuture提交到线程池吗？这样可以避免流量直接打到下游，因为流量过高上游线程池会拒绝？
这样主要想探索下这两种方式的优劣？

（For English speaker）Question:

In Dubbo 2.7 and above, there are asynchronous features. When implementing asynchronous to synchronous conversion on the client side, is it necessary for users in production to wrap another layer of CompletableFuture and submit it to the thread pool when making a call? This can help avoid high traffic directly hitting the downstream, as the upstream thread pool may reject the traffic. The main purpose is to explore the advantages and disadvantages of these two approaches.

下面是一个demo接口对应上面两种方式的压测结果：

Below is a load testing result for a demo interface corresponding to the two approaches mentioned above:

Test code

public interface DemoService {
    String sayHello(String var1);

    default CompletableFuture<String> sayHiAsync(String name) {
        return CompletableFuture.completedFuture(this.sayHello(name));
    }
}

@RestController
public class DemoController {

    @Reference
    DemoService demoService;

    @Resource(name = "common-thread-pool")
    ThreadPoolExecutor commonThreadPool;


    @PostMapping("/demo")
    public String demoService() throws ExecutionException, InterruptedException, TimeoutException {
        return CompletableFuture
                .supplyAsync(() -> demoService.sayHello("Hello"),
                        commonThreadPool).get(10, TimeUnit.SECONDS);
    }


    @PostMapping("/demoAsync")
    public String demoServiceAsync() throws ExecutionException, InterruptedException {
        CompletableFuture<String> res = demoService.sayHiAsync("Hello");

        return res.get();
    }
}

会有什么坑不？敬请大佬解答
Looking forward to your answer!

Code of Conduct

• I agree to follow this project's Code of Conduct

[AlbumenJ]

This is depends on your coding style. Dubbo make it all possible. In most scenarios, performance is not important enough or users cannot feel the difference of performance. So, choose the one you like.