1.Dubbo是什麼？

Dubbo 是一個分散式、高效能、透明化的 RPC 服務框架，提供服務自動註冊、自動發現等高效服務治理方案， 可以和 Spring 框架無縫整合。

RPC 指的是遠端呼叫協議，也就是說兩個伺服器互動資料。

2.Dubbo的由來？

網際網路的快速發展，Web應用程式的規模不斷擴大，一般會經歷如下四個發展階段。

單一應用架構

當網站流量很小時，只需一個應用， 將所有功能都部署在一起即可。

垂直應用架構

當訪問量逐漸增大，單一應用按照有業務線 拆成多個應用 ，以提升效率。

此時，用於加速前端頁面開發的 Web框架(MVC) 是關鍵。

分散式服務架構

當垂直應用越來越多，應用之間互動不可避免， 將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心 ，使前端應用能更快速的響應多變的市場需求。

此時，用於提高業務複用及整合的 分散式服務框架(RPC) 是關鍵。

流動計算架構

當服務越來越多，容量的評估，小服務資源的浪費等問題逐漸顯現， 此時需增加一個排程中心基於訪問壓力實時管理叢集容量，提高叢集利用率 。

此時，用於提高機器利用率的 資源排程和治理中心(SOA) 是關鍵。

3.Dubbo的主要應用場景？

透明化的遠端方法呼叫，就像呼叫本地方法一樣呼叫遠端方法，只需簡單配置，沒有任何API侵入。

軟負載均衡及容錯機制，可在內網替代F5等硬體負載均衡器，降低成本，減少單點。

服務自動註冊與發現，不再需要寫死服務提供方地址，註冊中心基於介面名查詢服務提供者的IP地址，並且能夠平滑新增或刪除服務提供者。

4.Dubbo的核心功能？

主要就是如下3個核心功能：

• Remoting： 網路通訊框架，提供對多種NIO框架抽象封裝，包括“同步轉非同步”和“請求-響應”模式的資訊交換方式。
• Cluster：服務框架 ，提供基於介面方法的透明遠端過程呼叫，包括多協議支援，以及軟負載均衡，失敗容錯，地址路由，動態配置等叢集支援。
• Registry：服務註冊 ，基於註冊中心目錄服務，使服務消費方能動態的查詢 服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。

5.Dubbo的核心元件？

6.Dubbo服務註冊與發現的流程？

流程說明：

• Provider(提供者)繫結指定埠並啟動服務
• 指供者連線註冊中心，併發本機IP、埠、應用資訊和提供服務資訊傳送至註冊中心儲存
• Consumer(消費者），連線註冊中心 ，併傳送應用資訊、所求服務資訊至註冊中心
• 註冊中心根據 消費 者所求服務資訊匹配對應的提供者列表傳送至Consumer 應用快取。
• Consumer 在發起遠端呼叫時基於快取的消費者列表擇其一發起呼叫。
• Provider 狀態變更會實時通知註冊中心、在由註冊中心實時推送至Consumer

設計的原因：

• Consumer 與Provider 解偶，雙方都可以橫向增減節點數。
• 註冊中心對本身可做對等叢集，可動態增減節點，並且任意一臺宕掉後，將自動切換到另一臺
• 去中心化，雙方不直接依懶註冊中心，即使註冊中心全部當機短時間內也不會影響服務的呼叫
• 服務提供者無狀態，任意一臺宕掉後，不影響使用

image

7.Dubbo的架構設計？

Dubbo框架設計一共劃分了10個層：

服務介面層（Service） ：該層是與實際業務邏輯相關的，根據服務提供方和服務消費方的業務設計對應的介面和實現。

配置層（Config） ：對外配置介面，以ServiceConfig和ReferenceConfig為中心。

服務代理層（Proxy ）：服務介面透明代理，生成服務的客戶端Stub和伺服器端Skeleton。

服務註冊層（Registry） ：封裝服務地址的註冊與發現，以服務URL為中心。

叢集層（Cluster） ：封裝多個提供者的路由及負載均衡，並橋接註冊中心，以Invoker為中心。

監控層（Monitor） ：RPC呼叫次數和呼叫時間監控。

遠端呼叫層（Protocol） ：封將RPC呼叫，以Invocation和Result為中心，擴充套件介面為Protocol、Invoker和Exporter。

資訊交換層（Exchange） ：封裝請求響應模式，同步轉非同步，以Request和Response為中心。

網路傳輸層（Transport） ：抽象mina和netty為統一介面，以Message為中心。

8.Dubbo的服務呼叫流程？

9.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協議

10.dubbo推薦用什麼協議？

預設使用dubbo協議

11.Dubbo有些哪些註冊中心？

• Multicast註冊中心： Multicast註冊中心不需要任何中心節點，只要廣播地址，就能進行服務註冊和發現。基於網路中組播傳輸實現；
• Zookeeper註冊中心： 基於分散式協調系統Zookeeper實現，採用Zookeeper的watch機制實現資料變更；
• redis註冊中心： 基於redis實現，採用key/Map儲存，住key儲存服務名和型別，Map中key儲存服務URL，value服務過期時間。基於redis的釋出/訂閱模式通知資料變更；
• Simple註冊中心

Java架構/分散式：705127209（大牛交流群）沒有開發經驗勿加！

12.Dubbo的服務治理？

• 過多的服務URL配置困難

• 負載均衡分配節點壓力過大的情況下也需要部署叢集

• 服務依賴混亂，啟動順序不清晰

• 過多服務導致效能指標分析難度較大，需要監控

13.Dubbo的註冊中心叢集掛掉，釋出者和訂閱者之間還能通訊麼？

可以的，啟動dubbo時，消費者會從zookeeper拉取註冊的生產者的地址介面等資料，快取在本地。

每次呼叫時，按照本地儲存的地址進行呼叫。

Java架構/分散式：705 127 209釦 㪊（大牛架構圈子）

14.Dubbo與Spring的關係？

Dubbo採用全Spring配置方式，透明化接入應用，對應用沒有任何API侵入，只需用Spring載入Dubbo的配置即可，Dubbo基於Spring的Schema擴充套件進行載入。

15.Dubbo使用的是什麼通訊框架?

預設使用NIO Netty框架

16.Dubbo叢集提供了哪些負載均衡策略？

• Random LoadBalance: 隨機選取提供者策略，有利於動態調整提供者權重。截面碰撞率高，呼叫次數越多，分佈越均勻；
• RoundRobin LoadBalance: 輪循選取提供者策略，平均分佈，但是存在請求累積的問題；
• LeastActive LoadBalance: 最少活躍呼叫策略，解決慢提供者接收更少的請求；
• ConstantHash LoadBalance: 一致性Hash策略，使相同引數請求總是發到同一提供者，一臺機器當機，可以基於虛擬節點，分攤至其他提供者，避免引起提供者的劇烈變動；

預設時為Random隨機呼叫

17.Dubbo的叢集容錯方案有哪些？

• Failover Cluster
• 失敗自動切換，當出現失敗，重試其它伺服器。通常用於讀操作，但重試會帶來更長延遲。
• Failfast Cluster
• 快速失敗，只發起一次呼叫，失敗立即報錯。通常用於非冪等性的寫操作，比如新增記錄。
• Failsafe Cluster
• 失敗安全，出現異常時，直接忽略。通常用於寫入審計日誌等操作。
• Failback Cluster
• 失敗自動恢復，後臺記錄失敗請求，定時重發。通常用於訊息通知操作。
• Forking Cluster
• 並行呼叫多個伺服器，只要一個成功即返回。通常用於實時性要求較高的讀操作，但需要浪費更多服務資源。可透過 forks=”2″ 來設定最大並行數。
• Broadcast Cluster
• 廣播呼叫所有提供者，逐個呼叫，任意一臺報錯則報錯 。通常用於通知所有提供者更新快取或日誌等本地資源資訊。

18.Dubbo的預設叢集容錯方案？

Failover Cluster

19.Dubbo支援哪些序列化方式？

預設使用Hessian序列化，還有Duddo、FastJson、Java自帶序列化。

20.Dubbo超時時間怎樣設定？

Dubbo超時時間設定有兩種方式：

• 服務提供者端設定超時時間，在Dubbo的使用者文件中，推薦如果能在服務端多配置就儘量多配置，因為服務提供者比消費者更清楚自己提供的服務特性。
• 服務消費者端設定超時時間，如果在消費者端設定了超時時間，以消費者端為主，即優先順序更高。因為服務呼叫方設定超時時間控制性更靈活。如果消費方超時，服務端執行緒不會定製，會產生警告。

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

dubbo在呼叫服務不成功時，預設是會重試兩次的。

22.Dubbo在安全機制方面是如何解決？

Dubbo透過Token令牌防止使用者繞過註冊中心直連，然後在註冊中心上管理授權。Dubbo還提供服務黑白名單，來控制服務所允許的呼叫方。

23.dubbo 和 dubbox 之間的區別？

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

24.除了Dubbo還有哪些分散式框架？

大家熟知的就是Spring cloud，當然國外也有類似的多個框架。

25.Dubbo和Spring Cloud的關係？

Dubbo
是 SOA 時代的產物，它的關注點主要在於服務的呼叫，流量分發、流量監控和熔斷。而 Spring Cloud
誕生於微服務架構時代，考慮的是微服務治理的方方面面，另外由於依託了 Spirng、Spirng Boot
的優勢之上，兩個框架在開始目標就不一致，Dubbo 定位服務治理、Spirng Cloud 是一個生態。

26.dubbo和spring cloud的區別？

最大的區別：Dubbo底層是使用Netty這樣的NIO框架，是基於TCP協議傳輸的，配合以Hession序列化完成RPC通訊。

而SpringCloud是基於Http協議+Rest介面呼叫遠端過程的通訊，相對來說，Http請求會有更大的報文，佔的頻寬也會更多。但是REST相比RPC更為靈活，服務提供方和呼叫方的依賴只依靠一紙契約，不存在程式碼級別的強依賴，這在強調快速演化的微服務環境下，顯得更為合適，至於注重通訊速度還是方便靈活性，具體情況具體考慮。