Dubbo 工作原理

Dubbo 的发展路径：

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

通信框架异步发送请求消息，请求消息发送成功后，返回代表业务结果的 CompletableFuture 给业务线程。之后对于 Future 的处理，根据调用类型会有所区别：
对于同步请求（如上图体现的场景），业务线程会调用 future.get 同步阻塞等待结果，当收到网络层返回的业务结果后，future.get 返回并最终将结果传递给调用发起方。
对于异步请求，业务线程不会调用 future.get，而是将 future 保存在调用上下文或者直接返回给调用者，同时会为 future 注册回调监听器，以便当真正的业务结果从通信层返回时监听器可以对结果做进一步的处理。
异步 Dubbo RPC 请求的调用流程:

1、消费方面向 Proxy 代理编程，发出调用请求，请求经过 Filter 链向下传递。
2、Invoker.invoke() 将请求异步转发给网络层，并收到代表返回结果的 Future。
3、Future 被包装到 Result，转而由 Result 代表这次远程调用的结果（由于 Result 的异步属性，此时它可能并不包含真正的返回值）。
4、Result 继续沿着调用链返回，在经过每个 Filter 时，Filter 可选择注册 Listener 监听器，以便在业务结果返回时执行结果预处理。
5、最终 Proxy 调用 result.recreate() 将结果返回给消费者：
如果方法是 CompletableFuture 签名，则返回 Future；
如果方法是普通同步签名，则返回对象默认值，Future 可通过 RpcContext 拿到；
6、 调用方在拿到代表异步业务结果的 Future 后，可选择注册回调监听器，以监听真正的业务结果返回。

同步调用和异步调用基本上是一致的，并且也是走的回调模式，只是在链路返回之前做了一次阻塞 get 调用，以确保在收到实际结果时再返回。Filter 在注册 Listener 时由于 Future 已处于 complete 状态，因此会同时触发回调 onResponse()/onError()。

关于流程图中提到的 Result，Result 在 Dubbo 的一次 RPC 调用中代表返回结果，在 3.0 中 Result 自身增加了代表状态的接口，类似 Future 现在 Result 可以代表一次未完成的调用。

要让 Result 具备代表异步返回结果的能力，有两中方式来实现：

1. Result is a Future，在 Java 8 中更合理的方式是继承 CompletionStage 接口。

public interface Result extends CompletionStage
{
}
2. 让 Result 实例持有 Future 实例，与 1 的区别即是设计中选用“继承”还是“组合”。
public class AsyncRpcResult implements Result
{
private CompletableFuture resultFuture;

}
同时，为了让 Result 更直观的体现其异步结果的特性，也为了方便面向 Result 接口编程，我们可以考虑为Result增加一些异步接口：
public interface
Result extends Serializable
{
Result thenApplyWithContext( Function<Result, Result> fn);
CompletableFuture thenApply(Function<Result ? extendsU> fn);
Result get() throws InterruptedException, ExecutionException;
}