一直被dubbo的spring相關配置搞得比較暈，dubbo作爲淘寶自己搞得東東，也沒有太多像樣的成系統的書籍資料，所以相關知識顯得比較零碎。趁機會把相關知識尤其是配置知識整理記錄一下，以供記憶。
Application層的配置
<dubbo:applicationname="dubbo-provider" />
--應用配置，用於配置當前應用信息，不管該應用是提供者還是消費者，這一層目前只知道name字段的配置，表示應用的名字，服務端和客戶端名字不同
Registry層的配置
<dubbo:registryprotocol="zookeeper" address="132.121.127.30:2181" client="curator"file="D:\\dubbo_cache.txt" register="true" />
--註冊中心配置，註冊與註冊中心相連接的相關信息，正常情況下說白了就是和zookeeper連接的相關信息，包括連接協議protocol="zookeeper"，zookeeper的ip：port, client默認是zkclient，至於curator和zkclient的區別後續還需進一步瞭解。File字段是持久化了dubbo服務提供者的ip：端口等相關信息，目的是爲了在註冊中心掛掉的情況下，消費者可以使用本地持久化的這份緩存文件去尋找服務提供者。Register爲false時表示服務提供者不註冊到註冊中心，默認是true。
Protocol層的配置
<dubbo:protocol name="dubbo"port="20880" dispatcher="all" threadpool="fixed"accesslog="D:\\dubbo.log" />
--協議配置，用於配置提供服務的協議信息，協議由提供方指定，消費方被動接受。（意思是消費端不需要這塊配置，服務提供方配就行），name="dubbo"協議一般用的就是dubbo協議，好像也支持其他協議。Port就是服務提供者的服務端口。dispatcher="all"表示所有的請求響應消息都派發到線程池中。threadpool="fixed"表示線程池是固定大小的，啓動時就建立線程。Accesslog字段是表示存儲消費者訪問提供者命令的文件。（通過該文件可以查詢到任意時刻消費者訪問提供者的相關命令）
事件處理線程說明
如果事件處理的邏輯能迅速完成，並且不會發起新的IO請求，比如只是在內存中記個標識，則直接在IO線程上處理更快，因爲減少了線程池調度。
但如果事件處理邏輯較慢，或者需要發起新的IO請求，比如需要查詢數據庫，則必須派發到線程池，否則IO線程阻塞，將導致不能接收其它請求。
如果用IO線程處理事件，又在事件處理過程中發起新的IO請求，比如在連接事件中發起登錄請求，會報“可能引發死鎖”異常，但不會真死鎖。
Dispatcher
all 所有消息都派發到線程池，包括請求，響應，連接事件，斷開事件，心跳等。
direct 所有消息都不派發到線程池，全部在IO線程上直接執行。
message 只有請求響應消息派發到線程池，其它連接斷開事件，心跳等消息，直接在IO線程上執行。
execution 只請求消息派發到線程池，不含響應，響應和其它連接斷開事件，心跳等消息，直接在IO線程上執行。
connection 在IO線程上，將連接斷開事件放入隊列，有序逐個執行，其它消息派發到線程池。
ThreadPool
fixed 固定大小線程池，啓動時建立線程，不關閉，一直持有。(缺省)
cached 緩存線程池，空閒一分鐘自動刪除，需要時重建。
limited 可伸縮線程池，但池中的線程數只會增長不會收縮。(爲避免收縮時突然來了大流量引起的性能問題)。
Service層的配置
<dubbo:serviceinterface="server.DubboProvider" ref="DubboProvider"executes="100" />
--服務配置，用於暴露一個服務，定義服務的元信息，一個服務可以用多個協議暴露，一個服務也可以註冊到多個註冊中心。Interface要配接口名（必須是接口，如果是實現類的話會報錯）。Ref配的是實現類的bean id，比如<bean id="DubboProvider"class="server.DubboProviderImpl" />，executes表示的是服務級別的最大併發執行數。如果想禁止消費者繞過註冊中心直接通過服務提供者的地址訪問服務，可以再服務提供者的配置那邊加上token項，比如token=”123456”,這樣一來消費者就得必須經過註冊中心才能得到token,才能訪問服務提供者，否則就報錯，這一層配置是服務提供者獨有的。
Reference層的配置
<dubbo:referenceid="DubboProvider" interface="server.DubboProvider"url="dubbo://192.168.1.103:20880/" />
--引用服務配置，用於創建一個遠程服務代理，一個引用可以指向多個註冊中心。其中interface要和提供者的service層的interface保持一致。Id是作爲java代碼getBean時的參數。如果要繞過註冊中心直接訪問服務提供者，則需要直接在這一層配置上要訪問的服務提供者的ip：端口，比如url="dubbo://192.168.1.103:20880/"。正常情況下是應該通過註冊中心去自動發現服務提供者的。比如則這一層配置是消費者獨有的。
--以上是最基本的dubbo服務提供方和消費方的spring配置。其中Application層的配置、Registry層的配置是服務提供方和消費方都要用到的，而Protocol層的配置、Service層的配置是服務提供方的獨有的，Reference層的配置是消費方獨有的。搞清楚這個大框架就基本能使用dubbo的基本xml配置。
除了上面所述那些，還有幾個相對少用到的配置層（見綠色內容）
<dubbo:service/> 服務配置，用於暴露一個服務，定義服務的元信息，一個服務可以用多個協議暴露，一個服務也可以註冊到多個註冊中心。
eg、<dubbo:serviceref="demoService"interface="com.unj.dubbotest.provider.DemoService" />
<dubbo:reference/> 引用服務配置，用於創建一個遠程服務代理，一個引用可以指向多個註冊中心。
eg、<dubbo:referenceid="demoService"interface="com.unj.dubbotest.provider.DemoService" />
<dubbo:protocol/> 協議配置，用於配置提供服務的協議信息，協議由提供方指定，消費方被動接受。
eg、<dubbo:protocolname="dubbo" port="20880" />
<dubbo:application/> 應用配置，用於配置當前應用信息，不管該應用是提供者還是消費者。
eg、<dubbo:applicationname="xixi_provider" />
<dubbo:application name="hehe_consumer" />
<dubbo:registry/> 註冊中心配置，用於配置連接註冊中心相關信息。
eg、<dubbo:registryaddress="zookeeper://192.168.2.249:2181" />
<dubbo:module/>模塊配置，用於配置當前模塊信息，可選。
<dubbo:monitor/>監控中心配置，用於配置連接監控中心相關信息，可選。
<dubbo:provider/>提供方的缺省值，當ProtocolConfig和ServiceConfig某屬性沒有配置時，採用此缺省值，可選。
<dubbo:consumer/>消費方缺省配置，當ReferenceConfig某屬性沒有配置時，採用此缺省值，可選。
<dubbo:method/>方法配置，用於ServiceConfig和ReferenceConfig指定方法級的配置信息。
<dubbo:argument/>用於指定方法參數配置。
使用dubbo需要代碼方面注意的一個地方：
Dubbo還有一個比較奇怪的地方，就是在代碼啓動服務提供方時，程序會自動結束退出而不是自動阻塞等待訪問，所以需要手工在服務提供方的中添加上阻塞線程的代碼，比如
synchronized (springContext) {
while(true){
try {
springContext.wait();
}catch (InterruptedException e) {
//TODO Auto-generated catch block
e.printStackTrace();
}
}
}
--這樣就能使主線程一直保持阻塞狀態（並且是無法喚醒），等待消費端的訪問。
而消費方就恰恰相反，服務調用完了程序也會一直阻塞不結束，所以也得手工去添加結束spring容器生命週期和程序強制退出的代碼，比如：
springContext.close();
System.exit(0);