一书一图-深度剖析Apache Dubbo核心技术内幕

写在开头

需要重点理解的点是增强SPI和适配器(所有@SPI注解会生成Adaptive适配类)，这两点关乎于核心的protocol和invoker的加载和多态控制
主要关心服务发布流程与消费端启动和调用流程，服务降级、集群容错、负载均衡、线程模型和线程池策略等可以之后单独了解，它们内容多但是代码结构和调用并不复杂
Dubbo自封装的netty模块可以不用深究，主要分 handler 和 Dubbo自定义的数据协议
zookeeper主要扮演配置中心和注册中心使用，服务提供者的变动会触发zk节点变动，从而通知到消费者及时变更内存缓存的服务提供者
注释代码
设计模式多用装饰模式、代理模式、责任链模式、策略模式
书中有部分内容在阅读时产生了理解歧义，可惜没有联系书籍作者的途径，此处作保留，希望有读者可以交流理解

细节疑问

图3.6

private void invoke(Channel channel, String methodKey) {
    Invocation invocation = createInvocation(channel, channel.getUrl(), methodKey);
    // connected 与 disconnected 均不会创建 invocation 实例，因此后续代码不会执行
    if (invocation != null) {
        try {
            received(channel, invocation);
        } catch (Throwable t) {
            logger.warn("Failed to invoke event method " + invocation.getMethodName() + "(), cause: " + t.getMessage(), t);
        }
    }
}

关于步骤11，在Debug的过程中发现，对于onconnected事件，此时invocation应该是null，因此不会执行received

P96

从上面的代码可知，MockClusterWrapper 类把 FailoverClusterInvoker 包装成了MockClusterInvoker 实例，所以整个调用链最终调用返回的是 MockClusterInvoker对象。也就是说，本节第一个时序图(见图3.8)中的步骤4返回的是 MockClusterWrapper，然后执行图3.9中的步骤14以获取 MockClusterInvoker 的代理，实现 invoker 到客户端接口的转换…

疑惑点在于在debug过程中，发现org.apache.dubbo.registry.integration.RegistryProtocol#cluster的确是在3.8的步骤4通过IOC注入，但此时并不是返回结果，尚在执行过程中，执行到3-9的步骤14时，通过在org.apache.dubbo.rpc.protocol.ProtocolFilterWrapper#buildInvokerChain断点确认 invoker 还是 DubboInvoker，此时只有继续执行，等到3-8的步骤12（org.apache.dubbo.registry.integration.RegistryProtocol#doRefer）时，才会通过之前注入的 MockClusterWrapper 返回 MockClusterInvoker。然后层层返回，最终返回到3-8的步骤4，再通过proxyFactory.getProxy(invoker) 获取代理。

P230

先看看 DubboCodec 的子类 ExchangeCodec 的 encode() 方法

ExchangeCodec应该是DubboCodec的父类