?
前些天發現了一個巨牛的人工智能學習網站，通俗易懂，風趣幽默，忍不住分享一下給大家。點擊跳轉到教程。
一、dubbo常用配置
<dubbo:service/> 服務配置，用于暴露一個服務，定義服務的元信息，一個服務可以用多個協議暴露，一個服務也可以注冊到多個注冊中心。
eg、<dubbo:service ref="demoService" interface="com.unj.dubbotest.provider.DemoService" /><dubbo:reference/> 引用服務配置，用于創建一個遠程服務代理，一個引用可以指向多個注冊中心。
eg、<dubbo:reference id="demoService" interface="com.unj.dubbotest.provider.DemoService" /><dubbo:protocol/> 協議配置，用于配置提供服務的協議信息，協議由提供方指定，消費方被動接受。
eg、<dubbo:protocol name="dubbo" port="20880" /><dubbo:application/> 應用配置，用于配置當前應用信息，不管該應用是提供者還是消費者。
eg、<dubbo:application name="xixi_provider" /><dubbo:application name="hehe_consumer" /><dubbo:module/> 模塊配置，用于配置當前模塊信息，可選。
<dubbo:registry/> 注冊中心配置，用于配置連接注冊中心相關信息。
eg、<dubbo:registry address="zookeeper://192.168.2.249:2181" /><dubbo:monitor/> 監控中心配置，用于配置連接監控中心相關信息，可選。
<dubbo:provider/> 提供方的缺省值，當ProtocolConfig和ServiceConfig某屬性沒有配置時，采用此缺省值，可選。
<dubbo:consumer/> 消費方缺省配置，當ReferenceConfig某屬性沒有配置時，采用此缺省值，可選。
<dubbo:method/> 方法配置，用于ServiceConfig和ReferenceConfig指定方法級的配置信息。
<dubbo:argument/> 用于指定方法參數配置。二、服務調用超時設置
上圖中以timeout為例，顯示了配置的查找順序，其它retries, loadbalance, actives也類似。
方法級優先，接口級次之，全局配置再次之。
如果級別一樣，則消費方優先，提供方次之。
其中，服務提供方配置，通過URL經由注冊中心傳遞給消費方。
建議由服務提供方設置超時，因為一個方法需要執行多長時間，服務提供方更清楚，如果一個消費方同時引用多個服務，就不需要關心每個服務的超時設置。
理論上ReferenceConfig的非服務標識配置，在ConsumerConfig，ServiceConfig, ProviderConfig均可以缺省配置。
三、啟動時檢查?
Dubbo缺省會在啟動時檢查依賴的服務是否可用，不可用時會拋出異常，阻止Spring初始化完成，以便上線時，能及早發現問題，默認check=true。
如果你的Spring容器是懶加載的，或者通過API編程延遲引用服務，請關閉check，否則服務臨時不可用時，會拋出異常，拿到null引用，如果check=false，總是會返回引用，當服務恢復時，能自動連上。
可以通過check="false"關閉檢查，比如，測試時，有些服務不關心，或者出現了循環依賴，必須有一方先啟動。
1、關閉某個服務的啟動時檢查：(沒有提供者時報錯)
<dubbo:reference interface="com.foo.BarService" check="false" />2、關閉所有服務的啟動時檢查：(沒有提供者時報錯) 寫在定義服務消費者一方
<dubbo:consumer check="false" />3、關閉注冊中心啟動時檢查：(注冊訂閱失敗時報錯)
<dubbo:registry check="false" />引用缺省是延遲初始化的，只有引用被注入到其它Bean，或被getBean()獲取，才會初始化。
如果需要饑餓加載，即沒有人引用也立即生成動態代理，可以配置：
<dubbo:reference interface="com.foo.BarService" init="true" />四、訂閱
1、問題
為方便開發測試，經常會在線下共用一個所有服務可用的注冊中心，這時，如果一個正在開發中的服務提供者注冊，可能會影響消費者不能正常運行。
2、解決方案
可以讓服務提供者開發方，只訂閱服務(開發的服務可能依賴其它服務)，而不注冊正在開發的服務，通過直連測試正在開發的服務。
禁用注冊配置：
<dubbo:registry address="10.20.153.10:9090" register="false" />
或者：
<dubbo:registry address="10.20.153.10:9090?register=false" />五、回聲測試(測試服務是否可用)
回聲測試用于檢測服務是否可用，回聲測試按照正常請求流程執行，能夠測試整個調用是否通暢，可用于監控。
所有服務自動實現EchoService接口，只需將任意服務引用強制轉型為EchoService，即可使用。
eg、<dubbo:reference id="memberService" interface="com.xxx.MemberService" />MemberService memberService = ctx.getBean("memberService"); // 遠程服務引用
EchoService echoService = (EchoService) memberService; // 強制轉型為EchoService
String status = echoService.$echo("OK"); // 回聲測試可用性
assert(status.equals("OK"))六、延遲連接?
延遲連接，用于減少長連接數，當有調用發起時，再創建長連接。
只對使用長連接的dubbo協議生效。
<dubbo:protocol name="dubbo" lazy="true" />七、令牌驗證?
防止消費者繞過注冊中心訪問提供者，在注冊中心控制權限，以決定要不要下發令牌給消費者，注冊中心可靈活改變授權方式，而不需修改或升級提供者
1、全局設置開啟令牌驗證：
<!--隨機token令牌，使用UUID生成-->
<dubbo:provider interface="com.foo.BarService" token="true" /><!--固定token令牌，相當于密碼-->
<dubbo:provider interface="com.foo.BarService" token="123456" />2、服務級別設置開啟令牌驗證：
<!--隨機token令牌，使用UUID生成-->
<dubbo:service interface="com.foo.BarService" token="true" /><!--固定token令牌，相當于密碼-->
<dubbo:service interface="com.foo.BarService" token="123456" />3、協議級別設置開啟令牌驗證：
<!--隨機token令牌，使用UUID生成-->
<dubbo:protocol name="dubbo" token="true" /><!--固定token令牌，相當于密碼-->
<dubbo:protocol name="dubbo" token="123456" />八、日志適配?
缺省自動查找：log4j、slf4j、jcl、jdk
可以通過以下方式配置日志輸出策略：dubbo:application logger="log4j"/>
訪問日志：
如果你想記錄每一次請求信息，可開啟訪問日志，類似于apache的訪問日志。此日志量比較大，請注意磁盤容量。
將訪問日志輸出到當前應用的log4j日志：
<dubbo:protocol accesslog="true" />將訪問日志輸出到指定文件：
<dubbo:protocol accesslog="http://10.20.160.198/wiki/display/dubbo/foo/bar.log" />九、配置Dubbo緩存文件
配置方法如下：
<dubbo:registryfile=”${user.home}/output/dubbo.cache” />注意：
文件的路徑，應用可以根據需要調整，保證這個文件不會在發布過程中被清除。如果有多個應用進程注意不要使用同一個文件，避免內容被覆蓋。
這個文件會緩存：
注冊中心的列表
服務提供者列表
有了這項配置后，當應用重啟過程中，Dubbo注冊中心不可用時則應用會從這個緩存文件讀取服務提供者列表的信息，進一步保證應用可靠性。
?
