知識星球
作者：肥朝
原文地址：http://www.jianshu.com/p/f06d62fd1a73
友情提示：歡迎關註公眾號【芋道原始碼】。?關註後，拉你進【原始碼圈】微信群和【肥朝】搞基嗨皮。
友情提示：歡迎關註公眾號【芋道原始碼】。?關註後，拉你進【原始碼圈】微信群和【肥朝】搞基嗨皮。
友情提示：歡迎關註公眾號【芋道原始碼】。?關註後，拉你進【原始碼圈】微信群和【肥朝】搞基嗨皮。
前言
上週的dubbo原始碼解析-遠端暴露中講解了遠端暴露的大致過程,但是期間大家也發現了,這個過程涉及到了很多分支,比如 netty, zookeeper.當然設計樣式就不說了,這個貫穿在整個框架的始終.
但是我也認為,好的原始碼分析類文章,應該是先整體,後枝幹的,就比如如果我們一開始學習 HTML的時候先把各個標簽過一遍,估計可能很多人還沒入門就放棄了,比較友好的方式我認為應該是不管三七二十一,先做出一個小的demo,再逐個細節分析.因此我的每週一篇dubbo原始碼解析也嘗試使用該種 先主體,後枝幹的方式.由於 dubbo涉及到的知識體系(包括一些拓展)比較龐大,所以根據我的估算,以目前一週一篇的形式,到明年的更新不完的.所以可以大膽的關註肥朝的個人簡書.
由於本篇涉及到 dubbo和 zookeeper的一些知識上的互動,建議簡單跑一個 zookeeper的demo,我也梳理了一下 zookeeper需要掌握的基本入門知識點.大致如下,如果有興趣可以留言,後面會陸續更新
插播面試題
-
一般選擇什麼註冊中心,還有別的選擇嗎?
-
dubbo中zookeeper做註冊中心,如果註冊中心叢集都掛掉,那釋出者和訂閱者還能通訊嗎?(面試高頻題)
-
專案中有使用過多執行緒嗎?有的話講講你在哪裡用到了多執行緒?(面試高頻題)
-
zookeeper的java客戶端你使用過哪些?
友情提示
由於 服務暴露這一節的內容幾乎是環環相扣的,比如本章節是在上一章節dubbo原始碼解析-遠端暴露中的一個分支的細化講解.因此不建議跳躍性閱讀.建議閱讀本篇前先閱讀以下幾篇
-
dubbo原始碼解析-服務暴露原理
-
dubbo原始碼解析-本地暴露
-
dubbo原始碼解析-遠端暴露
前期預熱
今天我們要講的其實就是一行程式碼.也就是
getRegistry(originInvoker);
的過程.這行程式碼在上週的 遠端暴露中有提到,細心的你應該有些印象.
過程並不複雜,我用一個時序圖來理一下思緒
看到這個時序圖是不是感覺太簡單了,就三個步驟?優秀的原始碼都涉及到了大量的設計樣式以及面向物件的思想,這裡就不得不提一下我之前反覆強調的看 繼承體系圖了.其實在 newZookeeperRegistry()的時候,做了很多事,其中就包含了前面提到的高頻題.同時看原始碼也很考驗一個人的基礎是否扎實,俗話說得好,基礎不牢地動山搖.比如下麵我給兩個非常簡單的例子,你輸出看看,是否和自己想的一樣?
class SubClass extends SuperClass
{
public String name = "SubClass";
}
class SuperClass
{
public String name = "SuperClass";
}
public class Demo
{
public static void main(String[] args)
{
SuperClass clz = new SubClass();
//你覺得這裡輸出什麼?
System.out.println(clz.name);
}
}
public class CodeBlockDemo
{
{
System.out.println("初始化程式碼");
}
CodeBlockDemo()
{
System.out.println("建構式");
}
static
{
System.out.println("靜態程式碼塊");
}
//執行後輸出結果?
public static void main(String[] args)
{
{
int a = 10;
//10
System.out.println("區域性程式碼塊");
}
new CodeBlockDemo();
new CodeBlockDemo();
new CodeBlockDemo();
}
}
直入主題
從時序圖我們從第一個關鍵詞 getRegistry開始
如果看過上一篇的同學此時對這個抽象方法就很熟悉了,這裡又用到了設計樣式中的 鉤子方法
那麼他會呼叫自己的哪個子類呢?我們來看一下繼承體系圖
看到這裡可能有些同學就有疑惑了, Zookeeper我認識, Dubbo我也認識,但是 Multicast我就不認識了.那麼我們回到第一個面試題
一般選擇什麼註冊中心,還有別的選擇嗎?
這個問題其實我們翻看一下檔案,答案迎刃而解.
繼續往下走,根據時序圖,我們似乎看到了最後一個步驟,那是不是說明本篇接近了尾聲?不,還有三個面試題還沒解答,現在戰鬥才剛剛開始
我們來看看 ZookeeperRegistry的繼承體系圖
根據繼承體系圖,我們打好斷點往下走,現在我們引出第二個面試題,也是dubbo面試中的高頻題
dubbo中zookeeper做註冊中心,如果註冊中心叢集都掛掉,那釋出者和訂閱者還能通訊嗎?
答案是可以的,為什麼呢?我們看下麵三個圖,我們看到zookeeper的資訊會快取到本地作為一個快取檔案,並且轉換成 properties物件方便使用.
專案中有使用過多執行緒嗎?有的話講講你在哪裡用到了多執行緒?
這裡的做法是,建立執行緒池,定時的檢測並連線註冊中心,如果失敗了就重連.其實也就是一個 定時任務執行器.可能你做了兩三年java還沒真正在專案中開啟過執行緒,問到這個問題時菊花一緊,但是 定時任務執行器這種需求在專案中還是很常見的,你可以參考這個例子,把你們的定時任務場景和這裡的多執行緒用法套在一起,雲淡風輕的這麼一回答,還不是棒棒噠?
繼續往下走,我們來看第四個面試題
zookeeper的java客戶端你使用過哪些?
我們看一下 zookeeperTransporter的類圖和繼承體系圖
從繼承體系圖我們就只有,zookeeper是支援 ZkClient和 Curator兩種java客戶端(其實就類似jedis是redis的java客戶端一樣),同時 @SPI("zkclient")這裡就可以看出它預設是用 ZkClient的(原因關註肥朝,後續講解)
繼續往下走
這裡是 ZkClient的api,主要也就是一些監聽和處理,我們在 dubbo拓展專題-zookeeper再細說
本篇開頭也說了,本篇講的就是一行程式碼
getRegistry(originInvoker);
看到這裡 returnregistry,也就預告了本篇接近了尾聲
寫在末尾
寫到這裡是時候已經是星期天了的凌晨,當你決心堅持去做一件事的時候,才會註意到,期間會遇到各種阻力和意外.這是dubbo原始碼解析的第九篇,也就是堅持周更超過兩個月.正如前面所說,戰鬥才剛剛開始.我們下週見.鑒於本人才疏學淺,不對的地方還望斧正,也歡迎關註我的簡書,名稱為 肥朝
