httpclient&WebClient--4次迭代，让我的 Client 优化 100倍！

4次迭代，让我的 Client 优化 100倍！

https://www.cnblogs.com/crazymakercircle/p/17136216.html

 

在大家的生产项目中，经常需要通过Client组件（HttpClient/OkHttp/JDK Connection)调用第三方接口。

在一个高并发的中台生产项目中。有一个比较特殊的请求，一次请求，包含 10个 Web 外部服务调用，每个服务调用的预定时间200ms。

为了并行，使用了一个很大的线程池，最大100个线程。

 

第1轮迭代，是通过CompletableFuture进行代码的优化。

这个环节，对性能没有本质的提升，但是CompletableFuture 这种 函数式编程的风格，为后面的迭代打下来一些技术基础。

使用CompletableFuture 并发10个远程api 接口，有两个方法

• 方法1：CompletableFuture 和 CountDownLatch
• 方法2：CompletableFuture.allOf 算子

第2次迭代：响应式 Flux 流进行异步回调改造。

什么分析一下，发现一个秘密：执行一次WEB调用操作所需的实际工作非常少。实际的工作就2点：

• 生成并触发一个请求
• 等等一段时间，会收到一个响应。

而且，其中有一个节非常低性能，这个环节是：在请求和响应之间，线程根本没有做任何工作，而且在等待，等待200ms。

线程资源是宝贵的。咱们一个java应用不能开始太多的线程，一般最多就400个左右。如果开启太多，很多的cpu资源就用去做线程上下文切换了。

如何要让这些线程不等待，去干别的工作，该当如何？这是使用异步框架。使用异步框架发出 Web 请求的核心优势之一，在请求进行中时您不会占用任何线程。

 

第3次迭代：响应式 parallel Flux 流进行并行异步回调改造

 

第4次迭代：响应式 WebClient 组件去掉底层的io线程阻塞

httpclient底层的io线程是阻塞式的

Netty这样的reactor反应器线程模型，底层的io线程是非阻塞式的

如果底层的io传输，也需要使用反应器线程，怎么办？ 3个措施：

• 那么要么使用netty，
• 要么使用基于netty的http组件。
• 或者基于netty自己进行封组

这里，使用了响应式的http组件，WebClient组件。使用 WebClient 进行了第四次迭代。