[[285520]]

dubbo是什么

dubbo是一個分布式框架，遠程服務調用的分布式框架，其核心部分包含：集群容錯：提供基于接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集群支持。遠程通訊：提供對多種基于長連接的NIO框架抽象封裝，包括多種線程模型，序列化，以及“請求-響應”模式的信息交換方式。自動發現：基于注冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。

dubbo能做什么

透明化的遠程方法調用，就像調用本地方法一樣調用遠程方法，只需簡單配置，沒有任何API侵入。軟負載均衡及容錯機制，可在內網替代F5等硬件負載均衡器，降低成本，減少單點。服務自動注冊與發現，不再需要寫死服務提供方地址，注冊中心基于接口名查詢服務提供者的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、說說核心的配置有哪些？

核心配置有：

1) dubbo:service/

2) dubbo:reference/

3) dubbo:protocol/

4) dubbo:registry/

5) dubbo:application/

6) dubbo:provider/

7) dubbo:consumer/

8) 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 異常

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

a. 檢查連接的注冊中心是否正確

b. 到注冊中心查看相應的服務提供者是否存在

c. 檢查服務提供者是否正常運行

7) 出現” 消息發送失敗” 異常

通常是接口方法的傳入傳出參數未實現 Serializable 接口。

14、dubbo 和 dubbox 之間的區別？

答：dubbox 是當當網基于 dubbo 上做了一些擴展，如加了服務可 restful 調用，更新了開源組件等。

15、你還了解別的分布式框架嗎？

答：別的還有 spring 的 spring cloud，facebook 的 thrift，twitter 的 finagle 等。

16、Dubbo 支持哪些協議，每種協議的應用場景，優缺點？

dubbo：單一長連接和 NIO 異步通訊，適合大并發小數據量的服務調用，以及消費者遠大于提供者。傳輸協議 TCP，異步，Hessian 序列化；

rmi：采用 JDK 標準的 rmi 協議實現，傳輸參數和返回參數對象需要實現 Serializable 接口，使用 java 標準序列化機制，使用阻塞式短連接，傳輸數據包大小混合，消費者和提供者個數差不多，可傳文件，傳輸協議 TCP。多個短連接，TCP 協議傳輸，同步傳輸，適用常規的遠程服務調用和 rmi 互操作。在依賴低版本的 Common-Collections 包，java 序列化存在安全漏洞；

webservice:基于 WebService 的遠程調用協議，集成 CXF 實現，提供和原生 WebService 的互操作。多個短連接，基于 HTTP 傳輸，同步傳輸，適用系統集成和跨語言調用；http：基于 Http 表單提交的遠程調用協議，使用 Spring 的 HttpInvoke 實現。多個短連接，傳輸協議 HTTP，傳入參數大小混合，提供者個數多于消費者，需要給應用程序和瀏覽器 JS 調用；hessian：集成 Hessian 服務，基于 HTTP 通訊，采用 Servlet 暴露服務，Dubbo 內嵌 Jetty 作為服務器時默認實現，提供與 Hession 服務互操作。多個短連接，同步 HTTP 傳輸，Hessian 序列化，傳入參數較大，提供者大于消費者，提供者壓力較大，可傳文件；

memcache：基于 memcached 實現的 RPC 協議 redis：基于 redis 實現的 RPC 協議

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

Dubbo 提供了常見的集群策略實現，并預擴展點予以自行實現。

Random LoadBalance: 隨機選取提供者策略，有利于動態調整提供者權重。截面碰撞率高，調用次數越多，分布越均勻；

RoundRobin LoadBalance: 輪循選取提供者策略，平均分布，但是存在請求累積的問題；

LeastActive LoadBalance: 最少活躍調用策略，解決慢提供者接收更少的請求；ConstantHash LoadBalance: 一致性 Hash 策略，使相同參數請求總是發到同一提供者，一臺機器宕機，可以基于虛擬節點，分攤至其他提供者，避免引起提供者的劇烈變動；

18、服務調用超時問題怎么解決

dubbo在調用服務不成功時，默認是會重試兩次的。這樣在服務端的處理時間超過了設定的超時時間時，就會有重復請求，比如在發郵件時，可能就會發出多份重復郵件，執行注冊請求時，就會插入多條重復的注冊數據，那么怎么解決超時問題呢？如下

對于核心的服務中心，去除dubbo超時重試機制，并重新評估設置超時時間。業務處理代碼必須放在服務端，客戶端只做參數驗證和服務調用，不涉及業務流程處理 全局配置實例

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