Dubbo架構圖
從架構圖可以看出，Consumer服務消費者，Provider服務提供者。Container服務容器。消費當然是invoke提供者了，invoke這條實線按照圖上的說明當然是同步的意思了。但是在實際調用過程中，Provider的位置對於Consumer來說是透明的，上一次調用服務的位置（IP地址）和下一次調用服務的位置，是不確定的。這個地方就需要使用註冊中心來實現軟負載。
Register
服務提供者先啓動start，然後註冊register服務。消費者訂閱subscribe服務，如果沒有訂閱到自己想獲得的服務，它會不斷的嘗試訂閱。新的服務註冊到註冊中心以後，註冊中心會將這些服務通過notify通知到消費者。
Monitor
這是一個監控，圖中虛線表明Consumer 和Provider通過異步的方式發送消息至Monitor，Consumer和Provider會將信息存放在本地磁盤，平均1min會發送一次信息。Monitor在整個架構中是可選的（圖中的虛線並不是可選的意思），Monitor功能需要單獨配置，不配置或者配置以後，Monitor掛掉並不會影響服務的調用。
Dubbo的執行流程
基本的工作流程和原理如下
- client一個線程調用遠程接口，生成一個唯一的ID（比如一段隨機字符串，UUID等），Dubbo是使用AtomicLong從0開始累計數字的
- 將打包的方法調用信息（如調用的接口名稱，方法名稱，參數值列表等），和處理結果的回調對象callback，全部封裝在一起，組成一個對象object
- 向專門存放調用信息的全局ConcurrentHashMap裏面put(ID, object)
- 將ID和打包的方法調用信息封裝成一對象connRequest，使用IoSession.write(connRequest)異步發送出去
- 當前線程再使用callback的get()方法試圖獲取遠程返回的結果，在get()內部，則使用synchronized獲取回調對象callback的鎖， 再先檢測是否已經獲取到結果，如果沒有，然後調用callback的wait()方法，釋放callback上的鎖，讓當前線程處於等待狀態。
- 服務端接收到請求並處理後，將結果（此結果中包含了前面的ID，即回傳）發送給客戶端，客戶端socket連接上專門監聽消息的線程收到消息，分析結果，取到ID，再從前面的ConcurrentHashMap裏面get(ID)，從而找到callback，將方法調用結果設置到callback對象裏。
- 監聽線程接着使用synchronized獲取回調對象callback的鎖（因爲前面調用過wait()，那個線程已釋放callback的鎖了），再notifyAll()，喚醒前面處於等待狀態的線程繼續執行（callback的get()方法繼續執行就能拿到調用結果了），至此，整個過程結束