记一次JSF异步调用引起的接口可用率降低
前言
本文记录了由于JSF异步调用超时引起的接口可用率降低问题的排查过程，主要介绍了排查思路和JSF异步调用的流程，希望可以帮助大家了解JSF的异步调用原理以及提供一些问题排查思路。本文分析的JSF源码是基于JSF 1,7.5-HOTFIX-T6版本。
起因
问题背景
1.广告投放系统是典型的I/O密集型（I/O Bound）服务，系统中某些接口单次操作可能依赖十几个外部接口,导致接口耗时较长，严重影响用户体验，因此需要将这些外部调用切换为异步模式，通过并发的模式降低整体耗时，提高接口的响应速度。
2.在同步调用的场景下，接口耗时长、性能差，接口响应时间长。这时为了缩短接口的响应时间，一般会使用线程池的方式并行获取数据，但是如果使用线程池来做，不同业务需要不同的线程池，最后会导致难以维护，随着CPU调度线程数的增加，会导致更严重的资源争用，宝贵的CPU资源被损耗在上下文切换上，而且线程本身也会占用系统资源，且不能无限增加。
3.通过阅读JSF的文档发现JSF是支持异步调用模式的，既然中间件已经支持这个功能，所以我们就采用了JSF提供的异步调用模式，目前JSF支持三种异步调用方式，分别是ResponseFuture方式、CompletableFuture方式和定义返回值为 CompletableFuture 的接口签名方式。
（1）RpcContext中获取ResponseFuture方式
该方式需要先将Consumer端的async属性设置为true，代表开启异步调用，然后在调用Provider的地方使用RpcContext.getContext().getFuture()方法获取一个ResponseFuture，拿到Future以后就可以使用get方法去阻塞等待返回，但是这种方式已经不推荐使用了，因为第二种CompletableFuture的模式更加强大。
代码示例:
asyncHelloService.sayHello("The ResponseFuture One");
ResponseFuture<Object> future1 = RpcContext.getContext().getFuture();
asyncHelloService.sayNoting("The ResponseFuture Two");
ResponseFuture<Object> future2 = RpcContext.getContext().getFuture();
try {
future1.get();
future2.get();
} catch (Throwable e) {
LOGGER.error("catch " + e.getClass().getCanonicalName() + " " + e.getMessage(), e);
}（2）RpcContext中获取CompletableFuture方式（1.7.5及以上版本支持）
该方式需要先将Consumer端的async属性设置为true，代表开启异步调用，然后在调用Provider的地方使用RpcContext.getContext().getCompletableFuture()方法获取到一个CompletableFuture进行后续操作。CompletableFuture对Future进行了扩展，可以通过设置回调的方式处理计算结果，支持组合操作，也支持进一步的编排，一定程度解决了回调地狱的问题。
代码示例:
asyncHelloService.sayHello("The CompletableFuture One");
CompletableFuture<String> cf1 = RpcContext.getContext().getCompletableFuture();
asyncHelloService.sayNoting("The CompletableFuture Two");
CompletableFuture<String> cf2 = RpcContext.getContext().getCompletableFuture();
CompletableFuture<String> cf3 = RpcContext.getContext().asyncCall(() -> {
asyncHelloService.sayHello("The CompletableFuture Three");
});
try {
cf1.get();
cf2.get();
cf3.get();
} catch (Throwable e) {
LOGGER.error("catch " + e.getClass(