工作原理

　　簡單的說，Dubbo是基于Java的RPC框架。Dubbo工作分為4個角色，分別是服務(wù)提供者、服務(wù)消費者、注冊中心、和監(jiān)控中心。

　　按照工作階段又分為部署階段和運行階段。

　　其中部署階段在圖中以藍色的線來表示，代表服務(wù)注冊、服務(wù)訂閱的過程，而運行階段在圖中以紅色的線來表示，代表一次RPC的完整調(diào)用。

　　部署階段中服務(wù)提供方在啟動時在指定的端口上暴露服務(wù)，并向注冊中心匯報自己的地址。

　　服務(wù)調(diào)用方啟動時向注冊中心訂閱自己感興趣的服務(wù)。

　　運行階段注冊中心先將地址列表推送給服務(wù)消費者，服務(wù)消費者選取一個地址向?qū)Χ税l(fā)起調(diào)用。

　　在這個過程中，服務(wù)消費者和服務(wù)提供者的運行狀態(tài)會上報給監(jiān)控中心。

　　整體架構(gòu)

　　這里是Dubbo的整體架構(gòu)圖。首先這張圖看起來很復(fù)雜、信息量很大。不要被嚇到。一點點的來看。

　　我先介紹一下這張圖的解讀方式。這張圖從左往右看，分為兩部分，左半邊藍色背景的部分代表服務(wù)消費者，右半邊綠色背景的部分代表服務(wù)提供者。

　　從上往下看又分為九層。

　　左邊九層按功能來劃分又被分為了三大類，分別是面向用戶的Biz層、框架核心RPC以及負責(zé)遠程傳輸?shù)腞emoting，右邊按面向人群又劃分為了兩類，上面兩層是面向用戶的API，而下面七層是面向擴展提供者的SPI。

　　圖中的線代表對象與對象之間不同的關(guān)系，紫色代表繼承；黑色代表依賴；藍色虛線代表服務(wù)注冊、服務(wù)訂閱的過程，也就是上面講的部署階段；紅色代表一次完整的RPC調(diào)用，也就是運行階段。

　　我們順著紅色的線，來看下一次完整的RPC調(diào)用是如何進行的。

　　首先從圖的左邊開始，服務(wù)消費者從Proxy層發(fā)起一次RPC調(diào)用，Dubbo從Registry層拿到服務(wù)的地址列表，再通過Cluster層選擇其中的一個作為目標地址，再流經(jīng)Protocol決定的執(zhí)行鏈，最后將服務(wù)信息，包括要調(diào)用的服務(wù)名、方法名、參數(shù)等序列化，再經(jīng)過應(yīng)用協(xié)議編碼，通過Transport層發(fā)送到網(wǎng)絡(luò)上。

　　右邊的服務(wù)提供者從網(wǎng)絡(luò)上收到數(shù)據(jù)以后，從下往上，依次通過應(yīng)用協(xié)議解碼、反序列化得到要調(diào)用的服務(wù)信息，再經(jīng)由執(zhí)行鏈，最終通過Invoker找到目標服務(wù)的目標方法，執(zhí)行并返回結(jié)果。

　　解讀完Dubbo的架構(gòu)圖，再來看看架構(gòu)圖中體現(xiàn)的設(shè)計原則。

　　Dubbo秉承高內(nèi)聚、低耦合的設(shè)計，這一點體現(xiàn)在架構(gòu)圖中九層的清晰劃分上，并且也體現(xiàn)在依賴的方向上。黑色的線條的方向永遠是從上指向下，沒有循環(huán)依賴和反向依賴的出現(xiàn)。

　　Dubbo還有一個很重要的設(shè)計哲學(xué)就是平等對待第三方的擴展，即Dubbo內(nèi)建的功能也是通過同樣的擴展機制提供出來的，第三方的擴展和內(nèi)建功能可以相互取代。正是由于Dubbo將第三方擴展當成框架的一等公民，為未來基于這個機制建立生態(tài)帶來了可能性。

　　以上就是動力節(jié)點java培訓(xùn)機構(gòu)的小編針對“java dubbo框架視頻教程”的內(nèi)容進行的回答，希望對大家有所幫助，如有疑問，請在線咨詢，有專業(yè)老師隨時為你服務(wù)。