出處：dubbo入門(3)-架構原理
在之前的兩篇文章中，我們了解了有關分布式服務的基本概念和簡單的使用。現在來了解一下dubbo是如何提供這些功能的、如何運作的，以及整個框架的層次結構。
本文參考自dubbo架構設計詳解及dubbo官方使用者手冊
首先要了解dubbo提供的三大核心功能：
通訊提供多種對nio框架的抽象方式，給不同服務間的互相通訊及呼叫提供多種方式。包括同步、非同步、請求與響應等模型。
服務治理
維護服務之間的呼叫關係，並且提供服務容錯、負載均衡、動態配置等功能。使得開發者能夠實時了解服務整體的運**況。
註冊中心
提供服務註冊中心，使得服務能夠動態的新增、刪除並實時更新落地到消費方。
解釋一下各個節點所扮演的角色：
接著需要了解整體的呼叫關係和流程：
服務提供者在啟動時，向註冊中心註冊自己的服務。而服務的消費者在啟動時，在註冊中心中訂閱自己所需的服務。
註冊中心返回服務提供者位址列表給消費者，如果有變更，註冊中心將基於長連線推送變更資料給消費者。
服務消費者，從提供者位址列表中，基於軟負載均衡演算法，選一台提供者進行呼叫，如果呼叫失敗，再選另一台呼叫。
服務消費者和提供者，在記憶體中累計呼叫次數和呼叫時間，定時每分鐘傳送一次統計資料到監控中心。
上述的節點架構，給dubbo帶來了幾個非常強大的特性，也是dubbo的優勢所在：
所有的節點之間都是連通的，並且通過優化降低網路呼叫的消耗。
體現為：
即便服務中的某些節點無法正常工作，系統整體不會崩潰，而是通過多種容錯策略盡可能降低損失。
體現為：
當服務的規模需要調整時，不必暫停服務重新部署，而是可以動態切換，體現為：
當服務集群進一步增大，可能需要過渡到流動計算架構。但dubbo本身的服務結構不會為公升級提供阻力。
dubbo框架設計一共劃分了10個層，而最上面的service層是留給實際想要使用dubbo開發分布式服務的開發者實現業務邏輯的介面層。圖中左邊淡藍背景的為服務消費方使用的介面，右邊淡綠色背景的為服務提供方使用的介面， 位於中軸線上的為雙方都用到的介面。
下面簡要說明一下各層的作用（由於我還沒讀過原始碼，所以只是參考文件得出的個人理解）
服務介面層(service)
業務邏輯實現的地方，也是使用框架的開發者真正編寫**的地方
配置層(config)
配置整體執行引數的地方。
服務**層(proxy)
介面呼叫透明化**，將invoker轉化成使用者直接呼叫的介面。沒有這層依然可以實現rpc，但是需要使用者手動組建invoker，不能實現透明化呼叫。
服務註冊層(registry)
封裝服務位址的註冊和發現功能，如果沒有服務註冊層，則需要服務提供者自己直接暴露服務呼叫位址。
集群層(cluster)
封裝多個提供者的路由並提供負載均衡，橋接註冊中心。實現多個服務提供方集成為乙個服務提供方的對映。
監控層(monitor)
檢測rpc的呼叫次數和呼叫情況。
遠端呼叫層(protocol)
核心層，封裝rpc呼叫。protocol負責管理invoker的生命週期。而invoker是dubbo的核心模型，代表乙個可執行體，所有的呼叫都基於invoker，無論是本地或是遠端呼叫，還是集群呼叫。
資訊交換層(exchange)
封裝各種通訊模式：請求-響應、同步轉非同步等。
網路傳輸層(transport)
抽象mina和netty為統一介面，提供基礎nio的能力。
資料序列化層(serialize)
提供一些基本的可復用的工具。
基於下圖分析在rpc層服務消費者與服務提供者之間的排程關係。
如我們之前總結的，主要分為3步：
服務提供方發布服務到服務註冊中心
服務消費方從註冊中心訂閱服務
服務呼叫方呼叫已訂閱的服務
dubbo本身的結構其實並不複雜，而且分層清晰。
了解dubbo的架構，有助於理解分布式系統的設計思路，並且更容易上手。
後續也會從原始碼角度分析dubbo系統的實現。
在之前的兩篇文章中，我們了解了有關分布式服務的基本概念和簡單的使用。現在來了解一下dubbo是如何提供這些功能的、如何運作的，以及整個框架的層次結構。
本文參考自dubbo架構設計詳解及dubbo官方使用者手冊
首先要了解dubbo提供的三大核心功能：
通訊提供多種對nio框架的抽象方式，給不同服務間的互相通訊及呼叫提供多種方式。包括同步、非同步、請求與響應等模型。
服務治理
維護服務之間的呼叫關係，並且提供服務容錯、負載均衡、動態配置等功能。使得開發者能夠實時了解服務整體的運**況。
註冊中心
提供服務註冊中心，使得服務能夠動態的新增、刪除並實時更新落地到消費方。
解釋一下各個節點所扮演的角色：
接著需要了解整體的呼叫關係和流程：
服務提供者在啟動時，向註冊中心註冊自己的服務。而服務的消費者在啟動時，在註冊中心中訂閱自己所需的服務。
註冊中心返回服務提供者位址列表給消費者，如果有變更，註冊中心將基於長連線推送變更資料給消費者。
服務消費者，從提供者位址列表中，基於軟負載均衡演算法，選一台提供者進行呼叫，如果呼叫失敗，再選另一台呼叫。
服務消費者和提供者，在記憶體中累計呼叫次數和呼叫時間，定時每分鐘傳送一次統計資料到監控中心。
上述的節點架構，給dubbo帶來了幾個非常強大的特性，也是dubbo的優勢所在：
所有的節點之間都是連通的，並且通過優化降低網路呼叫的消耗。
體現為：
即便服務中的某些節點無法正常工作，系統整體不會崩潰，而是通過多種容錯策略盡可能降低損失。
體現為：
當服務的規模需要調整時，不必暫停服務重新部署，而是可以動態切換，體現為：
當服務集群進一步增大，可能需要過渡到流動計算架構。但dubbo本身的服務結構不會為公升級提供阻力。
dubbo框架設計一共劃分了10個層，而最上面的service層是留給實際想要使用dubbo開發分布式服務的開發者實現業務邏輯的介面層。圖中左邊淡藍背景的為服務消費方使用的介面，右邊淡綠色背景的為服務提供方使用的介面， 位於中軸線上的為雙方都用到的介面。
下面簡要說明一下各層的作用（由於我還沒讀過原始碼，所以只是參考文件得出的個人理解）
服務介面層(service)
業務邏輯實現的地方，也是使用框架的開發者真正編寫**的地方
配置層(config)
配置整體執行引數的地方。
服務**層(proxy)
介面呼叫透明化**，將invoker轉化成使用者直接呼叫的介面。沒有這層依然可以實現rpc，但是需要使用者手動組建invoker，不能實現透明化呼叫。
服務註冊層(registry)
封裝服務位址的註冊和發現功能，如果沒有服務註冊層，則需要服務提供者自己直接暴露服務呼叫位址。
集群層(cluster)
封裝多個提供者的路由並提供負載均衡，橋接註冊中心。實現多個服務提供方集成為乙個服務提供方的對映。
監控層(monitor)
檢測rpc的呼叫次數和呼叫情況。
遠端呼叫層(protocol)
核心層，封裝rpc呼叫。protocol負責管理invoker的生命週期。而invoker是dubbo的核心模型，代表乙個可執行體，所有的呼叫都基於invoker，無論是本地或是遠端呼叫，還是集群呼叫。
資訊交換層(exchange)
封裝各種通訊模式：請求-響應、同步轉非同步等。
網路傳輸層(transport)
抽象mina和netty為統一介面，提供基礎nio的能力。
資料序列化層(serialize)
提供一些基本的可復用的工具。
基於下圖分析在rpc層服務消費者與服務提供者之間的排程關係。
如我們之前總結的，主要分為3步：
服務提供方發布服務到服務註冊中心
服務消費方從註冊中心訂閱服務
服務呼叫方呼叫已訂閱的服務
dubbo本身的結構其實並不複雜，而且分層清晰。
了解dubbo的架構，有助於理解分布式系統的設計思路，並且更容易上手。
後續也會從原始碼角度分析dubbo系統的實現。
Dubbo實踐（二）架構
節點角色說明 節點 角色說明 provider 暴露服務的服務提供方 consumer 呼叫遠端服務的服務消費方 registry 服務註冊與發現的註冊中心 monitor 統計服務的呼叫次數和呼叫時間的監控中心 container 服務執行容器 呼叫關係說明 服務容器負責啟動，載入，執行服務提供者...
Android OkHttp3架構分析
在okhttp3中，其靈活性很大程度上體現在，可以intercept其任意乙個環節，而這個優勢便是okhttp3整個請求響應架構體系的精髓所在 okhttp 中的對所有的任務採用namedrunnable，約束每個執行單元給出對應的業務名稱，以便於執行緒維護。1.非同步請求執行緒池 okhttp d...
Springmvc入門基礎 二 架構詳解
架構流程文字說明 使用者傳送請求至前端控制器dispatcherservlet dispatcherservlet 處理器對映器根據請求url找到具體的處理器，生成處理器物件及處理器 如果有則生成 一併返回給dispatcherservlet。dispatcherservlet 通過handlera...