1.Dubbo是什么赦拘？

Dubbo 是一個(gè)分布式甸各、高性能垛贤、透明化的 RPC 服務(wù)框架，提供服務(wù)自動(dòng)注冊(cè)趣倾、自動(dòng)發(fā)現(xiàn)等高效服務(wù)治理方案聘惦， 可以和 Spring 框架無(wú)縫集成。

2.Dubbo的由來(lái)儒恋？

互聯(lián)網(wǎng)的快速發(fā)展善绎，Web應(yīng)用程序的規(guī)模不斷擴(kuò)大黔漂，一般會(huì)經(jīng)歷如下四個(gè)發(fā)展階段。

單一應(yīng)用架構(gòu)

當(dāng)網(wǎng)站流量很小時(shí)禀酱，只需一個(gè)應(yīng)用炬守，將所有功能都部署在一起即可。

垂直應(yīng)用架構(gòu)

當(dāng)訪問(wèn)量逐漸增大剂跟，單一應(yīng)用按照有業(yè)務(wù)線拆成多個(gè)應(yīng)用减途，以提升效率。

此時(shí)曹洽，用于加速前端頁(yè)面開(kāi)發(fā)的Web框架(MVC)是關(guān)鍵鳍置。

分布式服務(wù)架構(gòu)

當(dāng)垂直應(yīng)用越來(lái)越多，應(yīng)用之間交互不可避免送淆，將核心業(yè)務(wù)抽取出來(lái)税产，作為獨(dú)立的服務(wù)，逐漸形成穩(wěn)定的服務(wù)中心坊夫，使前端應(yīng)用能更快速的響應(yīng)多變的市場(chǎng)需求砖第。

此時(shí)，用于提高業(yè)務(wù)復(fù)用及整合的分布式服務(wù)框架(RPC)是關(guān)鍵环凿。

流動(dòng)計(jì)算架構(gòu)

當(dāng)服務(wù)越來(lái)越多梧兼，容量的評(píng)估，小服務(wù)資源的浪費(fèi)等問(wèn)題逐漸顯現(xiàn)智听，此時(shí)需增加一個(gè)調(diào)度中心基于訪問(wèn)壓力實(shí)時(shí)管理集群容量羽杰，提高集群利用率。

此時(shí)到推，用于提高機(jī)器利用率的資源調(diào)度和治理中心(SOA)是關(guān)鍵考赛。

?

3.Dubbo的主要應(yīng)用場(chǎng)景？

透明化的遠(yuǎn)程方法調(diào)用莉测，就像調(diào)用本地方法一樣調(diào)用遠(yuǎn)程方法颜骤，只需簡(jiǎn)單配置，沒(méi)有任何API侵入捣卤。

軟負(fù)載均衡及容錯(cuò)機(jī)制忍抽，可在內(nèi)網(wǎng)替代F5等硬件負(fù)載均衡器，降低成本董朝，減少單點(diǎn)鸠项。

服務(wù)自動(dòng)注冊(cè)與發(fā)現(xiàn)，不再需要寫死服務(wù)提供方地址子姜，注冊(cè)中心基于接口名查詢服務(wù)提供者的IP地址祟绊，并且能夠平滑添加或刪除服務(wù)提供者。

4.Dubbo的核心功能？

主要就是如下3個(gè)核心功能：

Remoting：網(wǎng)絡(luò)通信框架牧抽，提供對(duì)多種NIO框架抽象封裝嘉熊，包括“同步轉(zhuǎn)異步”和“請(qǐng)求-響應(yīng)”模式的信息交換方式。

Cluster：服務(wù)框架阎姥，提供基于接口方法的透明遠(yuǎn)程過(guò)程調(diào)用记舆，包括多協(xié)議支持，以及軟負(fù)載均衡呼巴，失敗容錯(cuò)，地址路由御蒲，動(dòng)態(tài)配置等集群支持衣赶。

Registry：服務(wù)注冊(cè)，基于注冊(cè)中心目錄服務(wù)厚满，使服務(wù)消費(fèi)方能動(dòng)態(tài)的查找服務(wù)提供方府瞄，使地址透明，使服務(wù)提供方可以平滑增加或減少機(jī)器碘箍。

5.Dubbo的核心組件遵馆？

?

6.Dubbo服務(wù)注冊(cè)與發(fā)現(xiàn)的流程？

?

流程說(shuō)明：

Provider(提供者)綁定指定端口并啟動(dòng)服務(wù)

指供者連接注冊(cè)中心丰榴，并發(fā)本機(jī)IP货邓、端口、應(yīng)用信息和提供服務(wù)信息發(fā)送至注冊(cè)中心存儲(chǔ)

Consumer(消費(fèi)者）四濒，連接注冊(cè)中心 换况，并發(fā)送應(yīng)用信息、所求服務(wù)信息至注冊(cè)中心

注冊(cè)中心根據(jù) 消費(fèi) 者所求服務(wù)信息匹配對(duì)應(yīng)的提供者列表發(fā)送至Consumer 應(yīng)用緩存盗蟆。

Consumer 在發(fā)起遠(yuǎn)程調(diào)用時(shí)基于緩存的消費(fèi)者列表?yè)衿湟话l(fā)起調(diào)用戈二。

Provider 狀態(tài)變更會(huì)實(shí)時(shí)通知注冊(cè)中心、在由注冊(cè)中心實(shí)時(shí)推送至Consumer

設(shè)計(jì)的原因：

Consumer 與Provider 解偶喳资，雙方都可以橫向增減節(jié)點(diǎn)數(shù)觉吭。

注冊(cè)中心對(duì)本身可做對(duì)等集群，可動(dòng)態(tài)增減節(jié)點(diǎn)仆邓，并且任意一臺(tái)宕掉后鲜滩，將自動(dòng)切換到另一臺(tái)

去中心化，雙方不直接依懶注冊(cè)中心宏赘，即使注冊(cè)中心全部宕機(jī)短時(shí)間內(nèi)也不會(huì)影響服務(wù)的調(diào)用

服務(wù)提供者無(wú)狀態(tài)绒北，任意一臺(tái)宕掉后，不影響使用

?

7.Dubbo的架構(gòu)設(shè)計(jì)察署？

?

Dubbo框架設(shè)計(jì)一共劃分了10個(gè)層：

服務(wù)接口層（Service）：該層是與實(shí)際業(yè)務(wù)邏輯相關(guān)的闷游，根據(jù)服務(wù)提供方和服務(wù)消費(fèi)方的業(yè)務(wù)設(shè)計(jì)對(duì)應(yīng)的接口和實(shí)現(xiàn)。

配置層（Config）：對(duì)外配置接口，以ServiceConfig和ReferenceConfig為中心脐往。

服務(wù)代理層（Proxy）：服務(wù)接口透明代理休吠，生成服務(wù)的客戶端Stub和服務(wù)器端Skeleton，以ServiceProxy為中心业簿，擴(kuò)展接口為ProxyFactory瘤礁。

服務(wù)注冊(cè)層（Registry）：封裝服務(wù)地址的注冊(cè)與發(fā)現(xiàn)，以服務(wù)URL為中心梅尤。

集群層（Cluster）：封裝多個(gè)提供者的路由及負(fù)載均衡柜思，并橋接注冊(cè)中心，以Invoker為中心巷燥。

監(jiān)控層（Monitor）：RPC調(diào)用次數(shù)和調(diào)用時(shí)間監(jiān)控赡盘，以Statistics為中心，擴(kuò)展接口為MonitorFactory缰揪、Monitor和MonitorService陨享。

遠(yuǎn)程調(diào)用層（Protocol）：封將RPC調(diào)用，以Invocation和Result為中心钝腺，擴(kuò)展接口為Protocol抛姑、Invoker和Exporter。

信息交換層（Exchange）：封裝請(qǐng)求響應(yīng)模式艳狐，同步轉(zhuǎn)異步定硝，以Request和Response為中心，擴(kuò)展接口為Exchanger僵驰、ExchangeChannel喷斋、ExchangeClient和ExchangeServer。

網(wǎng)絡(luò)傳輸層（Transport）：抽象mina和netty為統(tǒng)一接口蒜茴，以Message為中心星爪，擴(kuò)展接口為Channel、Transporter粉私、Client顽腾、Server和Codec。

8.Dubbo的服務(wù)調(diào)用流程诺核？

?

9.Dubbo支持哪些協(xié)議抄肖，每種協(xié)議的應(yīng)用場(chǎng)景，優(yōu)缺點(diǎn)窖杀？

dubbo：?jiǎn)我婚L(zhǎng)連接和NIO異步通訊漓摩，適合大并發(fā)小數(shù)據(jù)量的服務(wù)調(diào)用，以及消費(fèi)者遠(yuǎn)大于提供者入客。傳輸協(xié)議TCP管毙，異步腿椎，Hessian序列化；

rmi：采用JDK標(biāo)準(zhǔn)的rmi協(xié)議實(shí)現(xiàn)夭咬，傳輸參數(shù)和返回參數(shù)對(duì)象需要實(shí)現(xiàn)Serializable接口啃炸，使用java標(biāo)準(zhǔn)序列化機(jī)制，使用阻塞式短連接卓舵，傳輸數(shù)據(jù)包大小混合南用，消費(fèi)者和提供者個(gè)數(shù)差不多，可傳文件掏湾，傳輸協(xié)議TCP裹虫。 多個(gè)短連接，TCP協(xié)議傳輸融击，同步傳輸恒界，適用常規(guī)的遠(yuǎn)程服務(wù)調(diào)用和rmi互操作。在依賴低版本的Common-Collections包砚嘴，java序列化存在安全漏洞；

webservice：基于WebService的遠(yuǎn)程調(diào)用協(xié)議涩拙，集成CXF實(shí)現(xiàn)际长，提供和原生WebService的互操作。多個(gè)短連接兴泥，基于HTTP傳輸工育，同步傳輸，適用系統(tǒng)集成和跨語(yǔ)言調(diào)用搓彻；

http：基于Http表單提交的遠(yuǎn)程調(diào)用協(xié)議如绸，使用Spring的HttpInvoke實(shí)現(xiàn)。多個(gè)短連接旭贬，傳輸協(xié)議HTTP怔接，傳入?yún)?shù)大小混合，提供者個(gè)數(shù)多于消費(fèi)者稀轨，需要給應(yīng)用程序和瀏覽器JS調(diào)用扼脐；

hessian：集成Hessian服務(wù)，基于HTTP通訊奋刽，采用Servlet暴露服務(wù)瓦侮，Dubbo內(nèi)嵌Jetty作為服務(wù)器時(shí)默認(rèn)實(shí)現(xiàn)，提供與Hession服務(wù)互操作佣谐。多個(gè)短連接肚吏，同步HTTP傳輸，Hessian序列化狭魂，傳入?yún)?shù)較大罚攀，提供者大于消費(fèi)者党觅，提供者壓力較大，可傳文件坞生；

memcache：基于memcached實(shí)現(xiàn)的RPC協(xié)議

redis：基于redis實(shí)現(xiàn)的RPC協(xié)議

10.dubbo推薦用什么協(xié)議仔役？

默認(rèn)使用dubbo協(xié)議

11.Dubbo有些哪些注冊(cè)中心？

Multicast注冊(cè)中心：Multicast注冊(cè)中心不需要任何中心節(jié)點(diǎn)是己，只要廣播地址又兵，就能進(jìn)行服務(wù)注冊(cè)和發(fā)現(xiàn)∽浞希基于網(wǎng)絡(luò)中組播傳輸實(shí)現(xiàn)沛厨；

Zookeeper注冊(cè)中心：基于分布式協(xié)調(diào)系統(tǒng)Zookeeper實(shí)現(xiàn)，采用Zookeeper的watch機(jī)制實(shí)現(xiàn)數(shù)據(jù)變更摔认；

redis注冊(cè)中心：基于redis實(shí)現(xiàn)逆皮，采用key/Map存儲(chǔ)，住key存儲(chǔ)服務(wù)名和類型参袱，Map中key存儲(chǔ)服務(wù)URL电谣，value服務(wù)過(guò)期時(shí)間∧ㄊ矗基于redis的發(fā)布/訂閱模式通知數(shù)據(jù)變更剿牺；

Simple注冊(cè)中心

12.Dubbo默認(rèn)采用注冊(cè)中心？

? 采用Zookeeper

13.為什么需要服務(wù)治理环壤？

?

過(guò)多的服務(wù)URL配置困難

負(fù)載均衡分配節(jié)點(diǎn)壓力過(guò)大的情況下也需要部署集群

服務(wù)依賴混亂晒来，啟動(dòng)順序不清晰

過(guò)多服務(wù)導(dǎo)致性能指標(biāo)分析難度較大，需要監(jiān)控

14.Dubbo的注冊(cè)中心集群掛掉郑现，發(fā)布者和訂閱者之間還能通信么湃崩？

可以的，啟動(dòng)dubbo時(shí)接箫，消費(fèi)者會(huì)從zookeeper拉取注冊(cè)的生產(chǎn)者的地址接口等數(shù)據(jù)攒读，緩存在本地。

每次調(diào)用時(shí)列牺，按照本地存儲(chǔ)的地址進(jìn)行調(diào)用整陌。

15.Dubbo與Spring的關(guān)系？

Dubbo采用全Spring配置方式瞎领，透明化接入應(yīng)用泌辫，對(duì)應(yīng)用沒(méi)有任何API侵入，只需用Spring加載Dubbo的配置即可九默，Dubbo基于Spring的Schema擴(kuò)展進(jìn)行加載震放。

16.Dubbo使用的是什么通信框架?

默認(rèn)使用NIO Netty框架

17.Dubbo集群提供了哪些負(fù)載均衡策略？

Random LoadBalance:隨機(jī)選取提供者策略驼修，有利于動(dòng)態(tài)調(diào)整提供者權(quán)重殿遂。截面碰撞率高诈铛，調(diào)用次數(shù)越多，分布越均勻墨礁；

RoundRobin LoadBalance:輪循選取提供者策略幢竹，平均分布，但是存在請(qǐng)求累積的問(wèn)題恩静；

LeastActive LoadBalance:最少活躍調(diào)用策略焕毫，解決慢提供者接收更少的請(qǐng)求；

ConstantHash LoadBalance:一致性Hash策略驶乾，使相同參數(shù)請(qǐng)求總是發(fā)到同一提供者邑飒，一臺(tái)機(jī)器宕機(jī)，可以基于虛擬節(jié)點(diǎn)级乐，分?jǐn)傊疗渌峁┱吒硐蹋苊庖鹛峁┱叩膭×易儎?dòng)；

缺省時(shí)為Random隨機(jī)調(diào)用

18.Dubbo的集群容錯(cuò)方案有哪些风科？

Failover Cluster

失敗自動(dòng)切換撒轮，當(dāng)出現(xiàn)失敗，重試其它服務(wù)器贼穆。通常用于讀操作腔召，但重試會(huì)帶來(lái)更長(zhǎng)延遲。

Failfast Cluster

快速失敗扮惦，只發(fā)起一次調(diào)用，失敗立即報(bào)錯(cuò)亲桦。通常用于非冪等性的寫操作崖蜜，比如新增記錄。

Failsafe Cluster

失敗安全客峭，出現(xiàn)異常時(shí)豫领，直接忽略。通常用于寫入審計(jì)日志等操作舔琅。

Failback Cluster

失敗自動(dòng)恢復(fù)等恐，后臺(tái)記錄失敗請(qǐng)求，定時(shí)重發(fā)备蚓。通常用于消息通知操作课蔬。

Forking Cluster

并行調(diào)用多個(gè)服務(wù)器，只要一個(gè)成功即返回郊尝。通常用于實(shí)時(shí)性要求較高的讀操作二跋，但需要浪費(fèi)更多服務(wù)資源×骰瑁可通過(guò) forks="2" 來(lái)設(shè)置最大并行數(shù)扎即。

Broadcast Cluster

廣播調(diào)用所有提供者吞获，逐個(gè)調(diào)用，任意一臺(tái)報(bào)錯(cuò)則報(bào)錯(cuò) 谚鄙。通常用于通知所有提供者更新緩存或日志等本地資源信息各拷。

19.Dubbo的默認(rèn)集群容錯(cuò)方案？

Failover Cluster

20.Dubbo支持哪些序列化方式闷营？

默認(rèn)使用Hessian序列化烤黍，還有Duddo、FastJson粮坞、Java自帶序列化蚊荣。

21.Dubbo超時(shí)時(shí)間怎樣設(shè)置？

Dubbo超時(shí)時(shí)間設(shè)置有兩種方式：

服務(wù)提供者端設(shè)置超時(shí)時(shí)間莫杈，在Dubbo的用戶文檔中互例，推薦如果能在服務(wù)端多配置就盡量多配置，因?yàn)榉?wù)提供者比消費(fèi)者更清楚自己提供的服務(wù)特性筝闹。

服務(wù)消費(fèi)者端設(shè)置超時(shí)時(shí)間媳叨，如果在消費(fèi)者端設(shè)置了超時(shí)時(shí)間，以消費(fèi)者端為主关顷，即優(yōu)先級(jí)更高糊秆。因?yàn)榉?wù)調(diào)用方設(shè)置超時(shí)時(shí)間控制性更靈活。如果消費(fèi)方超時(shí)议双，服務(wù)端線程不會(huì)定制痘番，會(huì)產(chǎn)生警告。

22.服務(wù)調(diào)用超時(shí)問(wèn)題怎么解決平痰？

dubbo在調(diào)用服務(wù)不成功時(shí)汞舱，默認(rèn)是會(huì)重試兩次的。

23.Dubbo在安全機(jī)制方面是如何解決宗雇？

Dubbo通過(guò)Token令牌防止用戶繞過(guò)注冊(cè)中心直連昂芜，然后在注冊(cè)中心上管理授權(quán)。Dubbo還提供服務(wù)黑白名單赔蒲，來(lái)控制服務(wù)所允許的調(diào)用方泌神。

24.dubbo 和 dubbox 之間的區(qū)別？

dubbox 基于 dubbo 上做了一些擴(kuò)展舞虱，如加了服務(wù)可 restful 調(diào)用欢际，更新了開(kāi)源組件等。

25.Dubbo和Spring Cloud的關(guān)系矾兜？

Dubbo 是 SOA 時(shí)代的產(chǎn)物幼苛，它的關(guān)注點(diǎn)主要在于服務(wù)的調(diào)用，流量分發(fā)焕刮、流量監(jiān)控和熔斷舶沿。而 Spring Cloud 誕生于微服務(wù)架構(gòu)時(shí)代墙杯，考慮的是微服務(wù)治理的方方面面，另外由于依托了 Spirng括荡、Spirng Boot 的優(yōu)勢(shì)之上高镐，兩個(gè)框架在開(kāi)始目標(biāo)就不一致，Dubbo 定位服務(wù)治理畸冲、Spirng Cloud 是一個(gè)生態(tài)嫉髓。

26.Dubbo和Spring Cloud的區(qū)別？

?

最大的區(qū)別：Dubbo底層是使用Netty這樣的NIO框架邑闲，是基于TCP協(xié)議傳輸?shù)乃阈校浜弦訦ession序列化完成RPC通信。

而SpringCloud是基于Http協(xié)議+Rest接口調(diào)用遠(yuǎn)程過(guò)程的通信苫耸，相對(duì)來(lái)說(shuō)州邢，Http請(qǐng)求會(huì)有更大的報(bào)文，占的帶寬也會(huì)更多褪子。

但是REST相比RPC更為靈活量淌，服務(wù)提供方和調(diào)用方的依賴只依靠一紙契約，不存在代碼級(jí)別的強(qiáng)依賴嫌褪，這在強(qiáng)調(diào)快速演化的微服務(wù)環(huán)境下呀枢，顯得更為合適，至于注重通信速度還是方便靈活性笼痛。