工作流涉及到服務提供者（provider），註冊中心（registration），網路（network）和服務消費者（consumer）：
服務提供者在啟動的時候，會通過讀取一些配置將服務例項化。
proxy 封裝服務呼叫介面，方便呼叫者呼叫。客戶端獲取 proxy 時，可以像呼叫本地服務一樣，呼叫遠端服務。
proxy 在封裝時，需要呼叫 protocol 定義協議格式，例如：dubbo protocol。
將 proxy 封裝成 invoker，它是真實服務呼叫的例項。
將 invoker 轉化成 exporter，exporter 只是把 invoker 包裝了一層，是為了在註冊中心中暴露自己，方便消費者使用。
將包裝好的 exporter 註冊到註冊中心。
服務消費者建立好例項，會到服務註冊中心訂閱服務提供者的元資料。元資料報括服務 ip 和埠以及呼叫方式（proxy）。
消費者會通過獲取的 proxy 進行呼叫。通過服務提供方包裝過程可以知道，proxy 實際包裝了 invoker 實體，因此需要使用 invoker 進行呼叫。
在 invoker 呼叫之前，通過 directory 獲取服務提供者的 invoker 列表。在分布式的服務中有可能出現同乙個服務，分布在不同的節點上。
通過路由規則了解，服務需要從哪些節點獲取。
invoker 呼叫過程中，通過 cluster 進行容錯，如果遇到失敗策略進行重試。
呼叫中，由於多個服務可能會分布到不同的節點，就要通過 loadbalance 來實現負載均衡。
invoker 呼叫之前還需要經過 filter，它是乙個過濾鏈，用來處理上下文，限流和計數的工作。
生成過濾以後的 invoker。
用 client 進行資料傳輸。
codec 會根據 protocol 定義的協議，進行協議的構造。
構造完成的資料，通過序列化 serialization 傳輸給服務提供者。
request 已經到達了服務提供者，它會被分配到執行緒池（threadpool）中進行處理。
server 拿到請求以後查詢對應的 exporter（包含有 invoker）。
由於 export 也會被 filter 層層包裹
通過 filter 以後獲得 invoker
最後，對服務提供者實體進行呼叫。
zookeeper和dubbo互動
zookeeperregistry 在例項化時，呼叫父類建構函式。在父類建構函式中，會建立乙個定時任務，每隔5s執行retry( ) 方法。
在retry( ) 方法中，重試那些失敗的動作。重試的動作包括：
provider向zookeeper註冊自身的url，生成乙個臨時的znode
provider從dubbo容器中退出，停止提供rpc呼叫。也就是移除zookeeper內自身url對應的znode
consumer訂閱 " /dubbo/…service/providers" 目錄的子節點，生成childlistener
consumer從dubbo容器中退出，移除之前建立的childlistener
dubbo呼叫超時回滾 Dubbo服務呼叫超時
服務降級的發生，其實是由於消費者呼叫服務超時引起的，即從發出呼叫請求到獲取到提供者的響應結果這個時間超出了設定的時限。預設服務呼叫超時時限為1秒。可以在消費者端與提供者端設定超時時限。一 建立提供者工程06 provider timeout 1 建立工程 複製02 provider zk工程，並重命...
Dubbo服務暴露流程
本篇部落格，需要先看上篇 dubbo服務暴露流程 先看 dubbonamespacehandler類的 init方法，在定義屬性的時候有這樣一行 this registerbeandefinitionparser service new dubbobeandefinitionparser servi...
理解Dubbo的呼叫流程與Dubbo多協議解析
dubbo作為目前國內主流的微服務框架之一 一 dubbo的呼叫流程分析 dubbo本身主要支援兩種呼叫流程，包括直連提供者和基於註冊中心的呼叫 直連提供者一般都是在開發和測試環境下使用 我們將所有的配置和實現細節過濾，其實它就只是說明一件事，consumer明確知道provider的家庭住址，稍不...