Java進階專題(二十六) 將近2萬字的Dubbo原理解析,徹底搞懂dubbo

有夢想的老王發表於2021-03-27

前言

​ 前面我們研究了RPC的原理,市面上有很多基於RPC思想實現的框架,比如有Dubbo。今天就從Dubbo的SPI機制、服務註冊與發現原始碼及網路通訊過程去深入剖析下Dubbo。

Dubbo架構

概述

Dubbo是阿里巴巴公司開源的一個高效能優秀的服務框架,使得應用可通過高效能的RPC 實現服務的輸出和輸入功能,可以和Spring框架無縫整合。
Dubbo是一款高效能、輕量級的開源Java RPC框架,它提供了三大核心能力:面向介面的遠端方法呼叫,智慧容錯和負載均衡,以及服務自動註冊和發現。

呼叫流程:

  1. 服務容器負責啟動,載入,執行服務提供者。
  2. 服務提供者在啟動時,向註冊中心註冊自己提供的服務。
  3. 服務消費者在啟動時,向註冊中心訂閱自己所需的服務。
  4. 註冊中心返回服務提供者地址列表給消費者,如果有變更,註冊中心將基於長連線推送變更資料給消費者。
  5. 服務消費者,從提供者地址列表中,基於軟負載均衡演算法,選一臺提供者進行呼叫,如果呼叫失敗,再選另一臺呼叫。
  6. 服務消費者和提供者,在記憶體中累計呼叫次數和呼叫時間,定時每分鐘傳送一次統計資料到監控中心。

架構體系

原始碼結構

  • dubbo-common:公共邏輯模組: 包括Util類和通用模型
  • dubbo-remoting 遠端通訊模組: 相當於dubbo協議的實現,如果RPC使用RMI協議則不需要使用此包
  • dubbo-rpc 遠端呼叫模組: 抽象各種協議,以及動態代理,包含一對一的呼叫,不關心叢集的原理。
  • dubbo-cluster 叢集模組: 將多個服務提供方偽裝成一個提供方,包括負載均衡,容錯,路由等,叢集的地址列表可以是靜態配置的,也可以是註冊中心下發的.
  • dubbo-registry 註冊中心模組: 基於註冊中心下發的叢集方式,以及對各種註冊中心的抽象
  • dubbo-monitor 監控模組: 統計服務呼叫次數,呼叫時間,呼叫鏈跟蹤的服務.
  • dubbo-config 配置模組: 是dubbo對外的api,使用者通過config使用dubbo,隱藏dubbo所有細節
  • dubbo-container 容器模組: 是一個standlone的容器,以簡單的main載入spring啟動,因為服務通常不需要Tomcat/Jboss等web容器的特性,沒必要用web容器去載入服務.

整體設計

  • 圖中左邊淡藍背景的為服務消費方使用的介面,右邊淡綠色背景的為服務提供方使用的介面,位於中軸線上的為雙方都用到的介面。
  • 圖中從下至上分為十層,各層均為單向依賴,每一層都可以剝離上層被複用,其中,Service 和Config 層為API,其它各層均為SPI。
  • 圖中綠色小塊的為擴充套件介面,藍色小塊為實現類,圖中只顯示用於關聯各層的實現類。
  • 圖中藍色虛線為初始化過程,即啟動時組裝鏈,紅色實線為方法呼叫過程,即執行時調時鏈,紫色三角箭頭為繼承,可以把子類看作父類的同一個節點,線上的文字為呼叫的方法。

各層說明

  • config 配置層:對外配置介面,以 ServiceConfig , ReferenceConfig 為中心,可以直接初始化配置類,也可以通過spring 解析配置生成配置類
  • proxy 服務代理層:服務介面透明代理,生成服務的客戶端Stub 和伺服器端Skeleton, 以ServiceProxy 為中心,擴充套件介面為 ProxyFactory
  • registry 註冊中心層:封裝服務地址的註冊與發現,以服務URL 為中心,擴充套件介面為RegistryFactory , Registry , RegistryService
  • cluster 路由層:封裝多個提供者的路由及負載均衡,並橋接註冊中心,以 Invoker 為中心,擴充套件介面為 Cluster , Directory , Router , LoadBalance
  • monitor 監控層:RPC 呼叫次數和呼叫時間監控,以 Statistics 為中心,擴充套件介面為MonitorFactory , Monitor , MonitorService
  • protocol 遠端呼叫層:封裝RPC 呼叫,以 Invocation , Result 為中心,擴充套件介面為Protocol , Invoker , Exporter
  • exchange 資訊交換層:封裝請求響應模式,同步轉非同步,以 Request , Response 為中心,擴充套件介面為 Exchanger , ExchangeChannel , ExchangeClient , ExchangeServer
  • transport 網路傳輸層:抽象mina 和netty 為統一介面,以 Message 為中心,擴充套件介面為Channel , Transporter , Client , Server , Codec
  • serialize 資料序列化層:可複用的一些工具,擴充套件介面為 Serialization , ObjectInput ,ObjectOutput , ThreadPool

呼叫流程

對照上面的整體架構圖可以大致分為以下步驟:

1、服務提供者啟動,開啟Netty服務,建立Zookeeper客戶端,向註冊中心註冊服務。

2、服務消費者啟動,通過Zookeeper向註冊中心獲取服務提供者列表,與服務提供者通過Netty建立長連線。

3、服務消費者通過介面開始遠端呼叫服務,ProxyFactory通過初始化Proxy物件,Proxy通過建立動態代理物件。

4、動態代理物件通過invoke方法,層層包裝生成一個Invoker物件,該物件包含了代理物件。

5、Invoker通過路由,負載均衡選擇了一個最合適的服務提供者,在通過加入各種過濾器,協議層包裝生成一個新的DubboInvoker物件。

6、再通過交換成將DubboInvoker物件包裝成一個Reuqest物件,該物件通過序列化通過NettyClient傳輸到服務提供者的NettyServer端。

7、到了服務提供者這邊,再通過反序列化、協議解密等操作生成一個DubboExporter物件,再層層傳遞處理,會生成一個服務提供端的Invoker物件.

8、這個Invoker物件會呼叫本地服務,獲得結果再通過層層回撥返回到服務消費者,服務消費者拿到結果後,再解析獲得最終結果。

Dubbo中的SPI機制

什麼是SPI

概述

在Dubbo 中,SPI 是一個非常重要的模組。基於SPI,我們可以很容易的對Dubbo 進行擴充。如果大家想要學習Dubbo 的原始碼,SPI 機制務必弄懂。接下來,我們先來了解一下Java SPI 與Dubbo SPI 的用法,然後再來分析Dubbo SPI 的原始碼。

SPI是Service Provider Interface 服務提供介面縮寫,是一種服務發現機制。SPI的本質是將介面的實現類的全限定名定義在配置檔案中,並有伺服器讀取配置檔案,並載入實現類。這樣就可以在執行的時候,動態為介面替換實現類。

JDK中的SPI

Java SPI 實際上是“基於介面的程式設計+策略模式+配置檔案”組合實現的動態載入機制。

通過一個案例我們來認識下SPI

定義一個介面:

package com.laowang;

/**
 * @author 原
 * @date 2021/3/27
 * @since 1.0
 **/
public interface User {

    String showName();
}

定義兩個實現類

package com.laowang.impl;

import com.laowang.User;

/**
 * @author 原
 * @date 2021/3/27
 * @since 1.0
 **/
public class Student implements User {
    @Override
    public String showName() {
        System.out.println("my name is laowang");
        return null;
    }
}
package com.laowang.impl;

import com.laowang.User;

/**
 * @author 原
 * @date 2021/3/27
 * @since 1.0
 **/
public class Teacher implements User {
    @Override
    public String showName() {
        System.out.println("my name is zhangsan");
        return null;
    }
}

在resources目錄下建立資料夾META-INF.services,並在該資料夾下建立一個名稱與User的全路徑一致的檔案com.laowang.User

在檔案中寫入,兩個實現類的全路徑名

編寫測試類:

package com.laowang;

import java.util.ServiceLoader;

/**
 * @author 原
 * @date 2021/3/27
 * @since 1.0
 **/
public class SpiTest {
    public static void main(String[] args) {
        ServiceLoader<User> serviceLoader = ServiceLoader.load(User.class);
        serviceLoader.forEach(User::showName);
    }
}

執行結果:

我們發現通過SPI機制,幫我們自動執行了兩個實現類。

通過檢視ServiceLoader原始碼:

其實通過讀取配置檔案中實現類的全路徑類名,通過反射建立物件,並放入providers容器中。

總結:

呼叫過程
應用程式呼叫ServiceLoader.load方法,建立一個新的ServiceLoader,並例項化該類中的成員變數
應用程式通過迭代器介面獲取物件例項,ServiceLoader先判斷成員變數providers物件中(LinkedHashMap<String,S>型別)是否有快取例項物件,如果有快取,直接返回。如果沒有快取,執行類的裝載,
優點
使用Java SPI 機制的優勢是實現解耦,使得介面的定義與具體業務實現分離,而不是耦合在一起。應用程式可以根據實際業務情況啟用或替換具體元件。
缺點
不能按需載入。雖然ServiceLoader 做了延遲載入,但是基本只能通過遍歷全部獲取,也就是介面的實現類得全部載入並例項化一遍。如果你並不想用某些實現類,或者某些類例項化很耗時,它也被載入並例項化了,這就造成了浪費。
獲取某個實現類的方式不夠靈活,只能通過Iterator 形式獲取,不能根據某個引數來獲取對應的實現類。
多個併發多執行緒使用ServiceLoader 類的例項是不安全的。
載入不到實現類時丟擲並不是真正原因的異常,錯誤很難定位。

Dubbo中的SPI

Dubbo 並未使用Java SPI,而是重新實現了一套功能更強的SPI 機制。Dubbo SPI 的相關邏輯被封裝在了ExtensionLoader 類中,通過ExtensionLoader,我們可以載入指定的實現類。

栗子

與Java SPI 實現類配置不同,Dubbo SPI 是通過鍵值對的方式進行配置,這樣我們可以按需載入指定的實現類。下面來演示Dubbo SPI 的用法:
Dubbo SPI 所需的配置檔案需放置在META-INF/dubbo 路徑下,與Java SPI 實現類配置不同,DubboSPI 是通過鍵值對的方式進行配置,配置內容如下。

optimusPrime = org.apache.spi.OptimusPrime
bumblebee = org.apache.spi.Bumblebee

在使用Dubbo SPI 時,需要在介面上標註@SPI 註解。

@SPI
public interface Robot {
void sayHello();
}

通過ExtensionLoader,我們可以載入指定的實現類,下面來演示Dubbo SPI :

public class DubboSPITest {
   @Test
   public void sayHello() throws Exception {
       ExtensionLoader<Robot> extensionLoader =
           ExtensionLoader.getExtensionLoader(Robot.class);
       Robot optimusPrime = extensionLoader.getExtension("optimusPrime");
       optimusPrime.sayHello();
       Robot bumblebee = extensionLoader.getExtension("bumblebee");
       bumblebee.sayHello();
   }
}

Dubbo SPI 除了支援按需載入介面實現類,還增加了IOC 和AOP 等特性,這些特性將會在接下來的原始碼分析章節中一一進行介紹。

原始碼分析

ExtensionLoader 的getExtensionLoader 方法獲取一個ExtensionLoader 例項,然後再通過ExtensionLoader 的getExtension 方法獲取擴充類物件。下面我們從ExtensionLoader 的getExtension 方法作為入口,對擴充類物件的獲取過程進行詳細的分析。

public T getExtension(String name) {
       if (StringUtils.isEmpty(name)) {
           throw new IllegalArgumentException("Extension name == null");
       }
       if ("true".equals(name)) {
            // 獲取預設的擴充實現類
           return getDefaultExtension();
       }
       // Holder,顧名思義,用於持有目標物件 就是從容器中獲取,如果沒有直接new一個Holder
       Holder<Object> holder = getOrCreateHolder(name);
       //獲取目標物件例項
       Object instance = holder.get();
        // 如果目標物件例項為null 就需要通過雙重檢查建立例項
       if (instance == null) {
           synchronized (holder) {
               instance = holder.get();
               if (instance == null) {
                   // 建立擴充例項
                   instance = createExtension(name);
                   // 設定例項到 holder 中
                   holder.set(instance);
               }
           }
       }
       return (T) instance;
   }

上面程式碼的邏輯比較簡單,首先檢查快取,快取未命中則建立擴充物件。下面我們來看一下建立擴充物件的過程是怎樣的。

private T createExtension(String name) {
   // 從配置檔案中載入所有的擴充類,可得到“配置項名稱”到“配置類”的對映關係表
   Class<?> clazz = getExtensionClasses().get(name);
   if (clazz == null) {
       throw findException(name);
   }
   try {
       //從容器中獲取對應的例項物件 如果不存在就通過反射建立
       T instance = (T) EXTENSION_INSTANCES.get(clazz);
       if (instance == null) {
           // 通過反射建立例項
           EXTENSION_INSTANCES.putIfAbsent(clazz, clazz.newInstance());
           instance = (T) EXTENSION_INSTANCES.get(clazz);
       }
       // 向例項中注入依賴 下面是IOC和AOP的實現
       injectExtension(instance);
       Set<Class<?>> wrapperClasses = cachedWrapperClasses;
       if (CollectionUtils.isNotEmpty(wrapperClasses)) {
             // 迴圈建立 Wrapper 例項
           for (Class<?> wrapperClass : wrapperClasses) {
               // 將當前 instance 作為引數傳給 Wrapper 的構造方法,並通過反射建立Wrapper 例項。
               // 然後向 Wrapper 例項中注入依賴,最後將 Wrapper 例項再次賦值給instance 變數
               instance = injectExtension(
                   (T)
wrapperClass.getConstructor(type).newInstance(instance));
           }
       }

createExtension 方法的邏輯稍複雜一下,包含了如下的步驟:

  1. 通過getExtensionClasses 獲取所有的擴充類

  2. 通過反射建立擴充物件

  3. 向擴充物件中注入依賴

  4. 將擴充物件包裹在相應的Wrapper 物件中

以上步驟中,第一個步驟是載入擴充類的關鍵,第三和第四個步驟是Dubbo IOC 與AOP 的具體實現。由於此類設計原始碼較多,這裡簡單的總結下ExtensionLoader整個執行邏輯:

getExtension(String name)  #根據key獲取擴充物件
    -->createExtension(String name) #建立擴充例項
        -->getExtensionClasses #根據路徑獲取所有的擴充類
            -->loadExtensionClasses #載入擴充類
                -->cacheDefaultExtensionName #解析@SPI註解
            -->loadDirectory #方法載入指定資料夾配置檔案
                -->loadResource #載入資源
                    -->loadClass #載入類,並通過 loadClass 方法對類進行快取

Dubbo的SPI如何實現IOC和AOP的

Dubbo IOC

Dubbo IOC 是通過setter 方法注入依賴。Dubbo 首先會通過反射獲取到例項的所有方法,然後再遍歷方法列表,檢測方法名是否具有setter 方法特徵。若有,則通過ObjectFactory 獲取依賴物件,最後通過反射呼叫setter 方法將依賴設定到目標物件中。整個過程對應的程式碼如下:

    private T injectExtension(T instance) {
        try {
            if (objectFactory != null) {
                //獲取例項的所有方法
                for (Method method : instance.getClass().getMethods()) {
                    //isSetter做的事:檢測方法是否以 set 開頭,且方法僅有一個引數,且方法訪問級別為 public
                    if (isSetter(method)) {
                        /**
                         * Check {@link DisableInject} to see if we need auto injection for this property
                         */
                        if (method.getAnnotation(DisableInject.class) != null) {
                            continue;
                        }
                        Class<?> pt = method.getParameterTypes()[0];
                        if (ReflectUtils.isPrimitives(pt)) {
                            continue;
                        }
                        try {
                            String property = getSetterProperty(method);
                            //獲取依賴物件
                            Object object = objectFactory.getExtension(pt, property);
                            if (object != null) {
                                //設定屬性
                                method.invoke(instance, object);
                            }
                        } catch (Exception e) {
                            logger.error("Failed to inject via method " + method.getName()
                                    + " of interface " + type.getName() + ": " + e.getMessage(), e);
                        }
                    }
                }
            }
        } catch (Exception e) {
            logger.error(e.getMessage(), e);
        }
        return instance;
    }

Dubbo Aop

在說這個之前,我們得先知道裝飾者模式

裝飾者模式:在不改變原類檔案以及不使用繼承的情況下,動態地將責任附加到物件上,從而實現動態擴充一個物件的功能。它是通過建立一個包裝物件,也就是裝飾來包裹真實的物件。

在用Spring的時候,我們經常會用到AOP功能。在目標類的方法前後插入其他邏輯。比如通常使用Spring AOP來實現日誌,監控和鑑權等功能。Dubbo的擴充套件機制,是否也支援類似的功能呢?答案是yes。在Dubbo中,有一種特殊的類,被稱為Wrapper類。通過裝飾者模式,使用包裝類包裝原始的擴充套件點例項。在原始擴充套件點實現前後插入其他邏輯,實現AOP功能。

一般來說裝飾者模式有下面幾個參與者:
Component:裝飾者和被裝飾者共同的父類,是一個介面或者抽象類,用來定義基本行為
ConcreteComponent:定義具體物件,即被裝飾者
Decorator:抽象裝飾者,繼承自Component,從外類來擴充套件ConcreteComponent。對於ConcreteComponent來說,不需要知道Decorator的存在,Decorator是一個介面或抽象類
ConcreteDecorator:具體裝飾者,用於擴充套件ConcreteComponent

//獲取所有需要包裝的類
Set<Class<?>> wrapperClasses = cachedWrapperClasses;

我們再看看cachedWrapperClasses是什麼?

private Set<Class<?>> cachedWrapperClasses;

是一個set集合,那麼集合是什麼時候新增元素的呢?

    /**
     * cache wrapper class
     * <p>
     * like: ProtocolFilterWrapper, ProtocolListenerWrapper
     */
    private void cacheWrapperClass(Class<?> clazz) {
        if (cachedWrapperClasses == null) {
            cachedWrapperClasses = new ConcurrentHashSet<>();
        }
        cachedWrapperClasses.add(clazz);
    }

通過這個方法新增的,再看看誰呼叫了這個私有方法:

    /**
     * test if clazz is a wrapper class
     * <p>
     * which has Constructor with given class type as its only argument
     */
    private boolean isWrapperClass(Class<?> clazz) {
        try {
            clazz.getConstructor(type);
            return true;
        } catch (NoSuchMethodException e) {
            return false;
        }
    }

原來是通過isWrapperClass這個方法,判斷有沒有其他物件中的構造方法中持有本物件,如果有,dubbo就認為這是個裝飾類,呼叫裝飾者類的構造方法,並返回例項物件

然後通過例項化這個包裝類代替需要載入的這個類。這樣執行的方法就是包裝類的方法。

Dubbo中的動態編譯

我們知道在Dubbo 中,很多擴充都是通過SPI 機制 進行載入的,比如Protocol、Cluster、LoadBalance、ProxyFactory 等。有時,有些擴充並不想在框架啟動階段被載入,而是希望在擴充方法被呼叫時,根據執行時引數進行載入,即根據引數動態載入實現類。

這種在執行時,根據方法引數才動態決定使用具體的擴充,在dubbo中就叫做擴充套件點自適應例項。其實是一個擴充套件點的代理,將擴充套件的選擇從Dubbo啟動時,延遲到RPC呼叫時。Dubbo中每一個擴充套件點都有一個自適應類,如果沒有顯式提供,Dubbo會自動為我們建立一個,預設使用Javaassist。

自適應擴充機制的實現邏輯是這樣的

  1. 首先Dubbo 會為擴充介面生成具有代理功能的程式碼;
  2. 通過javassist 或jdk 編譯這段程式碼,得到Class 類;
  3. 通過反射建立代理類;
  4. 在代理類中,通過URL物件的引數來確定到底呼叫哪個實現類;

javassist

Javassist是一個開源的分析、編輯和建立Java位元組碼的類庫。是由東京工業大學的數學和電腦科學系的Shigeru Chiba (千葉滋)所建立的。它已加入了開放原始碼JBoss 應用伺服器專案,通過使用Javassist對位元組碼操作為JBoss實現動態AOP框架。javassist是jboss的一個子專案,其主要的優點,在於簡單,而且快速。直接使用java編碼的形式,而不需要了解虛擬機器指令,就能動態改變類的結構,或者動態生成類。

/**
*  Javassist是一個開源的分析、編輯和建立Java位元組碼的類庫
*  能動態改變類的結構,或者動態生成類
*/
public class CompilerByJavassist {
public static void main(String[] args) throws Exception {
// ClassPool:class物件容器
ClassPool pool = ClassPool.getDefault();
// 通過ClassPool生成一個User類
CtClass ctClass = pool.makeClass("com.itheima.domain.User");
// 新增屬性     -- private String username
CtField enameField = new CtField(pool.getCtClass("java.lang.String"),
"username", ctClass);
enameField.setModifiers(Modifier.PRIVATE);
ctClass.addField(enameField);
// 新增屬性    -- private int age
CtField enoField = new CtField(pool.getCtClass("int"), "age", ctClass);
enoField.setModifiers(Modifier.PRIVATE);
ctClass.addField(enoField);
//新增方法
ctClass.addMethod(CtNewMethod.getter("getUsername", enameField));
ctClass.addMethod(CtNewMethod.setter("setUsername", enameField));
ctClass.addMethod(CtNewMethod.getter("getAge", enoField));
ctClass.addMethod(CtNewMethod.setter("setAge", enoField));
// 無參構造器
CtConstructor constructor = new CtConstructor(null, ctClass);
constructor.setBody("{}");
ctClass.addConstructor(constructor);
// 新增建構函式
//ctClass.addConstructor(new CtConstructor(new CtClass[] {}, ctClass));
CtConstructor ctConstructor = new CtConstructor(new CtClass[]
{pool.get(String.class.getName()),CtClass.intType}, ctClass);
ctConstructor.setBody("{\n this.username=$1; \n this.age=$2;\n}");
ctClass.addConstructor(ctConstructor);
// 新增自定義方法
CtMethod ctMethod = new CtMethod(CtClass.voidType, "printUser",new
CtClass[] {}, ctClass);
// 為自定義方法設定修飾符
ctMethod.setModifiers(Modifier.PUBLIC);
// 為自定義方法設定函式體
StringBuffer buffer2 = new StringBuffer();
buffer2.append("{\nSystem.out.println(\"使用者資訊如下\");\n")
.append("System.out.println(\"使用者名稱=\"+username);\n")
.append("System.out.println(\"年齡=\"+age);\n").append("}");
ctMethod.setBody(buffer2.toString());
ctClass.addMethod(ctMethod);
//生成一個class
Class<?> clazz = ctClass.toClass();
Constructor cons2 =
clazz.getDeclaredConstructor(String.class,Integer.TYPE);
Object obj = cons2.newInstance("itheima",20);
//反射 執行方法
obj.getClass().getMethod("printUser", new Class[] {})
.invoke(obj, new Object[] {});
// 把生成的class檔案寫入檔案
byte[] byteArr = ctClass.toBytecode();
FileOutputStream fos = new FileOutputStream(new File("D://User.class"));
fos.write(byteArr);
fos.close();
}
}

原始碼分析

Adaptive註解

@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target({ElementType.TYPE, ElementType.METHOD})
public @interface Adaptive {
   String[] value() default {};
}

Adaptive 可註解在類或方法上。
標註在類上:Dubbo 不會為該類生成代理類。
標註在方法上:Dubbo 則會為該方法生成代理邏輯,表示當前方法需要根據 引數URL 呼叫對應的擴充套件點實現。

dubbo中每一個擴充套件點都有一個自適應類,如果沒有顯式提供,Dubbo會自動為我們建立一個,預設使用Javaassist。 先來看下建立自適應擴充套件類的程式碼

//1、看下extensionLoader的獲取方法
ExtensionLoader<Robot>extensionLoader=ExtensionLoader.getExtensionLoader(Robot.class);
//2、最終呼叫的是ExtensionLoader的構造方法
private ExtensionLoader(Class<?> type) {
        this.type = type;
        objectFactory = (type == ExtensionFactory.class ? null : ExtensionLoader.getExtensionLoader(ExtensionFactory.class).getAdaptiveExtension());
    }
//3、getAdaptiveExtension()看看幹了什麼事
    public T getAdaptiveExtension() {
        //獲取自適應擴充套件類,如果沒有就開始初始化一個
        Object instance = cachedAdaptiveInstance.get();
        if (instance == null) {
            if (createAdaptiveInstanceError == null) {
                synchronized (cachedAdaptiveInstance) {
                    instance = cachedAdaptiveInstance.get();
                    if (instance == null) {
                        try {
                            //這裡建立了一個自適應擴充套件類
                            instance = createAdaptiveExtension();
                            cachedAdaptiveInstance.set(instance);
                        } catch (Throwable t) {
                            createAdaptiveInstanceError = t;
                            throw new IllegalStateException("Failed to create adaptive instance: " + t.toString(), t);
                        }
                    }
                }
            } else {
                throw new IllegalStateException("Failed to create adaptive instance: " + createAdaptiveInstanceError.toString(), createAdaptiveInstanceError);
            }
        }

        return (T) instance;
    }
//看看createAdaptiveExtension()
 private T createAdaptiveExtension() {
        try {
            return injectExtension((T) getAdaptiveExtensionClass().newInstance());
        } catch (Exception e) {
            throw new IllegalStateException("Can't create adaptive extension " + type + ", cause: " + e.getMessage(), e);
        }
    }
//再進到getAdaptiveExtensionClass()
    private Class<?> getAdaptiveExtensionClass() {
        getExtensionClasses();
        if (cachedAdaptiveClass != null) {
            return cachedAdaptiveClass;
        }
        return cachedAdaptiveClass = createAdaptiveExtensionClass();
    }
//繼續追進去createAdaptiveExtensionClass()
private Class<?> createAdaptiveExtensionClass() {
        String code = new AdaptiveClassCodeGenerator(type, cachedDefaultName).generate();
        ClassLoader classLoader = findClassLoader();
        org.apache.dubbo.common.compiler.Compiler compiler = ExtensionLoader.getExtensionLoader(org.apache.dubbo.common.compiler.Compiler.class).getAdaptiveExtension();
        return compiler.compile(code, classLoader);
    }

//看看compiler
@SPI("javassist")
public interface Compiler {

    /**
     * Compile java source code.
     *
     * @param code        Java source code
     * @param classLoader classloader
     * @return Compiled class
     */
    Class<?> compile(String code, ClassLoader classLoader);

}
//其實到這裡就知道了,通過生成一個類的字串,再通過javassist生成一個物件

createAdaptiveExtensionClassCode()方法中使用一個StringBuilder來構建自適應類的Java原始碼。方法實現比較長,這裡就不貼程式碼了。這種生成位元組碼的方式也挺有意思的,先生成Java原始碼,然後編譯,載入到jvm中。通過這種方式,可以更好的控制生成的Java類。而且這樣也不用care各個位元組碼生成框架的api等。因為xxx.java檔案是Java通用的,也是我們最熟悉的。只是程式碼的可讀性不強,需要一點一點構建xx.java的內容。

服務暴露與發現

服務暴露

名詞解釋

在Dubbo 的核心領域模型中:

  • Invoker 是實體域,它是Dubbo 的核心模型,其它模型都向它靠擾,或轉換成它,它代表一個可執行體,可向它發起invoke 呼叫,它有可能是一個本地的實現,也可能是一個遠端的實現,也可能一個叢集實現。在服務提供方,Invoker用於呼叫服務提供類。在服務消費方,Invoker用於執行遠端呼叫。
  • Protocol 是服務域,它是Invoker 暴露和引用的主功能入口,它負責Invoker 的生命週期管理。
    export:暴露遠端服務
    refer:引用遠端服務
  • proxyFactory:獲取一個介面的代理類
    getInvoker:針對server端,將服務物件,如DemoServiceImpl包裝成一個Invoker物件
    getProxy:針對client端,建立介面的代理物件,例如DemoService的介面。
  • Invocation 是會話域,它持有呼叫過程中的變數,比如方法名,引數等

整體流程

在詳細探討服務暴露細節之前 , 我們先看一下整體duubo的服務暴露原理

在整體上看,Dubbo 框架做服務暴露分為兩大部分 , 第一步將持有的服務例項通過代理轉換成Invoker, 第二步會把Invoker 通過具體的協議 ( 比如Dubbo ) 轉換成Exporter, 框架做了這層抽象也大大方便了功能擴充套件 。

服務提供方暴露服務的藍色初始化鏈,時序圖如下:

原始碼分析

服務匯出的入口方法是ServiceBean 的onApplicationEvent。onApplicationEvent 是一個事件響應方法,該方法會在收到Spring 上下文重新整理事件後執行服務匯出操作。方法程式碼如下:

    @Override
    public void onApplicationEvent(ContextRefreshedEvent event) {
        if (!isExported() && !isUnexported()) {
            if (logger.isInfoEnabled()) {
                logger.info("The service ready on spring started. service: " + getInterface());
            }
            export();
        }
    }

通過export最終找到doExportUrls()方法

private void doExportUrls() {
    	//載入配置檔案中的所有註冊中心,並且封裝為dubbo內部的URL物件列表
        List<URL> registryURLs = loadRegistries(true);
        //迴圈所有協議配置,根據不同的協議,向註冊中心中發起註冊
        for (ProtocolConfig protocolConfig : protocols) {
            String pathKey = URL.buildKey(getContextPath(protocolConfig).map(p -> p + "/" + path).orElse(path), group, version);
            ProviderModel providerModel = new ProviderModel(pathKey, ref, interfaceClass);
            ApplicationModel.initProviderModel(pathKey, providerModel);
            //服務暴露方法
            doExportUrlsFor1Protocol(protocolConfig, registryURLs);
        }
    }

doExportUrlsFor1Protocol()方法程式碼老多了,我們只關係核心的地方

...
    if (!SCOPE_NONE.equalsIgnoreCase(scope)) {

            //本地暴露,將服務資料記錄到本地JVM中
            if (!SCOPE_REMOTE.equalsIgnoreCase(scope)) {
                exportLocal(url);
            }
           //遠端暴露,向註冊中心傳送資料
            if (!SCOPE_LOCAL.equalsIgnoreCase(scope)) {
                if (!isOnlyInJvm() && logger.isInfoEnabled()) {
                    logger.info("Export dubbo service " + interfaceClass.getName() + " to url " + url);
                }
                if (CollectionUtils.isNotEmpty(registryURLs)) {
                    for (URL registryURL : registryURLs) {
                        //if protocol is only injvm ,not register
                        if (LOCAL_PROTOCOL.equalsIgnoreCase(url.getProtocol())) {
                            continue;
                        }
                        url = url.addParameterIfAbsent(DYNAMIC_KEY, registryURL.getParameter(DYNAMIC_KEY));
                        URL monitorUrl = loadMonitor(registryURL);
                        if (monitorUrl != null) {
		                    url = url.addParameterAndEncoded(MONITOR_KEY, monitorUrl.toFullString());
	                    }
                        if (logger.isInfoEnabled()) {
                            logger.info("Register dubbo service " + interfaceClass.getName() + " url " + url + " to registry " + registryURL);
                        }

                        // For providers, this is used to enable custom proxy to generate invoker
                        String proxy = url.getParameter(PROXY_KEY);
                        if (StringUtils.isNotEmpty(proxy)) {
                            registryURL = registryURL.addParameter(PROXY_KEY, proxy);
                        }
						// 為服務提供類(ref)生成 Invoker
                        Invoker<?> invoker = proxyFactory.getInvoker(ref, (Class) interfaceClass, registryURL.addParameterAndEncoded(EXPORT_KEY, url.toFullString()));
                       // DelegateProviderMetaDataInvoker 用於持有 Invoker 和ServiceConfig
                        DelegateProviderMetaDataInvoker wrapperInvoker = new DelegateProviderMetaDataInvoker(invoker, this);
                        // 匯出服務,並生成 Exporter
                        Exporter<?> exporter = protocol.export(wrapperInvoker);
                        exporters.add(exporter);
                    }
                } else {
                    //不存在註冊中心,僅匯出服務
                    ....
                }
                /**
                 * @since 2.7.0
                 * ServiceData Store
                 */
                MetadataReportService metadataReportService = null;
                if ((metadataReportService = getMetadataReportService()) != null) {
                    metadataReportService.publishProvider(url);
                }
            }
        }
        this.urls.add(url);

上面程式碼根據url 中的scope 引數決定服務匯出方式,分別如下:
scope = none,不匯出服務
scope != remote,匯出到本地
scope != local,匯出到遠端

不管是匯出到本地,還是遠端。進行服務匯出之前,均需要先建立Invoker,這是一個很重要的步驟。因此下面先來分析Invoker 的建立過程。Invoker 是由ProxyFactory 建立而來,Dubbo 預設的ProxyFactory 實現類是JavassistProxyFactory。下面我們到JavassistProxyFactory 程式碼中,探索Invoker 的建立過程。如下:

    @Override
    public <T> Invoker<T> getInvoker(T proxy, Class<T> type, URL url) {
        // 為目標類建立warpper
        final Wrapper wrapper = Wrapper.getWrapper(proxy.getClass().getName().indexOf('$') < 0 ? proxy.getClass() : type);
        //建立匿名才invoker物件,並實現doinvoke方法
        return new AbstractProxyInvoker<T>(proxy, type, url) {
            @Override
            protected Object doInvoke(T proxy, String methodName,
                                      Class<?>[] parameterTypes,
                                      Object[] arguments) throws Throwable {
                // 呼叫 Wrapper 的 invokeMethod 方法,invokeMethod 最終會呼叫目標方法
                return wrapper.invokeMethod(proxy, methodName, parameterTypes, arguments);
            }
        };
    }

Invoke建立成功之後,接下來我們來看本地匯出

    /**
     * always export injvm
     */
    private void exportLocal(URL url) {
        URL local = URLBuilder.from(url)
                .setProtocol(LOCAL_PROTOCOL) // 設定協議頭為 injvm
                .setHost(LOCALHOST_VALUE)//本地ip:127.0.0.1
                .setPort(0)
                .build();
        // 建立 Invoker,並匯出服務,這裡的 protocol 會在執行時呼叫 InjvmProtocol 的export 方法
        Exporter<?> exporter = protocol.export(
                proxyFactory.getInvoker(ref, (Class) interfaceClass, local));
        exporters.add(exporter);
        logger.info("Export dubbo service " + interfaceClass.getName() + " to local registry url : " + local);
    }

exportLocal 方法比較簡單,首先根據URL 協議頭決定是否匯出服務。若需匯出,則建立一個新的URL並將協議頭、主機名以及埠設定成新的值。然後建立Invoker,並呼叫InjvmProtocol 的export 方法匯出服務。下面我們來看一下InjvmProtocol 的export 方法都做了哪些事情。

    @Override
    public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException {
        return new InjvmExporter<T>(invoker, invoker.getUrl().getServiceKey(), exporterMap);
    }

如上,InjvmProtocol 的export 方法僅建立了一個InjvmExporter,無其他邏輯。到此匯出服務到本地就分析完了。

再看看匯出服務到遠端

接下來,我們繼續分析匯出服務到遠端的過程。匯出服務到遠端包含了服務匯出與服務註冊兩個過程。先來分析服務匯出邏輯。我們把目光移動到RegistryProtocol 的export 方法上。

    @Override
    public <T> Exporter<T> export(final Invoker<T> originInvoker) throws RpcException {
        // 獲取註冊中心 URL
        URL registryUrl = getRegistryUrl(originInvoker);
        URL providerUrl = getProviderUrl(originInvoker);
        final URL overrideSubscribeUrl = getSubscribedOverrideUrl(providerUrl);
        final OverrideListener overrideSubscribeListener = new OverrideListener(overrideSubscribeUrl, originInvoker);
        overrideListeners.put(overrideSubscribeUrl, overrideSubscribeListener);

        providerUrl = overrideUrlWithConfig(providerUrl, overrideSubscribeListener);

	    //匯出服務
        final ExporterChangeableWrapper<T> exporter = doLocalExport(originInvoker, providerUrl);

	    // 根據 URL 載入 Registry 實現類,比如 ZookeeperRegistry
        final Registry registry = getRegistry(originInvoker);

	    //獲取已註冊的服務提供者 URL,
        final URL registeredProviderUrl = getRegisteredProviderUrl(providerUrl, registryUrl);
        ProviderInvokerWrapper<T> providerInvokerWrapper = ProviderConsumerRegTable.registerProvider(originInvoker,
                registryUrl, registeredProviderUrl);
        //to judge if we need to delay publish
        boolean register = registeredProviderUrl.getParameter("register", true);
        if (register) {
            // 向註冊中心註冊服務
            register(registryUrl, registeredProviderUrl);
            providerInvokerWrapper.setReg(true);
        }

        //  向註冊中心進行訂閱 override 資料
        registry.subscribe(overrideSubscribeUrl, overrideSubscribeListener);

        exporter.setRegisterUrl(registeredProviderUrl);
        exporter.setSubscribeUrl(overrideSubscribeUrl);
        // 建立並返回 DestroyableExporter
        return new DestroyableExporter<>(exporter);
    }

上面程式碼看起來比較複雜,主要做如下一些操作:

  1. 呼叫doLocalExport 匯出服務
  2. 向註冊中心註冊服務
  3. 向註冊中心進行訂閱override 資料
  4. 建立並返回DestroyableExporter

看看doLocalExport 做了什麼

    private <T> ExporterChangeableWrapper<T> doLocalExport(final Invoker<T> originInvoker, URL providerUrl) {
        String key = getCacheKey(originInvoker);

        return (ExporterChangeableWrapper<T>) bounds.computeIfAbsent(key, s -> {
            Invoker<?> invokerDelegate = new InvokerDelegate<>(originInvoker, providerUrl);
            //protocol和配置的協議相關(dubbo:DubboProtocol)
            return new ExporterChangeableWrapper<>((Exporter<T>) protocol.export(invokerDelegate), originInvoker);
        });
    }

接下來,我們把重點放在Protocol 的export 方法上。假設執行時協議為dubbo,此處的protocol 變數會在執行時載入DubboProtocol,並呼叫DubboProtocol 的export 方法。

    public <T> Exporter<T> export(Invoker<T> invoker) throws RpcException {
        URL url = invoker.getUrl();

        // export service.獲取服務標識,理解成服務座標也行。由服務組名,服務名,服務版本號以及埠組成。比如:demoGroup/com.alibaba.dubbo.demo.DemoService:1.0.1:20880
        String key = serviceKey(url);
        //建立DubboExporter
        DubboExporter<T> exporter = new DubboExporter<T>(invoker, key, exporterMap);
        exporterMap.put(key, exporter); //key:介面 (DemoService)

        //export an stub service for dispatching event
        Boolean isStubSupportEvent = url.getParameter(STUB_EVENT_KEY, DEFAULT_STUB_EVENT);
        Boolean isCallbackservice = url.getParameter(IS_CALLBACK_SERVICE, false);
        if (isStubSupportEvent && !isCallbackservice) {
            String stubServiceMethods = url.getParameter(STUB_EVENT_METHODS_KEY);
            if (stubServiceMethods == null || stubServiceMethods.length() == 0) {
                if (logger.isWarnEnabled()) {
                    logger.warn(new IllegalStateException("consumer [" + url.getParameter(INTERFACE_KEY) +
                            "], has set stubproxy support event ,but no stub methods founded."));
                }

            } else {
                stubServiceMethodsMap.put(url.getServiceKey(), stubServiceMethods);
            }
        }
		//啟動服務
        openServer(url);
        //優化序列器
        optimizeSerialization(url);

        return exporter;
    }

如上,我們重點關注DubboExporter 的建立以及openServer 方法,其他邏輯看不懂也沒關係,不影響理解服務匯出過程。下面分析openServer 方法。

    private void openServer(URL url) {
        // find server.
        String key = url.getAddress();
        //client can export a service which's only for server to invoke
        boolean isServer = url.getParameter(IS_SERVER_KEY, true);
        if (isServer) {
            //訪問快取
            ExchangeServer server = serverMap.get(key);
            if (server == null) {
                synchronized (this) {
                    server = serverMap.get(key);
                    if (server == null) {
                        //建立伺服器例項
                        serverMap.put(key, createServer(url));
                    }
                }
            } else {
                // server supports reset, use together with override
                server.reset(url);
            }
        }
    }

接下來分析伺服器例項的建立過程。如下

    private ExchangeServer createServer(URL url) {
        url = URLBuilder.from(url)
                // send readonly event when server closes, it's enabled by default
                .addParameterIfAbsent(CHANNEL_READONLYEVENT_SENT_KEY, Boolean.TRUE.toString())
                // enable heartbeat by default
                .addParameterIfAbsent(HEARTBEAT_KEY, String.valueOf(DEFAULT_HEARTBEAT))
                .addParameter(CODEC_KEY, DubboCodec.NAME)
                .build();
        String str = url.getParameter(SERVER_KEY, DEFAULT_REMOTING_SERVER);
        
		// 通過 SPI 檢測是否存在 server 引數所代表的 Transporter 擴充,不存在則丟擲異常
        if (str != null && str.length() > 0 && !ExtensionLoader.getExtensionLoader(Transporter.class).hasExtension(str)) {
            throw new RpcException("Unsupported server type: " + str + ", url: " + url);
        }

        ExchangeServer server;
        try {
            // 建立 ExchangeServer
            server = Exchangers.bind(url, requestHandler);
        } catch (RemotingException e) {
            throw new RpcException("Fail to start server(url: " + url + ") " + e.getMessage(), e);
        }
        
		// 獲取 client 引數,可指定 netty,mina
        str = url.getParameter(CLIENT_KEY);
        if (str != null && str.length() > 0) {
            // 獲取所有的 Transporter 實現類名稱集合,比如 supportedTypes = [netty, mina]
            Set<String> supportedTypes = ExtensionLoader.getExtensionLoader(Transporter.class).getSupportedExtensions();
            // 檢測當前 Dubbo 所支援的 Transporter 實現類名稱列表中,
      		 // 是否包含 client 所表示的 Transporter,若不包含,則丟擲異常
            if (!supportedTypes.contains(str)) {
                throw new RpcException("Unsupported client type: " + str);
            }
        }

        return server;
    }

如上,createServer 包含三個核心的邏輯。

第一是檢測是否存在server 引數所代表的Transporter 擴充,不存在則丟擲異常。

第二是建立伺服器例項。

第三是檢測是否支援client 引數所表示的Transporter 擴充,不存在也是丟擲異常。兩次檢測操作所對應的程式碼較直白了,無需多說。但建立伺服器的操作目前還不是很清晰,我們繼續往下看。

    public static ExchangeServer bind(URL url, ExchangeHandler handler) throws RemotingException {
        if (url == null) {
            throw new IllegalArgumentException("url == null");
        }
        if (handler == null) {
            throw new IllegalArgumentException("handler == null");
        }
        url = url.addParameterIfAbsent(Constants.CODEC_KEY, "exchange");
        // 獲取 Exchanger,預設為 HeaderExchanger。
   		// 緊接著呼叫 HeaderExchanger 的 bind 方法建立 ExchangeServer 例項
        return getExchanger(url).bind(url, handler);
    }

上面程式碼比較簡單,就不多說了。下面看一下HeaderExchanger 的bind 方法。

    public ExchangeServer bind(URL url, ExchangeHandler handler) throws RemotingException {
        // 建立 HeaderExchangeServer 例項,該方法包含了多個邏輯,分別如下:
        //   1. new HeaderExchangeHandler(handler)
        //   2. new DecodeHandler(new HeaderExchangeHandler(handler))
        //   3. Transporters.bind(url, new DecodeHandler(new
HeaderExchangeHandler(handler)))
        return new HeaderExchangeServer(Transporters.bind(url, new ChannelHandler[]{new DecodeHandler(new HeaderExchangeHandler(handler))}));
    }

HeaderExchanger 的bind 方法包含的邏輯比較多,但目前我們僅需關心Transporters 的bind 方法邏
輯即可。該方法的程式碼如下:

    public static Server bind(URL url, ChannelHandler... handlers) throws RemotingException {
        if (url == null) {
            throw new IllegalArgumentException("url == null");
        } else if (handlers != null && handlers.length != 0) {
            Object handler;
            if (handlers.length == 1) {
                handler = handlers[0];
            } else {
                // 如果 handlers 元素數量大於1,則建立 ChannelHandler 分發器
                handler = new ChannelHandlerDispatcher(handlers);
            }
			// 獲取自適應 Transporter 例項,並呼叫例項方法
            return getTransporter().bind(url, (ChannelHandler)handler);
        } else {
            throw new IllegalArgumentException("handlers == null");
        }
    }

如上,getTransporter() 方法獲取的Transporter 是在執行時動態建立的,類名為TransporterAdaptive,也就是自適應擴充類。TransporterAdaptive 會在執行時根據傳入的URL 引數決定載入什麼型別的Transporter,預設為NettyTransporter。呼叫 NettyTransporter.bind(URL,ChannelHandler) 方法。建立一個 NettyServer 例項。呼叫 NettyServer.doOPen() 方法,伺服器被開啟,服務也被暴露出來了。

服務註冊

本節內容以Zookeeper 註冊中心作為分析目標,其他型別註冊中心大家可自行分析。下面從服務註冊
的入口方法開始分析,我們把目光再次移到RegistryProtocol 的export 方法上。如下:

進入到register()方法

    public void register(URL registryUrl, URL registeredProviderUrl) {
        //獲得註冊中心例項
        Registry registry = registryFactory.getRegistry(registryUrl);
        //進行註冊
        registry.register(registeredProviderUrl);
    }

看看getRegistry()方法

    @Override
    public Registry getRegistry(URL url) {
        url = URLBuilder.from(url)
                .setPath(RegistryService.class.getName())
                .addParameter(INTERFACE_KEY, RegistryService.class.getName())
                .removeParameters(EXPORT_KEY, REFER_KEY)
                .build();
        String key = url.toServiceStringWithoutResolving();
        // Lock the registry access process to ensure a single instance of the registry
        LOCK.lock();
        try {
            Registry registry = REGISTRIES.get(key);
            if (registry != null) {
                return registry;
            }
            //create registry by spi/ioc
            registry = createRegistry(url);
            if (registry == null) {
                throw new IllegalStateException("Can not create registry " + url);
            }
            REGISTRIES.put(key, registry);
            return registry;
        } finally {
            // Release the lock
            LOCK.unlock();
        }
    }

進入createRegistry()方法

    @Override
    public Registry createRegistry(URL url) {
        return new ZookeeperRegistry(url, zookeeperTransporter);
    }
    public ZookeeperRegistry(URL url, ZookeeperTransporter zookeeperTransporter) {
        super(url);
        if (url.isAnyHost()) {
            throw new IllegalStateException("registry address == null");
        }
        //// 獲取組名,預設為 dubbo
        String group = url.getParameter(GROUP_KEY, DEFAULT_ROOT);
        if (!group.startsWith(PATH_SEPARATOR)) {
            group = PATH_SEPARATOR + group;
        }
        this.root = group;
        // 建立 Zookeeper 客戶端,預設為 CuratorZookeeperTransporter
        zkClient = zookeeperTransporter.connect(url);
        // 新增狀態監聽器
        zkClient.addStateListener(state -> {
            if (state == StateListener.RECONNECTED) {
                try {
                    recover();
                } catch (Exception e) {
                    logger.error(e.getMessage(), e);
                }
            }
        });
    }

在上面的程式碼程式碼中,我們重點關注ZookeeperTransporter 的connect 方法呼叫,這個方法用於建立
Zookeeper 客戶端。建立好Zookeeper 客戶端,意味著註冊中心的建立過程就結束了。

搞懂了服務註冊的本質,那麼接下來我們就可以去閱讀服務註冊的程式碼了。

    public void doRegister(URL url) {
        try {
            // 通過 Zookeeper 客戶端建立節點,節點路徑由 toUrlPath 方法生成,路徑格式如下:
       //  /${group}/${serviceInterface}/providers/${url}
       // 比如 /dubbo/org.apache.dubbo.DemoService/providers/dubbo%3A%2F%2F127.0.0.1......
            zkClient.create(toUrlPath(url), url.getParameter(DYNAMIC_KEY, true));
        } catch (Throwable e) {
            throw new RpcException("Failed to register " + url + " to zookeeper " + getUrl() + ", cause: " + e.getMessage(), e);
        }
    }
    @Override
    public void create(String path, boolean ephemeral) {
        if (!ephemeral) {
            // 如果要建立的節點型別非臨時節點,那麼這裡要檢測節點是否存在
            if (checkExists(path)) {
                return;
            }
        }
        int i = path.lastIndexOf('/');
        if (i > 0) {
            // 遞迴建立上一級路徑
            create(path.substring(0, i), false);
        }
        // 根據 ephemeral 的值建立臨時或持久節點
        if (ephemeral) {
            createEphemeral(path);
        } else {
            createPersistent(path);
        }
    }

好了,到此關於服務註冊的過程就分析完了。整個過程可簡單總結為:先建立註冊中心例項,之後再通過註冊中心例項註冊服務。

總結

  1. 在有註冊中心,需要註冊提供者地址的情況下,ServiceConfig 解析出的URL 格式為:registry:// registry-host/org.apache.dubbo.registry.RegistryService?export=URL.encode("dubbo://service-host/{服務名}/{版本號}")
  2. 基於Dubbo SPI 的自適應機制,通過URL registry:// 協議頭識別,就呼叫RegistryProtocol#export() 方法
  3. 將具體的服務類名,比如 DubboServiceRegistryImpl ,通過ProxyFactory 包裝成Invoker 例項
  4. 呼叫doLocalExport 方法,使用DubboProtocol 將Invoker 轉化為Exporter 例項,並開啟Netty 服務端監聽客戶請求
  5. 建立Registry 例項,連線Zookeeper,並在服務節點下寫入提供者的URL 地址,註冊服務
  6. 向註冊中心訂閱override 資料,並返回一個Exporter 例項
  7. 根據URL 格式中的 "dubbo://service-host/{服務名}/{版本號}" 中協議頭 dubbo:// 識別,呼叫DubboProtocol#export() 方法,開發服務埠
  8. RegistryProtocol#export() 返回的Exporter 例項存放到ServiceConfig 的 List<Exporter>exporters

相關文章