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()方法繼續執行就能拿到調用結果了），至此，整個過程結束