异步框架方案

写在前面

参考Dubbo异步框架实现。

基本工作流程

通用的跨网络异步调用线程模型：

框架异步发送请求消息，请求发送成功后，返回业务结果CompletableFuture给业务线程。

• 对于同步请求，业务线程会调用future.get同步阻塞等待结果，收到网络层返回业务结果后，future.get返回最终结果传递给调用发起方。
• 对于异步请求，业务线程不会调用future.get，而是将future结果保存在调用上下文或者直接返回给调用者，同时为future注册回调监听器，当真正业务结果返回时通过监听器对结果进行处理。

关键词

Filter

通过Filter链上进行抽象设计，扩展机制实现定制需求。

异步事件

以前的方式直接返回Result，用起来简单，但是网络服务调用发送请求和接收响应本身是两个不同事件，两个过程都需要通过Filter链处理。

1. invoke返回值改为CompletableFuture，替换掉之前的Result的同步获取方式。
2. Result接口继承CompletationStage，实现响应异步计算，基于CompletableFuture实现框架内部全异步调用。

1. 消费者向proxy代理实现编码，发起调用请求，请求经过filter链传递
2. Invoke.invoke()将请求转交给网络层，并收到代表返回结果对Future
3. Future结果包装到Result，由Result代表此次调用结果
4. Result按照调用链返回，经过每个Filter，Filter可以选择注册Listener监听器，以便对业务结果进行预处理
5. Proxy调用result.recreate()将结果返回给消费者
6. 调用方拿到业务结果future后，可选择注册回调监听器，用来监听真正业务结果返回

同步调用和异步调用相似，只是在链路返回之前做一次阻塞get调用，由于Filter注册了Listener监听，当Future处于Complete状态时会触发onResponse()/onError()回调。

Listener

Filter保持单一职责，将回调接口单独提取到Listener中。

每个Filter都可以定义自己的Listener回调器，实现对返回结果的异步监听。

框架内部的异步实现不能提高单次调用性能，由于线程切换和回调逻辑，异步反而导致单次调用性能下降，但是异步可以减少对资源的占用，提升整个系统的并发程度和吞吐量，对于RPC这种处理网络延迟场景来说很适用。