dubbo是阿里下面的乙個開源分布式服務管理框架。它的產生是因為分布式的產生而產生的。下面將幾點分享一下我對dubbo的初步認識。通過dubbo的官方文件可以了解一下怎麼使用以及基本的設計思想。下面分享一下我對dubbo的理解，可能其中存在誤導，還望指正。
一、dubbo的第一感受
當我看到上面這張，我一直在回憶我之前的開發經歷。這張圖很好的總結了j2ee發展至今的整個架構變更歷程。再來一張圖：
看到這個圖，讓我想起我大學時候接觸的服務註冊與發現，當時的服務是web service服務，服務提供方是通過axis2(當然也可以用cxf，關於cxf可以看看@黃勇的web service 那點事兒 —— 使用 cxf 開發 soap 服務這裡面有對cxf的詳細介紹)，服務註冊和發現是通過juddi來實現的。當時是將web service服務全部註冊到juddi，然後呼叫服務，通過juddi提供的發現服務介面，查詢服務，發現服務介面，可以分析服務的服務質量來給出最好的服務（當然，這種情況下同一種服務，有多個提供者）。瞬間讓我懷念起大學的時代。所以看到這張圖讓我有一種很熟悉的感覺，於是也瞬間理解了這張圖的意思。
這張圖的大致意思可以理解為：
註冊中心的職責：
(1)負責接受提供者服務註冊的請求
(2)負責將消費者訂閱的服務位址返回給消費者
(3)負責服務變更了，通知消費者
(4)管理註冊中心內部的服務
消費者：這將自己需要的服務，想註冊中心發起訂閱，以及當服務存在變更，進行調整。
服務提供者：將自己的服務發布到註冊中心，以及提供具體服務給消費者。
監控中心：負責監聽服務的請求次數以及處理時間，方便服務的治理。
上面是我第一次看到dubbo的感覺。關於如何使用，以及怎麼使用，我這裡就不做過多的介紹，相信大家去看看官方文件都能理解，裡面講的已經非常清楚了。
二、dubbo初步深入
擴充套件點是dubbo的核心，而擴充套件點的核心則是extensionloader，這個類有點類似classloader，但是extensionloader是載入dubbo的擴充套件點的。下面列出extensionloader幾個重要的屬性結構。
public class extensionloader
extension_loaders屬性是乙個static final的，那麼說明應該是乙個常量，這個就是用來裝載dubbo的所有擴充套件點的extensionloader，在dubbo中，每種型別的擴充套件點都會有乙個與其對應的extensionloader，類似jvm中每個class都會有乙個classloader,每個extensionloader會包含多個該擴充套件點的實現，類似乙個classloader可以載入多個具體的類，但是不同的extensionloader之間是隔離的，這點也和classloader類似。那麼理解dubbo的extensionloader可以拿classloader來進行模擬，這樣會加快自己對它的理解。
2、另乙個常量屬性是extension_instances，他是乙個具體擴充套件類的實體，用於快取，防止由於擴充套件點比較重，導致會浪費沒必要的資源，所以在實現擴充套件點的時候，一定要確保擴充套件點可單例化，否則可能會出現問題。
3、另乙個重要的屬性是type，這裡的type一般是介面，用於制定擴充套件點的型別，因為dubbo的擴充套件點申明是spi的方式，所以某乙個型別擴充套件點，就需要申明乙個擴充套件點介面。比如extensionfactory擴充套件點申明如下：
@spi
public inte***ce extensionfactory
meta-inf/services/,meta-inf/dubbo/,meta-inf/dubbo/internal/)下面查詢type.getname的檔案，裡面的內容格式是extendname=classfullname,所以說type是告訴dubbo擴充套件點的型別，以及查詢該型別擴充套件點的方式。
4、擴充套件點相互依賴注入，dubbo通過extensionfactory來解決，比如springextensionfactory和spiextensionfactory,不同擴充套件點之間肯定存在依賴，那麼其擴充套件點從**獲取，就全部交給extensionfactory來實現，通過上面extensionfactory**可以了解，要獲取某個個具體的擴充套件點實現需要知道兩個引數，第乙個是擴充套件點型別，用於得到是哪個型別的擴充套件點，第二個是該擴充套件實現的名稱，用於在某一型別的擴充套件中找到對應的實現。注意：在dubbo中extensionfactory也被當作是乙個擴充套件，那麼就更說明在dubbo中無處不是擴充套件，另乙個注意點是：只有extensionfactory擴充套件的extensionloader的objectfactory是null，其他的擴充套件的都必須有乙個extensionfactory實現賦值給objectfactory屬性。通過下面**可以得知：
private extensionloader(class> type)
extensionloader.getextensionloader(extensionfactory.class)之後，不是直接返回某個擴充套件點，而是呼叫getadaptiveextension來獲取乙個擴充套件的介面卡，這是為什麼呢？因為乙個擴充套件點有多個具體擴充套件的實現，那麼直接通過extensionloader直接返回乙個擴充套件是不可靠的，需要乙個介面卡來根據實際情況返回具體的擴充套件實現。所以這裡就有了cachedadaptiveinstance屬性的存在，dubbo裡面的每個擴充套件的extensionloader都有乙個cachedadaptiveinstance，這個屬性的型別必須實現extensionloader.type介面，這就是設計模式中的介面卡模式。比如extensionfactory擴充套件點就有adaptiveextensionfactory介面卡。擴充套件點的介面卡可以是自己通過@adaptive，也可以不提供實現，由dubbo通過動態生成adaptive來提供乙個介面卡類。此處需要注意：adaptive也是擴充套件點的某個實現，下面例舉出extensionfactory擴充套件點的介面卡：
@adaptive
public class adaptiveextensionfactory implements extensionfactory
factories = collections.unmodifiablelist(list);
}public t getextension(classtype, string name)
}return null;
}}
cachedclasses,這個就是儲存當前extensionloader有哪些擴充套件點實現，從而可以例項化出某個具體的擴充套件點實體，cachedclasses宣告為holder>>型別，其實可以理解為是map>型別，map的key是在type.getname檔案中的=之前的內容，value這是這個擴充套件點實現的類物件了。
三、總結
通過上面分析，已經知道了dubbo可以做什麼，以及dubbo的擴充套件點實現有了基本的了解。那麼總結一下dubbo擴充套件點幾個要點
1、乙個擴充套件點型別一定是乙個介面
2、乙個擴充套件點一定對應乙個extensionloader
3、乙個extensionloader一定有乙個adapter
4、乙個擴充套件點可以有多個實現，並且都是用乙個extensionloader進行載入
5、乙個extensionloader（除去extensionfactory擴充套件）都要有乙個extensionfactory
初識分布式服務管理框架 Dubbo
dubbo是阿里下面的乙個開源分布式服務管理框架。它的產生是因為分布式的產生而產生的。下面將幾點分享一下我對dubbo的初步認識。通過dubbo的官方文件可以了解一下怎麼使用以及基本的設計思想。下面分享一下我對dubbo的理解，可能其中存在誤導，還望指正。一 dubbo的第一感受 當我看到上面這張，...
初識分布式服務框架dubbo
dubbo是乙個分布式服務框架，以及soa治理方案。其功能主要包括 高效能nio通訊及多協議整合，服務動態定址與路由，軟負載均衡與容錯，依賴分析與降級等。dubbo底層是tcp協議的netty nio spring boot底層是http協議 dubbo的七大標籤 config 配置層，對外配置介面...
分布式事務框架 seata初識
事務,在資料庫中指的是運算元據庫的最小單位,往大了看,事務是應用程式中一系列嚴密的操作，所有操作必須成功完成，否則在每個操作中所作的所有更改都會被撤消。那為什麼會有分布式事務呢?單機事務是通過將操作限制在乙個會話內通過資料庫本身的鎖以及日誌來實現acid.因為引入了分布式架構,所以事務的參與者 支援...