分散式服務框架Dubbo的配置
一、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
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快取檔案
配置方法如下:
<dubbo:registryfile=”${user.home}/output/dubbo.cache” />
注意
注意: 檔案的路徑,應用可以根據需要調整,保證這個檔案不會在釋出過程中被清除。如果有多個應用程序注意不要使用同一個檔案,避免內容被覆蓋。
這個檔案會快取: 註冊中心的列表 服務提供者列表
有了這項配置後,當應用重啟過程中,Dubbo註冊中心不可用時則應用會從這個快取檔案讀取服務提供者列表的資訊,進一步保證應用可靠性。