阿里的Dubbo到底有多難，阿里面試26題及答案（核心元件+服務治理+架構設計等）
1.Dubbo是什麼？
Dubbo 是一個分散式、高效能、透明化的 RPC 服務框架，提供服務自動註冊、自動發現等高效服務治理方案， 可以和 Spring 框架無縫整合。
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 解偶，雙方都可以橫向增減節點數。
註冊中心對本身可做對等叢集，可動態增減節點，並且任意一臺宕掉後，將自動切換到另一臺
去中心化，雙方不直接依懶註冊中心，即使註冊中心全部宕機短時間內也不會影響服務的呼叫
服務提供者無狀態，任意一臺宕掉後，不影響使用
7.Dubbo的架構設計？
Dubbo框架設計一共劃分了10個層：
服務介面層（Service） ：該層是與實際業務邏輯相關的，根據服務提供方和服務消費方的業務設計對應的介面和實現。
配置層（Config） ：對外配置介面，以ServiceConfig和ReferenceConfig為中心。
服務代理層（Proxy ）：服務介面透明代理，生成服務的客戶端Stub和伺服器端Skeleton，以ServiceProxy為中心，擴充套件介面為ProxyFactory。
服務註冊層（Registry） ：封裝服務地址的註冊與發現，以服務URL為中心。
叢集層（Cluster） ：封裝多個提供者的路由及負載均衡，並橋接註冊中心，以Invoker為中心。
監控層（Monitor） ：RPC呼叫次數和呼叫時間監控，以Statistics為中心，擴充套件介面為MonitorFactory、Monitor和MonitorService。
遠端呼叫層（Protocol） ：封將RPC呼叫，以Invocation和Result為中心，擴充套件介面為Protocol、Invoker和Exporter。
資訊交換層（Exchange） ：封裝請求響應模式，同步轉非同步，以Request和Response為中心，擴充套件介面為Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。
網路傳輸層（Transport） ：抽象mina和netty為統一介面，以Message為中心，擴充套件介面為Channel、Transporter、Client、Server和Codec。
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註冊中心
12.Dubbo預設採用註冊中心？
採用Zookeeper
13.為什麼需要服務治理？
過多的服務URL配置困難
負載均衡分配節點壓力過大的情況下也需要部署叢集
服務依賴混亂，啟動順序不清晰
過多服務導致效能指標分析難度較大，需要監控
14.Dubbo的註冊中心叢集掛掉，釋出者和訂閱者之間還能通訊麼？
可以的，啟動dubbo時，消費者會從zookeeper拉取註冊的生產者的地址介面等資料，快取在本地。
每次呼叫時，按照本地儲存的地址進行呼叫。
15.Dubbo與Spring的關係？
Dubbo採用全Spring配置方式，透明化接入應用，對應用沒有任何API侵入，只需用Spring載入Dubbo的配置即可，Dubbo基於Spring的Schema擴充套件進行載入。
16.Dubbo使用的是什麼通訊框架?
預設使用NIO Netty框架
17.Dubbo叢集提供了哪些負載均衡策略？
Random LoadBalance: 隨機選取提供者策略，有利於動態調整提供者權重。截面碰撞率高，呼叫次數越多，分佈越均勻；
RoundRobin LoadBalance: 輪循選取提供者策略，平均分佈，但是存在請求累積的問題；
LeastActive LoadBalance: 最少活躍呼叫策略，解決慢提供者接收更少的請求；
ConstantHash LoadBalance: 一致性Hash策略，使相同引數請求總是發到同一提供者，一臺機器宕機，可以基於虛擬節點，分攤至其他提供者，避免引起提供者的劇烈變動；
預設時為Random隨機呼叫
18.Dubbo的叢集容錯方案有哪些？
Failover Cluster
失敗自動切換，當出現失敗，重試其它伺服器。通常用於讀操作，但重試會帶來更長延遲。
Failfast Cluster
快速失敗，只發起一次呼叫，失敗立即報錯。通常用於非冪等性的寫操作，比如新增記錄。
Failsafe Cluster
失敗安全，出現異常時，直接忽略。通常用於寫入審計日誌等操作。
Failback Cluster
失敗自動恢復，後臺記錄失敗請求，定時重發。通常用於訊息通知操作。
Forking Cluster
並行呼叫多個伺服器，只要一個成功即返回。通常用於實時性要求較高的讀操作，但需要浪費更多服務資源。可通過 forks="2" 來設定最大並行數。
Broadcast Cluster
廣播呼叫所有提供者，逐個呼叫，任意一臺報錯則報錯 。通常用於通知所有提供者更新快取或日誌等本地資源資訊。
19.Dubbo的預設叢集容錯方案？
Failover Cluster
20.Dubbo支援哪些序列化方式？
預設使用Hessian序列化，還有Duddo、FastJson、Java自帶序列化。
21.Dubbo超時時間怎樣設定？
Dubbo超時時間設定有兩種方式：
服務提供者端設定超時時間，在Dubbo的使用者文件中，推薦如果能在服務端多配置就儘量多配置，因為服務提供者比消費者更清楚自己提供的服務特性。
服務消費者端設定超時時間，如果在消費者端設定了超時時間，以消費者端為主，即優先順序更高。因為服務呼叫方設定超時時間控制性更靈活。如果消費方超時，服務端執行緒不會定製，會產生警告。
22.服務呼叫超時問題怎麼解決？
dubbo在呼叫服務不成功時，預設是會重試兩次的。
23.Dubbo在安全機制方面是如何解決？
Dubbo通過Token令牌防止使用者繞過註冊中心直連，然後在註冊中心上管理授權。Dubbo還提供服務黑白名單，來控制服務所允許的呼叫方。
24.dubbo 和 dubbox 之間的區別？
dubbox 基於 dubbo 上做了一些擴充套件，如加了服務可 restful 呼叫，更新了開源元件等。
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更為靈活，服務提供方和呼叫方的依賴只依靠一紙契約，不存在程式碼級別的強依賴，這在強調快速演化的微服務環境下，顯得更為合適，至於注重通訊速度還是方便靈活性。
最後給大家推薦一個BAT架構技術交流群：957413713 ，裡面會分享一些資深架構師錄製的視訊錄影：有Spring，MyBatis，Netty原始碼分析，高併發、高效能、分散式、微服務架構的原理，JVM效能優化這些成為架構師必備的知識體系。還能領取免費的學習資源，相信對於已經工作和遇到技術瓶頸的碼友，在這個群裡會有你需要的內容。
點選連結加入群聊【BAT架構技術交流群】： https://jq.qq.com/?_wv=1027&k=5XRbSdL