一、Duboo基本概念解釋
Dubbo是一種分布式服務架構。 Webservice也是一種服務架構，但是webservice并不是分布式的服務架構，他需要結合F5實作負載均衡。是以，dubbo除了可以提供服務之外，還可以實作軟負載均衡。它還提供了兩個功能Monitor 監控中心和調用中心。這兩個是可選的，需要單獨配置。
Dubbo的計數架構圖如下：
我們解釋以下這個架構圖：
Consumer服務消費者，Provider服務提供者。Container服務容器。消費當然是invoke提供者了，invoke這條實線按照圖上的說明當然同步的意思了，多說一句，在實際調用過程中，Provider的位置對于Consumer來說是透明的，上一次調用服務的位置（IP位址）和下一次調用服務的位置，是不确定的。這個地方就是實作了軟負載。
服務提供者先啟動start，然後注冊register服務。
消費訂閱subscribe服務，如果沒有訂閱到自己想獲得的服務，它會不斷的嘗試訂閱。新的服務注冊到注冊中心以後，注冊中心會将這些服務通過notify到消費者。
Monitor這是一個監控，圖中虛線表明Consumer 和Provider通過異步的方式發送消息至Monitor，Consumer和Provider會将資訊存放在本地磁盤，平均1min會發送一次資訊。Monitor在整個架構中是可選的（圖中的虛線并不是可選的意思），Monitor功能需要單獨配置，不配置或者配置以後，Monitor挂掉并不會影響服務的調用。
二、dubbo原理
本篇部落格的内容總體上比較抽象，如果一個想馬上使用dubbo的同學來說，讀這篇部落格效果不太好，本篇部落格沒有寫怎麼使用、配置dubbo，接下來，我再令寫一篇dubbo入門包含demo的部落格。
I、初始化過程細節：
上圖中的第一步start，就是将服務裝載容器中，然後準備注冊服務。和Spring中啟動過程類似，spring啟動時，将bean裝載進容器中的時候，首先要解析bean。是以dubbo也是先讀配置檔案解析服務。
解析服務：
1）、基于dubbo.jar内的Meta-inf/spring.handlers配置，spring在遇到dubbo名稱空間時，會回調DubboNamespaceHandler類。
2）、所有的dubbo标簽，都統一用DubboBeanDefinitionParser進行解析，基于一對一屬性映射，将XML标簽解析為Bean對象。
源碼截圖：
在ServiceConfig.export 或者ReferenceConfig.get 初始化時，将Bean對象轉會為url格式，将是以Bean屬性轉成url的參數。
然後将URL傳給Protocol擴充點，基于擴充點的Adaptive機制，根據URL的協定頭，進行不同協定的服務暴露和引用。
暴露服務：
a、 隻暴露服務端口
在沒有使用注冊中心的情況，這種情況一般适用在開發環境下，服務的調用這和提供在同一個IP上，隻需要打開服務的端口即可。
即，當配置 or
ServiceConfig解析出的URL的格式為：
Dubbo：//service-host/com.xxx.TxxService?version=1.0.0
基于擴充點的Adaptiver機制，通過URL的“dubbo：//”協定頭識别，直接調用DubboProtocol的export（）方法，打開服務端口。
b、向注冊中心暴露服務：
和上一種的差別：需要将服務的IP和端口一同暴露給注冊中心。
ServiceConfig解析出的url格式為：
registry://registry-host/com.alibaba.dubbo.registry.RegistryService?export=URL.encode(“dubbo://service-host/com.xxx.TxxService?version=1.0.0”)
基于擴充點的Adaptive機制，通過URL的“registry：//”協定頭識别，調用RegistryProtocol的export方法，将export參數中的提供者URL先注冊到注冊中心，再重新傳給Protocol擴充點進行暴露：
Dubbo：//service-host/com.xxx.TxxService?version=1.0.0
引用服務：
a、直接引用服務：
在沒有注冊中心的，直連提供者情況下，
ReferenceConfig解析出的URL格式為：
基于擴充點的Adaptive機制，通過url的“dubbo：//”協定頭識别，直接調用DubboProtocol的refer方法，傳回提供者引用。
b、從注冊中心發現引用服務：
此時，ReferenceConfig解析出的URL的格式為：
registry://registry-host/com.alibaba.dubbo.registry.RegistryService?refer=URL.encode(“consumer://consumer-host/com.foo.FooService?version=1.0.0”)
基于擴充點的Apaptive機制，通過URL的“registry：//”協定頭識别，就會調用RegistryProtocol的refer方法，基于refer參數總的條件，查詢提供者URL，如：
基于擴充點的Adaptive機制，通過提供者URL的“dubbo：//”協定頭識别，就會調用DubboProtocol的refer（）方法，得到提供者引用。
然後RegistryProtocol将多個提供者引用，通過Cluster擴充點，僞裝成單個提供這引用傳回。
三、遠端調用細節：
服務提供者暴露一個服務的詳細過程：
上圖是服務提供者暴露服務的主過程：
首先ServiceConfig類拿到對外提供服務的實際類ref，然後将ProxyFactory類的getInvoker方法使用ref生成一個AbstractProxyInvoker執行個體，到這一步就完成具體服務到invoker的轉化。接下來就是Invoker轉換到Exporter的過程。
Dubbo處理服務暴露的關鍵就在Invoker轉換到Exporter的過程，下面我們以Dubbo和rmi這兩種典型協定的實作來進行說明：
Dubbo的實作：
Dubbo協定的Invoker轉為Exporter發生在DubboProtocol類的export方法，它主要是打開socket偵聽服務，并接收用戶端發來的各種請求，通訊細節由dubbo自己實作。
Rmi的實作：
RMI協定的Invoker轉為Exporter發生在RmiProtocol類的export方法，他通過Spring或Dubbo或JDK來實作服務，通訊細節由JDK底層來實作。
服務消費者消費一個服務的詳細過程
上圖是服務消費的主過程：
首先ReferenceConfig類的init方法調用Protocol的refer方法生成Invoker執行個體。接下來把Invoker轉為用戶端需要的接口