友情提示：歡迎關注公眾號【芋道原始碼】。?關注後，拉你進【原始碼圈】微信群討論技術和原始碼。
友情提示：歡迎關注公眾號【芋道原始碼】。?關注後，拉你進【原始碼圈】微信群討論技術和原始碼。
友情提示：歡迎關注公眾號【芋道原始碼】。?關注後，拉你進【原始碼圈】微信群討論技術和原始碼。

前言

結束了叢集容錯和服務釋出原理這兩個小專題之後,有朋友問我服務引用什麼時候開始,本篇為服務引用的啟蒙篇.之前是一直和大家一起看原始碼,鑑於Talk is cheap.Show me your code,所以本篇將和大家一起寫寫程式碼.

插播面試題

• dubbo的原理是怎麼樣的?請簡單談談

• 有沒有考慮過自己實現一個類似dubbo的RPC框架,如果有,請問你會如果著手實現?(面試高頻題,區分度高)

• 你說你用過mybatis,那你知道Mapper介面的原理嗎?(如果回答得不錯,並且提到動態代理這個關鍵詞會繼續往下問,那這個動態代理又是如何通過依賴注入到Mapper介面的呢?)

直入主題

簡單原理

談到dubbo的原理,我們就必須首先要知道,dubbo的基本概念,通俗的說,就是dubbo是幹嘛的

dubbo是一個分散式服務框架，致力於提供高效能和透明化的RPC遠端服務呼叫方案，以及SOA服務治理方案

在此之前,就必須要講講以下幾個簡單又容易混淆的概念

• 叢集

同一個業務，部署在多個伺服器上

• 分散式

一個業務分拆多個子業務，部署在不同的伺服器上

• RPC

RPC（Remote Procedure Call Protocol）---遠端過程呼叫

我們捕捉到幾個重要的關鍵詞,分散式,透明化,RPC.

既然各服務是部署在不同的伺服器上,那服務間的呼叫就是要通過網路通訊,簡單的用圖描述如下:

之前在dubbo原始碼解析-本地暴露的時候就有很多朋友留言問到,這個本地暴露有什麼用.首先,dubbo作為一個被廣泛運用的框架,點滴的效能提升,那麼受益者都是很大一個數量.這也就是為什麼JDK的原始碼,都喜歡用位運算.比如圖中的UserService和RoleService服務是在同一模組內的,他們直接的通訊通過JVM效能肯定要比通過網路通訊要好得多.這就是為什麼dubbo在設計上,既有遠端暴露,又有本地暴露的原因.

既然涉及到了網路通訊,那麼服務消費者呼叫服務之前,都要寫各種網路請求,編解碼之類的相關程式碼,明顯是很不友好的.dubbo所說的透明

說了這麼多,那到底怎麼做?要實現這個需求,我們很容易想到一個關鍵詞,那就是動態代理

public interface MenuService {
    void sayHello();
}

public class MenuServiceImpl implements MenuService{
    @Override
    public void sayHello() {
    }
}

public class ProxyFactory implements InvocationHandler {
    private Class interfaceClass;
    public ProxyFactory(Class interfaceClass) {
        this.interfaceClass = interfaceClass;
    }
    //返回代理物件,此處用泛型為了呼叫時不用強轉,用Object需要強轉
    public  T getProxyObject(){
        return (T) Proxy.newProxyInstance(this.getClass().getClassLoader(),//類載入器
                new Class[]{interfaceClass},//為哪些介面做代理(攔截哪些方法)
                this);//(把這些方法攔截到哪處理)
    }
    @Override
    public Object invoke(Object proxy, Method method, Object[] args) throws Throwable {
        System.out.println(method);
        System.out.println("進行編碼");
        System.out.println("傳送網路請求");
        System.out.println("將網路請求結果進行解碼並返回");
        return null;
    }
}

public void test() throws Exception {
    ProxyFactory proxyFactor = new ProxyFactory(MenuService.class);
    MenuService menuService = proxyFactor.getProxyObject();
    menuService.sayHello();
    //輸出結果如下:
    //public abstract void com.toby.rpc.MenuService.sayHello()
    //進行編碼
    //傳送網路請求
    //將網路請求結果進行解碼並返回
}

看到這裡可能有朋友要吐槽了,我都看了你幾個月的原始碼解析了,上面說的那些我早就懂了,那我還關注肥朝幹嘛.我要的是整出一個類似dubbo的框架,效能上差點沒關係,至少外觀使用上要差不多,比如我們平時使用dubbo都是先在配置檔案配置這麼個東西

然後用在用@Autowired依賴注入來使用的,說白了,逼格要有!

與spring融合

我們假如要寫一個簡單的RPC,就取名叫tobyRPC(肥朝英文名為toby),其實我個人是比較喜歡截圖,但是部分朋友和我反覆強調貼程式碼,那這裡我就貼程式碼吧

1.設計配置屬性和JavaBean

public class ReferenceBean extends ReferenceConfig implements FactoryBean {
    @Override
    public Object getObject() throws Exception {
        return get();
    }
    @Override
    public Class<?> getObjectType() {
        return getInterfaceClass();
    }
    @Override
    public boolean isSingleton() {
        return true;
    }
}

public class ReferenceConfig {
    private Class<?> interfaceClass;
    // 介面代理類引用
    private transient volatile T ref;
    public synchronized T get() {
        if (ref == null) {
            init();
        }
        return ref;
    }
    private void init() {
        ref = new ProxyFactory(interfaceClass).getProxyObject();
    }
    public Class<?> getInterfaceClass() {
        return interfaceClass;
    }
    public void setInterfaceClass(Class<?> interfaceClass) {
        this.interfaceClass = interfaceClass;
    }
}

2.編寫XSD檔案

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
                        <![CDATA[ The service interface class name. ]]></xsd:documentation>
                            </tool:annotation>
                        </xsd:appinfo>
                    </xsd:annotation>
                </xsd:attribute>
            </xsd:extension>
        </xsd:complexContent>
    </xsd:complexType>
            <![CDATA[ Reference service config ]]></xsd:documentation>
        </xsd:annotation>
    </xsd:element>
</xsd:schema>

3.編寫NamespaceHandler和BeanDefinitionParser完成解析工作

public class TobyRPCBeanDefinitionParser extends AbstractSingleBeanDefinitionParser {
    protected Class getBeanClass(Element element) {
        return ReferenceBean.class;
    }
    protected void doParse(Element element, BeanDefinitionBuilder bean) {
        String interfaceClass = element.getAttribute("interface");
        if (StringUtils.hasText(interfaceClass)) {
            bean.addPropertyValue("interfaceClass", interfaceClass);
        }
    }
}

public class TobyRPCNamespaceHandler extends NamespaceHandlerSupport {
    public void init() {
        registerBeanDefinitionParser("reference", new TobyRPCBeanDefinitionParser());
    }
}

4.編寫spring.handlers和spring.schemas串聯起所有部件

spring.handlers

http\://toby.com/schema/tobyRPC=com.toby.config.TobyRPCNamespaceHandler

spring.schemas

http\://toby.com/schema/tobyRPC.xsd=META-INF/tobyRPC.xsd

5.建立配置檔案

<?xml version="1.0" encoding="UTF-8"?>

demo結構截圖如下:

萬事俱備,那我們跑個單元測試看看

執行結果如我們所料.但是具體要怎麼編碼,怎麼傳送請求,又如何解碼好像也沒說啊.沒說?沒說就對了.在完結服務引用這個小專題後,還會重點和大家看一下dubbo中的編解碼,spi,javassist等重點內容原始碼,等粗略把整個框架的思想都掌握後,再手把手臨摹一個五臟俱全(包含設計模式,dubbo架構設計)的簡易dubbo框架.總之一句話,關注肥朝即可.

敲黑板劃重點

為什麼面試都喜歡問原理,難道都是為了裝逼?當然不是,明白了原理,很多東西都是一通百通的.我們來看mybatis的這道面試題.首先Mapper介面的原理,可以參考我之前的別怕看原始碼,一張圖搞定Mybatis的Mapper原理 ,其實說白了,就是給Mapper介面注入一個代理物件,然後動態代理物件呼叫方法會被攔截到invoke中,然後在這個invoke方法中,做了一些不可描述的事情(老司機可以盡情YY).而這一切的前提,都是要無聲無息的把動態代理物件注入進去.其實注入進去的原理和dubbo也是一樣的,我們簡單看兩個圖

雄關萬道真如鐵,而今邁步從頭越

因為一些原因,經營了一年多的簡書,可能要逐步停更(流下兩行熱淚),大部分文章在後面會遷入掘金.今後的每週一篇也會在掘金首發

回首向來蕭瑟處,也無風雨也無晴

變的只是釋出平臺,不變的是還是那個無比熱愛技術的肥朝,每週一篇dubbo原始碼解析承諾依然不變(熟悉的配方,熟悉的味道).鑑於本人才疏學淺,不對的地方還望斧正,也歡迎大家繼續關注我的掘金,互相交流進步.簡書掘金同名,依舊為肥朝