dubbo原始碼愫讀（1）dubbo總體架構
1、微服務簡介
微服務是一種用於構建應用的架構方案。微服務架構有別於更為傳統的單體式方案，可將應用拆分成多個核心功能。每個功能都被稱為一項服務，可以單獨構建和部署，這意味著各項服務在工作（和出現故障）時不會相互影響。
1.1、微服務架構的優勢
微服務可通過分散式部署，大幅提升團隊和日常工作效率。還可以並行開發多個微服務。這意味著更多開發人員可以同時開發同一個應用，進而縮短開發所需的時間。
- 加速做好面市準備：
由於開發週期縮短，微服務架構有助於實現更加敏捷的部署和更新。 - 高度可擴充套件：
隨著某些服務的不斷擴充套件，您可以跨多個伺服器和基礎架構進行部署，充分滿足自身需求。 - 出色的彈性：
只要確保正確構建，這些獨立的服務就不會彼此影響。這意味著，一個服務出現故障不會導致整個應用下線，這一點與單體式應用模型不同。 - 易於部署：
相對於傳統的單體式應用，基於微服務的應用更加現代化而小巧，所以您無需為它們的部署操心。雖然對部署時的協作要求更高，但之後能獲得巨大回報。 - 易於訪問：
由於大型應用被拆分成了多個小型服務，所以開發人員能夠更加輕鬆地理解、更新和增強這些服務，從而縮短開發週期（尤其是在搭配使用敏捷的開發方法時）。 - 更加開放：
由於使用了多語言 API，所以開發人員可以根據需要實現的功能，自由選用最適合的語言和技術。
1.2、所面臨的挑戰
複雜性和效率問題是基於微服務的架構所面臨的挑戰。
- 構建： 你必須花時間明確各個服務間的依賴關係。要知道，由於存在這些依賴關係，當您完成一個構建時，可能會觸發多個其他構建。您還需要考慮微服務對於資料的影響。
- 測試： 整合測試和端到端測試可能會前所未有的難以實施，但卻更加重要。根據您在架構相互支撐的服務時所採用的不同方式，架構中的一個部分出現故障，很可能會導致其他部分也隨之出現故障。
- 版本管理： 在更新到新版本時，請記住：向後相容性可能會因更新操作而失效。要解決這一問題，您可以利用條件邏輯來進行構建，但是構建會變得繁複、難以控制且快速。或者，您也可以為不同的客戶端維護多個活躍版本，但是相關的維護和管理工作會變得更加龐雜。
- 部署： 沒錯，這也是一大挑戰，至少是首次設定時所要面臨的一大挑戰。為了簡化部署，您必須先大量投資於自動化，因為人工部署無法應對微服務的複雜性。請好好思考您要以何種方式以及怎樣的順序來部署各項服務。
- 日誌記錄： 使用分散式系統時，您需要利用集中式日誌將所有相關資訊集中到一處。否則，積累的日誌數量將讓您難以招架。
- 監控： 您必須通過一個集中式檢視來了解整個系統的情況，以便找出問題的根源。
- 除錯： 無法進行遠端除錯，因為這種方式無法涵蓋數十個或數百個服務。不幸的是，關於應該如何進行除錯，目前還沒有標準答案。
- 連線： 請考慮使用服務探索功能，無論是集中式的還是整合式。
2、dubbo架構設計
2.1、dubbo結構圖
dubbo結構圖.png
節點角色說明：
-
Consumer（服務消費者）：
服務消費者啟動後，會從註冊中心查詢服務提供者列表，並tcp連線到提供者伺服器；當應用呼叫RPC介面時，服務消費者通過一定的路由演算法，選擇某個服務提供者進行通訊，呼叫對應介面獲取資料。同時，消費者會向註冊中心訂閱需要的服務，當訂閱的服務有更新時，註冊中心將通知對應的消費者。消費者也會定時向監控中心報告狀態及統計資料等資訊，以備監控中心進行監控統計等。
-
Provider（服務提供者）：
服務提供者啟動之後，會將提供的服務資訊註冊到註冊中心；其同時接受消費者的服務請求並定時將狀態及統計資訊同步到監控中心。
-
Container（服務容器）：
服務執行容器。
-
Register（註冊中心）：
服務提供者先啟動start，然後註冊register服務。消費訂閱subscribe服務，如果沒有訂閱到自己想獲得的服務，它會不斷的嘗試訂閱。新的服務註冊到註冊中心以後，註冊中心會將這些服務通過notify到消費者。
-
Monitor（監控中心）：
這是一個監控，圖中虛線表明Consumer 和Provider通過非同步的方式傳送訊息至Monitor，Consumer和Provider會將資訊存放在本地磁碟，平均1min會發送一次資訊。Monitor在整個架構中是可選的（圖中的虛線並不是可選的意思），Monitor功能需要單獨配置，不配置或者配置以後，Monitor掛掉並不會影響服務的呼叫。
呼叫關係說明：
- 0： 服務容器負責啟動，載入，執行服務提供者。
- 1： 服務提供者在啟動時，向註冊中心註冊自己提供的服務。
- 2： 服務消費者在啟動時，向註冊中心訂閱自己所需的服務。
- 3： 註冊中心返回服務提供者地址列表給消費者，如果有變更，註冊中心將基於長連線推送變更資料給消費者。
- 4： 服務消費者，從提供者地址列表中，基於軟負載均衡演算法，選一臺提供者進行呼叫，如果呼叫失敗，再選另一臺呼叫。
- 5： 服務消費者和提供者，在記憶體中累計呼叫次數和呼叫時間，定時每分鐘傳送一次統計資料到監控中心。
2.2、dubbo總體架構
dubbo總體架構圖.png
Dubbo框架設計一共劃分了10個層，最上面的Service層是留給實際想要使用Dubbo開發分散式服務的開發者實現業務邏輯的介面層。圖中左邊淡藍背景的為服務消費方使用的介面，右邊淡綠色背景的為服務提供方使用的介面， 位於中軸線上的為雙方都用到的介面。
下面，結合Dubbo官方文件，我們分別理解一下框架分層架構中，各個層次的設計要點：
- 服務介面層（Service）： 該層是與實際業務邏輯相關的，根據服務提供方和服務消費方的業務設計對應的介面和實現。
- 配置層（Config）： 對外配置介面，以ServiceConfig和ReferenceConfig為中心，可以直接new配置類，也可以通過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。Protocol是服務域，它是Invoker暴露和引用的主功能入口，它負責Invoker的生命週期管理。Invoker是實體域，它是Dubbo的核心模型，其它模型都向它靠擾，或轉換成它，它代表一個可執行體，可向它發起invoke呼叫，它有可能是一個本地的實現，也可能是一個遠端的實現，也可能一個叢集實現。
- 資訊交換層（Exchange）： 封裝請求響應模式，同步轉非同步，以Request和Response為中心，擴充套件介面為Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。
- 網路傳輸層（Transport）： 抽象mina和netty為統一介面，以Message為中心，擴充套件介面為Channel、Transporter、Client、Server和Codec。
- 資料序列化層（Serialize）： 可複用的一些工具，擴充套件介面為Serialization、 ObjectInput、ObjectOutput和ThreadPool。
根據官方提供的，對於上述各層之間關係的描述，如下所示：
- 在RPC中，Protocol是核心層，也就是隻要有Protocol + Invoker + Exporter就可以完成非透明的RPC呼叫，然後在Invoker的主過程上Filter攔截點。
- 圖中的Consumer和Provider是抽象概念，只是想讓看圖者更直觀的瞭解哪些類分屬於客戶端與伺服器端，不用Client和Server的原因是Dubbo在很多場景下都使用Provider、Consumer、Registry、Monitor劃分邏輯拓普節點，保持統一概念。
- 而Cluster是外圍概念，所以Cluster的目的是將多個Invoker偽裝成一個Invoker，這樣其它人只要關注Protocol層Invoker即可，加上Cluster或者去掉Cluster對其它層都不會造成影響，因為只有一個提供者時，是不需要Cluster的。
- Proxy層封裝了所有介面的透明化代理，而在其它層都以Invoker為中心，只有到了暴露給使用者使用時，才用Proxy將Invoker轉成介面，或將介面實現轉成Invoker，也就是去掉Proxy層RPC是可以Run的，只是不那麼透明，不那麼看起來像調本地服務一樣調遠端服務。
- 而Remoting實現是Dubbo協議的實現，如果你選擇RMI協議，整個Remoting都不會用上，Remoting內部再劃為Transport傳輸層和Exchange資訊交換層，Transport層只負責單向訊息傳輸，是對Mina、Netty、Grizzly的抽象，它也可以擴充套件UDP傳輸，而Exchange層是在傳輸層之上封裝了Request-Response語義。
- Registry和Monitor實際上不算一層，而是一個獨立的節點，只是為了全域性概覽，用層的方式畫在一起
2.3、dubbo服務呼叫流程
服務提供方與服務消費放之間呼叫關係：
呼叫關係.png
上圖中，藍色的表示與業務有互動，綠色的表示只對Dubbo內部互動。上述圖所描述的呼叫流程如下：
- 服務提供方釋出服務到服務註冊中心；
- 服務消費方從服務註冊中心訂閱服務；
- 服務消費方呼叫已經註冊的可用服務
將上面抽象的呼叫流程圖展開，詳細如圖所示：
抽象流程圖.png
註冊/登出服務：
服務的註冊與登出，是對服務提供方角色而言，那麼註冊服務與登出服務的時序圖，如圖所示：
註冊登出流程.png
服務訂閱/取消：
為了滿足應用系統的需求，服務消費方的可能需要從服務註冊中心訂閱指定的有服務提供方釋出的服務，在得到通知可以使用服務時，就可以直接呼叫服務。反過來，如果不需要某一個服務了，可以取消該服務。下面看一下對應的時序圖，如圖所示：
訂閱取消流程.png
3、其他說明
3.1、協議支援
Dubbo支援多種協議，如下所示：
- Dubbo協議
- Hessian協議
- HTTP協議
- RMI協議
- WebService協議
- Thrift協議
- Memcached協議
- Redis協議
在通訊過程中，不同的服務等級一般對應著不同的服務質量，那麼選擇合適的協議便是一件非常重要的事情。你可以根據你應用的建立來選擇。例如，使用RMI協議，一般會受到防火牆的限制，所以對於外部與內部進行通訊的場景，就不要使用RMI協議，而是基於HTTP協議或者Hessian協議。
3.2、dubbo模組結構及關係
dubbo模組結構.png
可以通過Dubbo的程式碼（使用Maven管理）組織，與上面的模組進行比較。
簡單說明各個包的情況：
- 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： 容器模組，是一個Standalone的容器，以簡單的Main載入Spring啟動，因為服務通常不需要Tomcat/JBoss等Web容器的特性，沒必要用Web容器去載入服務。