Dubbo在開發中的一些常用配置

2021-09-26 19:03:18 字數 2316 閱讀 6767

目錄

1. 屬性配置方法及載入順序

2. 啟動檢查

3. 超時設定 & 配置覆蓋關係

4. 重試次數

5. 多版本

6. 本地存根

介紹dubbo在開發中的一些常用配置,文中內容主要參考dubbo文件配置和示例兩節,詳細可移步訪問傳送站

屬性常用配置方法主要有三種:

第一種是通過啟動時在虛擬機器引數中加上相關資訊

第三種是在classpath 根目錄下的建立 dubbo.properties,dubbo啟動時,如果沒有其他配置檔案,會自動載入該配置。

dubbo 缺省會在啟動時檢查依賴的服務是否可用,不可用時會丟擲異常,阻止 spring 初始化完成,以便上線時,能及早發現問題,預設check="true"

可在xml和properties檔案中進行配置,以顯式關閉啟動檢查

dubbo.consumer.check=false
由於網路或服務端不可靠,會導致呼叫出現一種不確定的中間狀態(超時)。為了避免超時導致客戶端資源(執行緒)掛起耗盡,必須設定超時時間。預設使用的timeout,目前預設為1000。

dubbo消費端

dubbo服務端

通過上面的配置,我們可能產生疑惑,如果多方都配置了屬性,那麼會以哪個為準?這就涉及到配置覆蓋關係

以 timeout 為例,顯示了配置的查詢順序,其它 retries, loadbalance, actives 等類似:

其中,服務提供方配置,通過 url 經由註冊中心傳遞給消費方。

建議由服務提供方設定超時,因為乙個方法需要執行多長時間,服務提供方更清楚,如呼叫的超時時間,合理的重試次數,等等;如果乙個消費方同時引用多個服務,就不需要關心每個服務的超時設定。另外,在服務提供方配置後,消費方不配置則會使用服務提供方的配置值,即服務提供方配置可以作為消費方的預設值。否則,消費方會使用消費方的全域性設定,這對於服務提供方是不可控的,並且往往是不合理的。

失敗自動切換,當出現失敗,重試其它伺服器,但重試會帶來更長延遲。可通過 retries="2" 來設定重試次數(不含第一次)。

當乙個介面實現,出現不相容公升級時,可以用版本號過渡,版本號不同的服務相互間不引用。

可以按照以下的步驟進行版本遷移:

在低壓力時間段,先公升級一半提供者為新版本

再將所有消費者公升級為新版本

然後將剩下的一半提供者公升級為新版本

老版本服務提供者配置:

新版本服務提供者配置:

老版本服務消費者配置:

新版本服務消費者配置:

如果不需要區分版本,可以按照以下的方式配置:

遠端服務後,客戶端通常只剩下介面,而實現全在伺服器端,但提供方有些時候想在客戶端也執行部分邏輯,比如:做 threadlocal 快取,提前驗證引數,呼叫失敗後偽造容錯資料等等,此時就需要在 api 中帶上 stub,客戶端生成 proxy 例項,會把 proxy 通過建構函式傳給 stub ,然後把 stub 暴露給使用者,stub 可以決定要不要去調 proxy。

服務提供方(服務消費方也可配置)

業務邏輯放在stub類中實現

package com.foo;

public class barservicestub implements barservice

public string sayhello(string name) catch (exception e) }}

Dubbo的一些思考

總覽 眾所周知,dubbo是乙個分布式rpc框架,主要解決服務間互相呼叫的問題。呼叫其實類似介面呼叫,如果想要呼叫不同伺服器上的介面可以使用http直接呼叫的方法,但是這種方法的開銷很大,並且不好處理遠端呼叫 現的各種問題 超時重試 負載均衡等等 也不方便監控服務端的存活情況,介面呼叫的次數等等。而...

開發常用的一些語句

2 remind trigger click 自動點選事件 3 back hide 隱藏 4 back show 顯示 5 booststrap組合表頭 js table bootstraptable columns中存放三組陣列 第一組陣列存放的是表的標題資訊,其中的colspan為整個表所有的列...

Dubbo中的一些常見問題?

關於dubbo是用的什麼協議?在使用dubbo的時候會配置 所以再回答面試官的時候就隨口說的是 dubbo協議 其實面試官問的此協議非彼協議,而是問的是http協議還是tcp協議,因為dubbo的核心就是用的單一長連線進行非同步通訊。那問題來了為什麼要用dubbo進行資料傳輸?一般服務端伺服器比較少...