[分散式][Dubbo]Dubbo常見問題

加瓦一枚發表於2019-03-20

dubbo是什麼

dubbo是一個分散式框架,遠端服務呼叫的分散式框架,其核心部分包含:
叢集容錯:提供基於介面方法的透明遠端過程呼叫,包括多協議支援,以及軟負載均衡,失敗容錯,地址路由,動態配置等叢集支援。
遠端通訊: 提供對多種基於長連線的NIO框架抽象封裝,包括多種執行緒模型,序列化,以及“請求-響應”模式的資訊交換方式。
自動發現:基於註冊中心目錄服務,使服務消費方能動態的查詢服務提供方,使地址透明,使服務提供方可以平滑增加或減少機器。

dubbo能做什麼

  1. 透明化的遠端方法呼叫,就像呼叫本地方法一樣呼叫遠端方法,只需簡單配置,沒有任何API侵入。
  2. 軟負載均衡及容錯機制,可在內網替代F5等硬體負載均衡器,降低成本,減少單點。
  3. 服務自動註冊與發現,不再需要寫死服務提供方地址,註冊中心基於介面名查詢服務提供者的IP地址,並且能夠平滑新增或刪除服務提供者。

1、預設使用的是什麼通訊框架,還有別的選擇嗎?

答:預設也推薦使用 netty 框架,還有 mina。

2、服務呼叫是阻塞的嗎?

答:預設是阻塞的,可以非同步呼叫,沒有返回值的可以這麼做。

3、一般使用什麼註冊中心?還有別的選擇嗎?

答:推薦使用 zookeeper 註冊中心,還有 Multicast註冊中心, Redis註冊中心, Simple註冊中心.

ZooKeeper的節點是通過像樹一樣的結構來進行維護的,並且每一個節點通過路徑來標示以及訪問。除此之外,每一個節點還擁有自身的一些資訊,包括:資料、資料長度、建立時間、修改時間等等。

4、預設使用什麼序列化框架,你知道的還有哪些?

答:預設使用 Hessian 序列化,還有 Duddo、FastJson、Java 自帶序列化。
hessian是一個採用二進位制格式傳輸的服務框架,相對傳統soap web service,更輕量,更快速。

Hessian原理與協議簡析:

http的協議約定了資料傳輸的方式,hessian也無法改變太多:

1) hessian中client與server的互動,基於http-post方式。

2) hessian將輔助資訊,封裝在http header中,比如“授權token”等,我們可以基於http-header來封裝關於“安全校驗”“meta資料”等。hessian提供了簡單的”校驗”機制。

3) 對於hessian的互動核心資料,比如“呼叫的方法”和引數列表資訊,將通過post請求的body體直接傳送,格式為位元組流。

4) 對於hessian的server端響應資料,將在response中通過位元組流的方式直接輸出。

hessian的協議本身並不複雜,在此不再贅言;所謂協議(protocol)就是約束資料的格式,client按照協議將請求資訊序列化成位元組序列傳送給server端,server端根據協議,將資料反序列化成“物件”,然後執行指定的方法,並將方法的返回值再次按照協議序列化成位元組流,響應給client,client按照協議將位元組流反序列話成”物件”。

5、服務提供者能實現失效踢出是什麼原理?

答:服務失效踢出基於 zookeeper 的臨時節點原理。

6、服務上線怎麼不影響舊版本?

答:採用多版本開發,不影響舊版本。在配置中新增version來作為版本區分

7、如何解決服務呼叫鏈過長的問題?

答:可以結合 zipkin 實現分散式服務追蹤。

8、說說核心的配置有哪些?

答:

核心配置有

  • dubbo:service/
  • dubbo:reference/
  • dubbo:protocol/
  • dubbo:registry/
  • dubbo:application/
  • dubbo:provider/
  • dubbo:consumer/
  • dubbo:method/

9、dubbo 推薦用什麼協議?

答:預設使用 dubbo 協議。

10、同一個服務多個註冊的情況下可以直連某一個服務嗎?

答:可以直連,修改配置即可,也可以通過 telnet 直接某個服務。

11、dubbo 在安全機制方面如何解決的?

dubbo 通過 token 令牌防止使用者繞過註冊中心直連,然後在註冊中心管理授權,dubbo 提供了黑白名單,控制服務所允許的呼叫方。

12、叢集容錯怎麼做?

答:讀操作建議使用 Failover 失敗自動切換,預設重試兩次其他伺服器。寫操作建議使用 Failfast 快速失敗,發一次呼叫失敗就立即報錯。

13、在使用過程中都遇到了些什麼問題? 如何解決的?

1. 同時配置了 XML 和 properties 檔案,則 properties 中的配置無效

只有 XML 沒有配置時,properties 才生效。

2.dubbo 預設會在啟動時檢查依賴是否可用,不可用就丟擲異常,阻止 spring 初始化完成,check 屬性預設為 true。

測試時有些服務不關心或者出現了迴圈依賴,將 check 設定為 false

3. 為了方便開發測試,線下有一個所有服務可用的註冊中心,這時,如果有一個正在開發中的服務提供者註冊,可能會影響消費者不能正常執行。

解決:讓服務提供者開發方,只訂閱服務,而不註冊正在開發的服務,通過直連測試正在開發的服務。設定 dubbo:registry 標籤的 register 屬性為 false。

4.spring 2.x 初始化死鎖問題。

在 spring 解析到 dubbo:service 時,就已經向外暴露了服務,而 spring 還在接著初始化其他 bean,如果這時有請求進來,並且服務的實現類裡有呼叫 applicationContext.getBean() 的用法。getBean 執行緒和 spring 初始化執行緒的鎖的順序不一樣,導致了執行緒死鎖,不能提供服務,啟動不了。

解決:不要在服務的實現類中使用 applicationContext.getBean(); 如果不想依賴配置順序,可以將 dubbo:provider 的 deplay 屬性設定為 - 1,使 dubbo 在容器初始化完成後再暴露服務。

5. 服務註冊不上

檢查 dubbo 的 jar 包有沒有在 classpath 中,以及有沒有重複的 jar 包

檢查暴露服務的 spring 配置有沒有載入

在服務提供者機器上測試與註冊中心的網路是否通

6. 出現 RpcException: No provider available for remote service 異常

表示沒有可用的服務提供者,

1). 檢查連線的註冊中心是否正確

2). 到註冊中心檢視相應的服務提供者是否存在

3). 檢查服務提供者是否正常執行

7. 出現” 訊息傳送失敗” 異常

通常是介面方法的傳入傳出引數未實現 Serializable 介面。

14、dubbo 和 dubbox 之間的區別?

答:dubbox 是噹噹網基於 dubbo 上做了一些擴充套件,如加了服務可 restful 呼叫,更新了開源元件等。

15、你還了解別的分散式框架嗎?

答:別的還有 spring 的 spring cloud,facebook 的 thrift,twitter 的 finagle 等。

16、Dubbo 支援哪些協議,每種協議的應用場景,優缺點?

  1. dubbo: 單一長連線和 NIO 非同步通訊,適合大併發小資料量的服務呼叫,以及消費者遠大於提供者。傳輸協議 TCP,非同步,Hessian 序列化;
  2. rmi: 採用 JDK 標準的 rmi 協議實現,傳輸引數和返回引數物件需要實現 Serializable 介面,使用 java 標準序列化機制,使用阻塞式短連線,傳輸資料包大小混合,消費者和提供者個數差不多,可傳檔案,傳輸協議 TCP。 多個短連線,TCP 協議傳輸,同步傳輸,適用常規的遠端服務呼叫和 rmi 互操作。在依賴低版本的 Common-Collections 包,java 序列化存在安全漏洞;
  3. webservice: 基於 WebService 的遠端呼叫協議,整合 CXF 實現,提供和原生 WebService 的互操作。多個短連線,基於 HTTP 傳輸,同步傳輸,適用系統整合和跨語言呼叫;http: 基於 Http 表單提交的遠端呼叫協議,使用 Spring 的 HttpInvoke 實現。多個短連線,傳輸協議 HTTP,傳入引數大小混合,提供者個數多於消費者,需要給應用程式和瀏覽器 JS 呼叫;
  4. hessian: 整合 Hessian 服務,基於 HTTP 通訊,採用 Servlet 暴露服務,Dubbo 內嵌 Jetty 作為伺服器時預設實現,提供與 Hession 服務互操作。多個短連線,同步 HTTP 傳輸,Hessian 序列化,傳入引數較大,提供者大於消費者,提供者壓力較大,可傳檔案;
  5. memcache: 基於 memcached 實現的 RPC 協議
  6. redis: 基於 redis 實現的 RPC 協議

17、Dubbo 叢集的負載均衡有哪些策略  

  1. Dubbo 提供了常見的叢集策略實現,並預擴充套件點予以自行實現。
  2. Random LoadBalance: 隨機選取提供者策略,有利於動態調整提供者權重。截面碰撞率高,呼叫次數越多,分佈越均勻;
  3. RoundRobin LoadBalance: 輪循選取提供者策略,平均分佈,但是存在請求累積的問題;
  4. LeastActive LoadBalance: 最少活躍呼叫策略,解決慢提供者接收更少的請求;
  5. ConstantHash LoadBalance: 一致性 Hash 策略,使相同引數請求總是發到同一提供者,一臺機器當機,可以基於虛擬節點,分攤至其他提供者,避免引起提供者的劇烈變動;

18. 服務呼叫超時問題怎麼解決

dubbo在呼叫服務不成功時,預設是會重試兩次的。這樣在服務端的處理時間超過了設定的超時時間時,就會有重複請求,比如在發郵件時,可能就會發出多份重複郵件,執行註冊請求時,就會插入多條重複的註冊資料,那麼怎麼解決超時問題呢?如下

  1. 對於核心的服務中心,去除dubbo超時重試機制,並重新評估設定超時時間。
  2. 業務處理程式碼必須放在服務端,客戶端只做引數驗證和服務呼叫,不涉及業務流程處理
    全域性配置例項

    <dubbo:provider delay="-1" timeout="6000" retries="0"/>

當然Dubbo的重試機制其實是非常好的QOS保證,它的路由機制,是會幫你把超時的請求路由到其他機器上,而不是本機嘗試,所以 dubbo的重試機器也能一定程度的保證服務的質量。但是請一定要綜合線上的訪問情況,給出綜合的評估。

相關文章