基礎(chǔ)知識為什么要使用Dubbo？隨著服務(wù)化的進(jìn)一步發(fā)展，服務(wù)越來越多，服務(wù)之間的調(diào)用和依賴也越來越復(fù)雜。面向服務(wù)的架構(gòu)（SOA）誕生了，并衍生了一系列相應(yīng)的技術(shù)。例如，封裝了服務(wù)提供、服務(wù)調(diào)用、連接處理、通信協(xié)議、序列化方法、服務(wù)發(fā)現(xiàn)、服務(wù)路由、日志輸出等行為的服務(wù)框架。這樣，分布式系統(tǒng)的服務(wù)治理框架就出現(xiàn)了，Dubbo也誕生了。達(dá)博是什么？ Dubbo是一個高性能、輕量級的開源RPC框架，提供自動服務(wù)注冊、自動發(fā)現(xiàn)等高效的服務(wù)治理解決方案，并且可以與Spring框架無縫集成。 Dubbo的使用場景有哪些？透明的遠(yuǎn)程方法調(diào)用：像調(diào)用本地方法一樣調(diào)用遠(yuǎn)程方法，配置簡單，無API侵入。軟負(fù)載均衡和容錯機(jī)制：可以替代內(nèi)網(wǎng)F5等硬件負(fù)載均衡器，降低成本和單點(diǎn)。自動服務(wù)注冊和發(fā)現(xiàn)：無需硬編碼服務(wù)提供商地址。注冊中心根據(jù)接口名稱查詢服務(wù)提供商的IP地址，可以平滑地添加或刪除服務(wù)提供商。 Dubbo的核心功能有哪些？ Remoting：網(wǎng)絡(luò)通信框架，提供對各種NIO框架的抽象封裝，包括“同步到異步”和“請求-響應(yīng)”模式的信息交換方式。集群：基于接口方法提供透明遠(yuǎn)程過程調(diào)用的服務(wù)框架，包括多協(xié)議支持，以及軟負(fù)載均衡、容錯、地址路由、動態(tài)配置等集群支持。注冊中心：服務(wù)注冊，基于注冊中心目錄服務(wù)，使服務(wù)消費(fèi)者能夠動態(tài)搜索服務(wù)提供者，使地址透明，讓服務(wù)提供者可以平滑地增減機(jī)器。 Dubbo的核心組件有哪些？ Provider：暴露服務(wù)的服務(wù)提供者Consumer：調(diào)用遠(yuǎn)程服務(wù)消費(fèi)者Registry：服務(wù)注冊和發(fā)現(xiàn)注冊中心Monitor：監(jiān)控中心和訪問調(diào)用統(tǒng)計Container：服務(wù)運(yùn)行容器Dubbo 服務(wù)器注冊和發(fā)現(xiàn)流程？服務(wù)容器Container負(fù)責(zé)啟動、加載、運(yùn)行服務(wù)提供者。當(dāng)服務(wù)提供者啟動時，它向注冊中心注冊其提供的服務(wù)。當(dāng)服務(wù)消費(fèi)者啟動時，它會向注冊中心訂閱它所需要的服務(wù)。注冊中心Registry將服務(wù)提供者地址列表返回給消費(fèi)者。如果有變更，注冊中心會基于長連接將變更數(shù)據(jù)推送給消費(fèi)者。服務(wù)消費(fèi)者Consumer根據(jù)軟負(fù)載均衡算法從提供者地址列表中選擇調(diào)用的提供者。如果呼叫失敗，它會選擇另一個提供商進(jìn)行呼叫。服務(wù)消費(fèi)者和服務(wù)提供者將呼叫次數(shù)和呼叫時間累積在內(nèi)存中，并定期每分鐘向監(jiān)控中心Monitor發(fā)送一次統(tǒng)計數(shù)據(jù)。

架構(gòu)設(shè)計Dubbo整體架構(gòu)設(shè)計中有哪些層次化接口？服務(wù)層（Service）：該層與業(yè)務(wù)邏輯相關(guān)。根據(jù)提供者和消費(fèi)者的業(yè)務(wù)設(shè)計，對應(yīng)的接口和實現(xiàn)配置層（Config）：外部配置接口，以ServiceConfig和ReferenceConfig為中心服務(wù)代理層（Proxy）：對服務(wù)接口的透明代理，生成服務(wù)接口服務(wù)的客戶端Stub 和服務(wù)器骨架。以ServiceProxy為中心，擴(kuò)展的接口是ProxyFactory服務(wù)注冊層（Registry）：封裝了服務(wù)地址的注冊和發(fā)現(xiàn)。以服務(wù)URL為中心，擴(kuò)展的接口有RegistryFactory、Registry、RegistryService。路由層（Cluster）：封裝多個Provider的路由和負(fù)載均衡，橋接注冊中心。以Invoker為中心，擴(kuò)展接口有Cluster、Directory、Router、LoadBlancce監(jiān)控層（Monitor）：RPC調(diào)用次數(shù)和調(diào)用時間監(jiān)控，以Statistics為中心，擴(kuò)展接口有MonitorFactory、Monitor和MonitorService遠(yuǎn)程調(diào)用層（Protocal）：對RPC 調(diào)用的封裝，以Invocable 和Result 為中心，擴(kuò)展接口為Protocol 、 Invoker 和Exporter 信息交換層（Exchange）：封裝請求響應(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數(shù)據(jù)序列化層（Serialize）：一些可復(fù)用的工具，擴(kuò)展接口有Serialization、ObjectInput、ObjectOutput和ThreadPoolDubbo Monitor。實現(xiàn)原理？消費(fèi)者端在發(fā)起調(diào)用之前會先經(jīng)過過濾器鏈； Provider端在收到請求時也會先經(jīng)過過濾器鏈，然后進(jìn)行實際的業(yè)務(wù)邏輯處理。默認(rèn)情況下，消費(fèi)者和提供者過濾器鏈中都有一個Monitorfilter。 MonitorFilter向DubboMonitor發(fā)送數(shù)據(jù)。 DubboMonitor將數(shù)據(jù)進(jìn)行聚合（默認(rèn)聚合1分鐘內(nèi)的統(tǒng)計數(shù)據(jù)）并臨時存儲在ConcurrentMap statsMap中，然后使用3個線程的線程池（線程名稱：DubboMonitorSendTimer）每隔1分鐘調(diào)用SimpleMonitorService來遍歷發(fā)送統(tǒng)計數(shù)據(jù)統(tǒng)計地圖。每次發(fā)送時，當(dāng)前統(tǒng)計信息的AtomicReference 都會被重置。 SimpleMonitorService將這些聚合后的數(shù)據(jù)填充到BlockingQueue隊列中（隊列大寫為100000）。 SimpleMonitorService 使用一個后臺線程（線程名稱：DubboMonitorAsyncWriteLogThread）將隊列中的數(shù)據(jù)寫入文件（線程以無限循環(huán)的形式寫入）。 SimpleMonitorService還使用包含1個線程（線程名稱：DubboMonitorTimer）的線程池，每5分鐘將文件中的統(tǒng)計數(shù)據(jù)繪制成分布式圖表。還有哪些類似于Dubbo的分布式框架？比較有名的就是Spring Cloud。 Dubbo 和Spring Cloud 是什么關(guān)系？ Dubbo是SOA時代的產(chǎn)物。其重點(diǎn)主要是服務(wù)調(diào)用、流量分發(fā)、流量監(jiān)控和熔斷。 Spring Cloud誕生于微服務(wù)架構(gòu)時代，考慮了微服務(wù)治理的方方面面。另外，由于它依賴于Spring和Spring Boot的優(yōu)勢，因此兩個框架一開始的目標(biāo)不一致。 Dubbo定位服務(wù)治理，與Spring Cloud構(gòu)建了一個生態(tài)。 Dubbo和Spring Cloud有什么區(qū)別？ Dubbo底層使用Netty等NIO框架，基于TCP協(xié)議傳輸，使用Hession序列化完成RPC通信。

Spring Cloud是基于Http協(xié)議的Rest接口進(jìn)行遠(yuǎn)程進(jìn)程調(diào)用的通信。相對而言，Http請求會有更大的消息，占用更多的帶寬。然而，REST 比RPC 更靈活。服務(wù)提供者和調(diào)用者的依賴僅依賴于一個契約，在代碼層面不存在強(qiáng)依賴。這在強(qiáng)調(diào)快速演進(jìn)的微服務(wù)環(huán)境中更加合適。至于強(qiáng)調(diào)溝通、速度還是方便、靈活，要具體情況具體考慮。 Dubbo 和Dubbox 有什么區(qū)別？ Dubbox是當(dāng)當(dāng)網(wǎng)在Dubbo停止維護(hù)后基于Dubbo構(gòu)建的擴(kuò)展項目。添加了Restful可以調(diào)用的服務(wù)，更新了開源組件等。 注冊中心Dubbo有哪些注冊中心？組播注冊中心：組播注冊中心不需要任何中心節(jié)點(diǎn)。只要使用廣播地址，就可以在網(wǎng)絡(luò)中基于組播傳輸進(jìn)行服務(wù)注冊和發(fā)現(xiàn)。 Zookeeper注冊中心：基于分布式協(xié)調(diào)系統(tǒng)Zookeeper實現(xiàn)，利用Zookeeper的watch機(jī)制實現(xiàn)數(shù)據(jù)變更。 Redis注冊中心：基于Redis實現(xiàn)，采用key/map存儲。鍵存儲服務(wù)名稱和類型。映射中的鍵存儲服務(wù)URL 和值服務(wù)過期時間?；赗edis發(fā)布/訂閱模型通知數(shù)據(jù)變化。簡單的注冊表。推薦使用Zookeeper作為注冊中心。 Dubbo的注冊中心集群宕機(jī)了。發(fā)布者和訂閱者還能通信嗎？可以進(jìn)行通信。 Dubbo啟動時，消費(fèi)者會從Zookeeper中拉取注冊生產(chǎn)者的地址接口等數(shù)據(jù)并緩存在本地。每次調(diào)用時都是根據(jù)本地存儲的地址進(jìn)行調(diào)用。 Dubbo集群提供哪些負(fù)載均衡策略？ Random LoadBalance:隨機(jī)選擇提供商策略，有助于動態(tài)調(diào)整提供商權(quán)重。截面碰撞率高，調(diào)用越多，分布越均勻。 RoundRobin LoadBalance:采用輪詢提供者選擇策略，分布均勻，但存在請求堆積的問題。 LeastActive LoadBalance: 最少活躍調(diào)用策略，解決緩慢提供者接收較少請求的問題。 ConstantHash LoadBalance: 一致性哈希策略確保具有相同參數(shù)的請求始終發(fā)送到相同的提供者。如果一臺機(jī)器宕機(jī)了，可以基于虛擬節(jié)點(diǎn)分發(fā)給其他提供者，避免提供者發(fā)生劇烈變化。默認(rèn)為隨機(jī)。

Dubbo的集群容錯方案有哪些？故障轉(zhuǎn)移集群：發(fā)生故障時自動切換。出現(xiàn)故障時，重試其他服務(wù)器。通常用于讀取操作，但重試會導(dǎo)致更長的延遲。 Failfast Cluster：快速失敗，只發(fā)起調(diào)用，失敗立即報錯。通常用于非冪等寫入操作，例如添加新記錄。 Failsafe Cluster：故障安全，當(dāng)發(fā)生異常時，被忽略。通常用于寫入審計日志等操作。故障恢復(fù)集群：自動從故障中恢復(fù)，在后臺記錄失敗的請求，并定期重新發(fā)送。通常用于消息通知操作。 Forking Cluster：并行調(diào)用多個服務(wù)器，一旦成功就返回。通常用于實時性要求較高的讀操作，但需要消耗較多的服務(wù)資源。最大并行數(shù)可以通過forks="2" 設(shè)置。廣播集群：廣播一一調(diào)用所有提供者。誰報錯，就報錯。通常用于通知所有提供者更新本地資源信息，例如緩存或日志。默認(rèn)的容錯方案是故障轉(zhuǎn)移集群。

Dubbo配置文件是如何加載到Spring中的？ Spring容器啟動時會讀取一些Spring默認(rèn)的schema和Dubbo自定義的schema。每個模式都對應(yīng)于它自己的NamespaceHandler。 NamespaceHandler使用BeanDefinitionParser來解析配置信息，并將其轉(zhuǎn)換為需要加載的bean對象！核心配置有哪些？標(biāo)簽

使用

解釋

服務(wù)配置

用于公開服務(wù)并定義服務(wù)的元信息。一個服務(wù)可以使用多種協(xié)議來暴露，一個服務(wù)也可以注冊到多個注冊中心。

參考配置

用于創(chuàng)建遠(yuǎn)程服務(wù)代理，一個引用可以指向多個注冊中心

協(xié)議配置

用于配置提供服務(wù)的協(xié)議信息。該協(xié)議由提供者指定并由消費(fèi)者被動接受。

應(yīng)用配置

用于配置當(dāng)前應(yīng)用程序信息，無論應(yīng)用程序是提供者還是消費(fèi)者

模塊配置

用于配置當(dāng)前模塊信息，可選

注冊中心配置

用于配置連接注冊中心相關(guān)信息

監(jiān)控中心配置

用于配置連接監(jiān)控中心相關(guān)信息，可選

提供商配置

當(dāng)ProtocolConfig和ServiceConfig的某個屬性沒有配置時，使用該默認(rèn)值。選修的

消費(fèi)者配置

當(dāng)未配置ReferenceConfig屬性時，使用此默認(rèn)值，可選

方法配置

用于ServiceConfig和ReferenceConfig指定方法級別的配置信息

參數(shù)配置

用于指定方法參數(shù)配置

如果是SpringBoot項目，只需要注釋或者打開Application配置文件即可！

設(shè)置Dubbo超時的方法有哪些？設(shè)置Dubbo超時有兩種方式：

在服務(wù)提供商端設(shè)置超時。在Dubbo的用戶文檔中，建議在服務(wù)器端配置盡可能多的配置，因為服務(wù)提供者比消費(fèi)者更了解其提供的服務(wù)的特性。超時時間是在服務(wù)消費(fèi)者端設(shè)置的。如果超時設(shè)置在消費(fèi)者側(cè)，則消費(fèi)者側(cè)為主，即優(yōu)先級較高。因為服務(wù)調(diào)用者可以更靈活地設(shè)置超時時間。如果消費(fèi)者超時，服務(wù)器線程將不會被定制，并且會產(chǎn)生警告。如果服務(wù)調(diào)用超時會發(fā)生什么？當(dāng)dubbo調(diào)用服務(wù)失敗時，默認(rèn)會重試兩次。通信協(xié)議Dubbo使用什么通信框架？默認(rèn)使用Netty作為通信框架。 Dubbo支持哪些協(xié)議，它們的優(yōu)缺點(diǎn)是什么？ Dubbo：單長連接、NIO異步通信，適合數(shù)據(jù)量較小的大并發(fā)服務(wù)調(diào)用，且消費(fèi)者遠(yuǎn)大于提供者。傳輸協(xié)議TCP，異步Hessian序列化。 Dubbo推薦使用dubbo協(xié)議。 RMI：采用JDK標(biāo)準(zhǔn)RMI協(xié)議實現(xiàn)。傳輸參數(shù)和返回參數(shù)對象需要實現(xiàn)Serialized接口，使用Java標(biāo)準(zhǔn)序列化機(jī)制，使用阻塞短連接，傳輸數(shù)據(jù)包大小混合。消費(fèi)者和提供者的數(shù)量幾乎相同。傳輸文件，傳輸協(xié)議TCP。多個短連接TCP協(xié)議傳輸，同步傳輸，適合常規(guī)遠(yuǎn)程服務(wù)調(diào)用和RMI互操作。當(dāng)依賴舊版本的Common-Collections 包時，Java 序列化存在安全漏洞。 WebService：基于WebService的遠(yuǎn)程調(diào)用協(xié)議，集成CXF實現(xiàn)，提供與原生WebService的互操作性。多個短連接，基于HTTP傳輸，同步傳輸，適合系統(tǒng)集成和跨語言調(diào)用。 HTTP：基于Http表單提交的遠(yuǎn)程調(diào)用協(xié)議，使用Spring的HttpInvoke實現(xiàn)。多個短連接、傳輸協(xié)議HTTP、傳入?yún)?shù)大小混合、提供者多于消費(fèi)者，需要應(yīng)用程序和瀏覽器JS調(diào)用。 Hessian：集成Hessian服務(wù)，基于HTTP通信，使用Servlet暴露服務(wù)。 Dubbo 嵌入Jetty 時默認(rèn)實現(xiàn)為服務(wù)器，提供與Hession 服務(wù)的互操作性。多個短連接，同步HTTP傳輸，Hessian序列化，傳入?yún)?shù)大，提供者比消費(fèi)者大，提供者壓力很大，文件可以傳輸。 Memcache：基于Memcache實現(xiàn)的RPC協(xié)議。 Redis：基于Redis實現(xiàn)的RPC協(xié)議。設(shè)計模式Dubbo 使用了哪些設(shè)計模式？ Dubbo框架在初始化和通信過程中采用了多種設(shè)計模式來靈活控制類加載、權(quán)限控制等功能。

工廠模式Provider導(dǎo)出服務(wù)時，會調(diào)用ServiceConfig的export方法。 ServiceConfig中有一個字段： private static final Protocol protocol=ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();復(fù)制代碼工廠模式Provider在導(dǎo)出服務(wù)時會調(diào)用ServiceConfig的export方法。 ServiceConfig中有一個字段： private static final Protocol protocol=ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();復(fù)制代碼Dubbo 中這樣的代碼還有很多。這也是一種工廠模式，只不過是利用JDKSPI機(jī)制來獲取實現(xiàn)類。這種實現(xiàn)的優(yōu)點(diǎn)是它具有高度可擴(kuò)展性。如果想擴(kuò)展實現(xiàn)，只需要在類路徑中添加一個文件即可，零代碼侵入。另外，和上面的Adaptive實現(xiàn)一樣，可以在調(diào)用時動態(tài)決定調(diào)用哪個實現(xiàn)。但是，由于這種實現(xiàn)使用了動態(tài)代理，因此會讓代碼調(diào)試比較麻煩，需要分析實際調(diào)用的實現(xiàn)類。

裝飾器模式Dubbo 在啟動階段和調(diào)用階段都大量使用了裝飾器模式。以Provider提供的調(diào)用鏈為例，具體的調(diào)用鏈代碼在ProtocolFilterWrapper的buildInvokerChain中完成。具體來說，實現(xiàn)了注解中包含group=provider的Filter，并按照順序排序。最終的調(diào)用順序是： EchoFilter - ClassLoaderFilter - GenericFilter - ContextFilter -ExecuteLimitFilter - TraceFilter - TimeoutFilter - MonitorFilter -ExceptionFilter 復(fù)制代碼更準(zhǔn)確地說，這里是裝飾器和責(zé)任鏈模式的混合。比如EchoFilter的作用就是判斷是否是echo測試請求，如果是則直接返回內(nèi)容。這是責(zé)任鏈的體現(xiàn)。而ClassLoaderFilter則只是在main函數(shù)中添加一個函數(shù)，并改變當(dāng)前線程的ClassLoader。這是一個典型的裝飾器模式。

觀察者模式Dubbo 的Provider 啟動時，需要與注冊中心進(jìn)行交互，首先注冊自己的服務(wù)，然后訂閱自己的服務(wù)。訂閱時，使用觀察者模式開啟監(jiān)聽。注冊中心會定期每隔5秒檢查是否有服務(wù)更新。如果有更新，它會向服務(wù)提供商發(fā)送通知消息。提供者收到notify消息后，會運(yùn)行NotifyListener的notify方法，執(zhí)行l(wèi)istener方法。動態(tài)代理模式Dubbo 擴(kuò)展JDK SPI 的ExtensionLoader 類的Adaptive 實現(xiàn)就是典型的動態(tài)代理實現(xiàn)。 Dubbo需要靈活控制實現(xiàn)類，即在調(diào)用階段根據(jù)參數(shù)動態(tài)決定調(diào)用哪個實現(xiàn)類。因此，利用老師成為代理類的方法可以實現(xiàn)靈活的調(diào)用。生成代理類的代碼是ExtensionLoader的createAdaptiveExtensionClassCode方法。代理類的主要邏輯是獲取URL參數(shù)中指定參數(shù)的值作為獲取實現(xiàn)類的key。運(yùn)維管理服務(wù)上線后如何兼容舊版本？版本號可用于過渡。注冊中心注冊了多個不同版本的服務(wù)。不同版本號的服務(wù)不互相引用。這有點(diǎn)類似于服務(wù)分組的概念。 Dubbo telnet 命令可以做什么？ dubbo服務(wù)發(fā)布后，我們可以使用telnet命令進(jìn)行調(diào)試和管理。 Dubbo 2.0.5及以上版本提供了telnet命令的端口支持。 Dubbo是否支持服務(wù)降級？在dubbo:reference中設(shè)置mock=“return null”。也可以將mock的值改為true，然后在與接口相同的路徑下實現(xiàn)一個Mock類。命名規(guī)則為“接口名稱+Mock”后綴。然后在Mock 類中實現(xiàn)自己的降級邏輯。 Dubbo如何優(yōu)雅關(guān)閉？ Dubbo使用JDK的ShutdownHook來完成優(yōu)雅關(guān)閉。因此，如果使用kill -9 PID等強(qiáng)制關(guān)機(jī)指令，則不會執(zhí)行優(yōu)雅關(guān)機(jī)。只有當(dāng)使用kill PID時才會執(zhí)行。 SPIDubbo SPI 和Java SPI 有什么區(qū)別？ JDK SPI：JDK 標(biāo)準(zhǔn)SPI 將立即加載所有擴(kuò)展實現(xiàn)。如果有些擴(kuò)展很耗時卻沒有被使用，那就是資源的浪費(fèi)。因此，只加載某個實現(xiàn)是不現(xiàn)實的。 DUBBO SPI： 1、在不改變Dubbo源碼的情況下擴(kuò)展Dubbo。 2. 延遲加載允許您一次只加載您想要加載的擴(kuò)展實現(xiàn)。 3.增加了對擴(kuò)展點(diǎn)IOC和AOP的支持。一個擴(kuò)展點(diǎn)可以直接將setter注入到其他擴(kuò)展點(diǎn)中。 4、Dubbo的擴(kuò)展機(jī)制可以很好的支持第三方IoC容器，默認(rèn)支持Spring Bean。其他Dubbo是否支持分布式事務(wù)？目前不支持?？梢酝ㄟ^tcc-transaction框架來實現(xiàn)。簡介：tcc-transaction是一個開源的TCC補(bǔ)償式分布式事務(wù)框架。 TCC-Transaction利用Dubbo隱式傳遞參數(shù)的功能來避免業(yè)務(wù)代碼的侵入。 Dubbo可以緩存結(jié)果嗎？以提高數(shù)據(jù)訪問的速度。 Dubbo 提供了聲明式緩存，以減少用戶添加緩存的工作量。其實它只是比普通的配置文件cache="true"多了一個標(biāo)簽而已。 Dubbo必須依賴哪些包？ Dubbo必須依賴JDK，其他可選。 Dubbo支持哪些序列化方式？默認(rèn)使用Hessian序列化，還有Duddo、FastJson、Java自帶的序列化。 Dubbo在安全方面采取了哪些措施？ Dubbo使用Token令牌來防止用戶繞過注冊中心直接連接，然后對注冊中心進(jìn)行授權(quán)管理。 Dubbo還提供服務(wù)黑白名單來控制服務(wù)允許的調(diào)用者。服務(wù)調(diào)用是否被阻塞？默認(rèn)是阻塞的，可以異步調(diào)用。如果沒有返回值的話可以這樣做。

Dubbo是基于NIO的并行調(diào)用的非阻塞實現(xiàn)?？蛻舳瞬恍枰獑佣鄠€線程來完成對多個遠(yuǎn)程服務(wù)的并行調(diào)用。與多線程相比，開銷更小，異步調(diào)用會返回一個Future對象。服務(wù)提供商如何實施故障排除？當(dāng)服務(wù)出現(xiàn)故障時，基于zookeeper的臨時節(jié)點(diǎn)原理被踢出。當(dāng)同一個服務(wù)有多個注冊時，我可以直接連接到某個服務(wù)嗎？可以直接點(diǎn)對點(diǎn)連接，只需修改配置，也可以通過telnet直接連接到某個服務(wù)。 Dubbo服務(wù)降級，失敗后重試怎么辦？您可以在dubbo:reference中設(shè)置mock=“return null”。也可以將mock的值改為true，然后在與接口相同的路徑下實現(xiàn)一個Mock類。命名規(guī)則為“接口名稱+Mock”后綴。然后在Mock 類中實現(xiàn)自己的降級邏輯。 Dubbo在使用過程中遇到了哪些問題？在注冊中心找不到對應(yīng)的服務(wù)。檢查服務(wù)實現(xiàn)類是否添加@service注解。您無法連接到注冊中心。檢查配置文件中對應(yīng)的測試IP是否正確。為什么RPC有RPChttp接口？是因為接口不多，與系統(tǒng)交互很少，是解決信息孤島初期經(jīng)常使用的通信方式；優(yōu)點(diǎn)是簡單、直接、易于開發(fā)。利用現(xiàn)成的http協(xié)議進(jìn)行傳輸。但如果是一個大型網(wǎng)站，內(nèi)部子系統(tǒng)很多，接口也很多，那么RPC框架的好處就顯現(xiàn)出來了。首先是長鏈接，每次通信不需要像http那樣經(jīng)過3次握手。減少網(wǎng)絡(luò)開銷；其次，RPC框架一般都有一個注冊中心，具有豐富的監(jiān)控和管理功能；發(fā)布、離線接口、動態(tài)擴(kuò)展等對于調(diào)用者來說是不可感知的統(tǒng)一操作。第三個是安全。最后就是最近流行的面向服務(wù)的架構(gòu)和面向服務(wù)的治理。 RPC框架是強(qiáng)有力的支撐。 Socket只是一種簡單的網(wǎng)絡(luò)通信方式。它只是在兩方之間創(chuàng)建一個溝通渠道。要實現(xiàn)rpc的功能，需要對其進(jìn)行封裝，以實現(xiàn)更多的功能。 RPC一般配合netty框架和spring自定義注解來編寫輕量級框架。事實上，netty內(nèi)部封裝了socket。較新的jdk的IO一般都是NIO，即非阻塞IO。在高并發(fā)網(wǎng)站中，RPC的優(yōu)勢RPCRPC（Remote procedure Call Protocol）遠(yuǎn)程過程調(diào)用協(xié)議是什么，就顯而易見了。它是一種在不了解底層網(wǎng)絡(luò)技術(shù)的情況下通過網(wǎng)絡(luò)向遠(yuǎn)程計算機(jī)程序請求服務(wù)的協(xié)議。簡而言之，RPC 使程序能夠訪問遠(yuǎn)程系統(tǒng)資源以及本地系統(tǒng)資源。一些比較關(guān)鍵的方面包括：通信協(xié)議、序列化、資源（接口）描述、服務(wù)框架、性能、語言支持等。簡單來說，RPC就是調(diào)用一個函數(shù)或方法（可以統(tǒng)稱為服務(wù)）在另一臺機(jī)器（服務(wù)器）上從一臺機(jī)器（客戶端）通過傳遞參數(shù)并獲取返回結(jié)果。

PRC架構(gòu)組件一個基本的RPC架構(gòu)至少應(yīng)該包含以下四個組件： 1.客戶端（Client）:服務(wù)調(diào)用者（服務(wù)消費(fèi)者） 2.客戶端存根（Client Stub）:存儲服務(wù)器地址信息。將客戶端的請求參數(shù)數(shù)據(jù)信息封裝成網(wǎng)絡(luò)消息，然后通過網(wǎng)絡(luò)傳輸發(fā)送給服務(wù)器3、服務(wù)器存根（Server Stub）:接收客戶端發(fā)送的請求消息并解包，然后調(diào)用本地服務(wù)進(jìn)行處理4、服務(wù)器（Server）:服務(wù)的真正提供者的具體調(diào)用流程： 1、服務(wù)消費(fèi)者（客戶端）通過調(diào)用本地服務(wù)來調(diào)用需要消費(fèi)的服務(wù)； 2. 客戶端存根（clientstub）收到調(diào)用請求后，負(fù)責(zé)方將

法、入?yún)⒌刃畔⑿蛄谢ńM裝）成能夠進(jìn)行網(wǎng)絡(luò)傳輸?shù)南Ⅲw； 3、客戶端存根（client stub）找到遠(yuǎn)程的服務(wù)地址，并且將消息通過網(wǎng)絡(luò)發(fā)送給服務(wù)端； 4、服務(wù)端存根（server stub）收到消息后進(jìn)行解碼（反序列化操作）； 5、服務(wù)端存根（server stub）根據(jù)解碼結(jié)果調(diào)用本地的服務(wù)進(jìn)行相關(guān)處理； 6、本地服務(wù)執(zhí)行具體業(yè)務(wù)邏輯并將處理結(jié)果返回給服務(wù)端存根（server stub）； 7、服務(wù)端存根（server stub）將返回結(jié)果重新打包成消息（序列化）并通過網(wǎng)絡(luò)發(fā)送至消費(fèi)方； 8、客戶端存根（client stub）接收到消息，并進(jìn)行解碼（反序列化）； 9、服務(wù)消費(fèi)方得到最終結(jié)果；而RPC框架的實現(xiàn)目標(biāo)則是將上面的第2-10步完好地封裝起來，也就是把調(diào)用、編碼/解碼的過程給封裝起來，讓用戶感覺上像調(diào)用本地服務(wù)一樣的調(diào)用遠(yuǎn)程服務(wù)。 RPC和SOA、SOAP、REST的區(qū)別1、REST 可以看著是HTTP協(xié)議的一種直接應(yīng)用，默認(rèn)基于JSON作為傳輸格式,使用簡單,學(xué)習(xí)成本低效率高,但是安全性較低。2、SOAP SOAP是一種數(shù)據(jù)交換協(xié)議規(guī)范,是一種輕量的、簡單的、基于XML的協(xié)議的規(guī)范。而SOAP可以看著是一個重量級的協(xié)議，基于XML、SOAP在安全方面是通過使用XML-Security和XML-Signature兩個規(guī)范組成了WS-Security來實現(xiàn)安全控制的,當(dāng)前已經(jīng)得到了各個廠商的支持 。 它有什么優(yōu)點(diǎn)？簡單總結(jié)為：易用、靈活、跨語言、跨平臺。3、SOA 面向服務(wù)架構(gòu)，它可以根據(jù)需求通過網(wǎng)絡(luò)對松散耦合的粗粒度應(yīng)用組件進(jìn)行分布式部署、組合和使用。服務(wù)層是SOA的基礎(chǔ)，可以直接被應(yīng)用調(diào)用，從而有效控制系統(tǒng)中與軟件代理交互的人為依賴性。 SOA是一種粗粒度、松耦合服務(wù)架構(gòu)，服務(wù)之間通過簡單、精確定義接口進(jìn)行通訊，不涉及底層編程接口和通訊模型。SOA可以看作是B/S模型、XML（標(biāo)準(zhǔn)通用標(biāo)記語言的子集）/Web Service技術(shù)之后的自然延伸。4、REST 和 SOAP、RPC 有何區(qū)別呢 沒什么太大區(qū)別，他們的本質(zhì)都是提供可支持分布式的基礎(chǔ)服務(wù)，最大的區(qū)別在于他們各自的的特點(diǎn)所帶來的不同應(yīng)用場景 。RPC框架需要解決的問題？1、如何確定客戶端和服務(wù)端之間的通信協(xié)議？2、如何更高效地進(jìn)行網(wǎng)絡(luò)通信？3、服務(wù)端提供的服務(wù)如何暴露給客戶端？4、客戶端如何發(fā)現(xiàn)這些暴露的服務(wù)？5、如何更高效地對請求對象和響應(yīng)結(jié)果進(jìn)行序列化和反序列化操作？RPC的實現(xiàn)基礎(chǔ)？1、需要有非常高效的網(wǎng)絡(luò)通信，比如一般選擇Netty作為網(wǎng)絡(luò)通信框架；2、需要有比較高效的序列化框架，比如谷歌的Protobuf序列化框架；3、可靠的尋址方式（主要是提供服務(wù)的發(fā)現(xiàn)），比如可以使用Zookeeper來注冊服務(wù)等等；4、如果是帶會話（狀態(tài)）的RPC調(diào)用，還需要有會話和狀態(tài)保持的功能；RPC使用了哪些關(guān)鍵技術(shù)？1、動態(tài)代理 生成Client Stub（客戶端存根）和Server Stub（服務(wù)端存根）的時候需要用到Java動態(tài)代理技術(shù)，可以使用JDK提供的原生的動態(tài)代理機(jī)制，也可以使用開源的：CGLib代理，Javassist字節(jié)碼生成技術(shù)。2、序列化和反序列化 在網(wǎng)絡(luò)中，所有的數(shù)據(jù)都將會被轉(zhuǎn)化為字節(jié)進(jìn)行傳送，所以為了能夠使參數(shù)對象在網(wǎng)絡(luò)中進(jìn)行傳輸，需要對這些參數(shù)進(jìn)行序列化和反序列化操作。 序列化：把對象轉(zhuǎn)換為字節(jié)序列的過程稱為對象的序列化，也就是編碼的過程。反序列化：把字節(jié)序列恢復(fù)為對象的過程稱為對象的反序列化，也就是解碼的過程。 目前比較高效的開源序列化框架：如Kryo、FastJson和Protobuf等。 反序列化：把字節(jié)序列恢復(fù)為對象的過程稱為對象的反序列化，也就是解碼的過程。 目前比較高效的開源序列化框架：如Kryo、FastJson和Protobuf等。3、NIO通信 出于并發(fā)性能的考慮，傳統(tǒng)的阻塞式 IO 顯然不太合適，因此我們需要異步的 IO，即 NIO。Java 提供了 NIO 的解決方案，Java 7 也提供了更優(yōu)秀的 NIO.2 支持。可以選擇Netty或者M(jìn)INA來解決NIO數(shù)據(jù)傳輸?shù)膯栴}。4、服務(wù)注冊中心 可選：Redis、Zookeeper、Consul 、Etcd。一般使用ZooKeeper提供服務(wù)注冊與發(fā)現(xiàn)功能，解決單點(diǎn)故障以及分布式部署的問題(注冊中心)。主流RPC框架有哪些1、RMI 利用java.rmi包實現(xiàn)，基于Java遠(yuǎn)程方法協(xié)議(Java Remote Method Protocol) 和java的原生序列化。2、Hessian 是一個輕量級的remoting onhttp工具，使用簡單的方法提供了RMI的功能。 基于HTTP協(xié)議，采用二進(jìn)制編解碼。3、protobuf-rpc-pro 是一個Java類庫，提供了基于 Google 的 Protocol Buffers 協(xié)議的遠(yuǎn)程方法調(diào)用的框架?；?Netty 底層的 NIO 技術(shù)。支持 TCP 重用/ keep-alive、SSL加密、RPC 調(diào)用取消操作、嵌入式日志等功能。4、Thrift 是一種可伸縮的跨語言服務(wù)的軟件框架。它擁有功能強(qiáng)大的代碼生成引擎，無縫地支持C + +，C#，Java，Python和PHP和Ruby。thrift允許你定義一個描述文件，描述數(shù)據(jù)類型和服務(wù)接口。依據(jù)該文件，編譯器方便地生成RPC客戶端和服務(wù)器通信代碼。 最初由facebook開發(fā)用做系統(tǒng)內(nèi)個語言之間的RPC通信，2007年由facebook貢獻(xiàn)到apache基金 ，現(xiàn)在是apache下的opensource之一 。支持多種語言之間的RPC方式的通信：php語言client可以構(gòu)造一個對象，調(diào)用相應(yīng)的服務(wù)方法來調(diào)用java語言的服務(wù)，跨越語言的C/S RPC調(diào)用。底層通訊基于SOCKET。5、Avro 出自Hadoop之父Doug Cutting, 在Thrift已經(jīng)相當(dāng)流行的情況下推出Avro的目標(biāo)不僅是提供一套類似Thrift的通訊中間件,更是要建立一個新的，標(biāo)準(zhǔn)性的云計算的數(shù)據(jù)交換和存儲的Protocol。支持HTTP，TCP兩種協(xié)議。6、Dubbo Dubbo是 阿里巴巴公司開源的一個高性能優(yōu)秀的服務(wù)框架，使得應(yīng)用可通過高性能的 RPC 實現(xiàn)服務(wù)的輸出和輸入功能，可以和 Spring框架無縫集成。RPC的實現(xiàn)原理架構(gòu)圖也就是說兩臺服務(wù)器A，B，一個應(yīng)用部署在A服務(wù)器上，想要調(diào)用B服務(wù)器上應(yīng)用提供的函數(shù)/方法，由于不在一個內(nèi)存空間，不能直接調(diào)用，需要通過網(wǎng)絡(luò)來表達(dá)調(diào)用的語義和傳達(dá)調(diào)用的數(shù)據(jù)。比如說，A服務(wù)器想調(diào)用B服務(wù)器上的一個方法： 1、建立通信 首先要解決通訊的問題：即A機(jī)器想要調(diào)用B機(jī)器，首先得建立起通信連接。 主要是通過在客戶端和服務(wù)器之間建立TCP連接，遠(yuǎn)程過程調(diào)用的所有交換的數(shù)據(jù)都在這個連接里傳輸。連接可以是按需連接，調(diào)用結(jié)束后就斷掉，也可以是長連接，多個遠(yuǎn)程過程調(diào)用共享同一個連接。 通常這個連接可以是按需連接（需要調(diào)用的時候就先建立連接，調(diào)用結(jié)束后就立馬斷掉），也可以是長連接（客戶端和服務(wù)器建立起連接之后保持長期持有，不管此時有無數(shù)據(jù)包的發(fā)送，可以配合心跳檢測機(jī)制定期檢測建立的連接是否存活有效），多個遠(yuǎn)程過程調(diào)用共享同一個連接。2、服務(wù)尋址 要解決尋址的問題，也就是說，A服務(wù)器上的應(yīng)用怎么告訴底層的RPC框架，如何連接到B服務(wù)器（如主機(jī)或IP地址）以及特定的端口，方法的名稱名稱是什么。 通常情況下我們需要提供B機(jī)器（主機(jī)名或IP地址）以及特定的端口，然后指定調(diào)用的方法或者函數(shù)的名稱以及入?yún)⒊鰠⒌刃畔?，這樣才能完成服務(wù)的一個調(diào)用。 可靠的尋址方式（主要是提供服務(wù)的發(fā)現(xiàn)）是RPC的實現(xiàn)基石，比如可以采用Redis或者Zookeeper來注冊服務(wù)等等。 2.1、從服務(wù)提供者的角度看： 當(dāng)服務(wù)提供者啟動的時候，需要將自己提供的服務(wù)注冊到指定的注冊中心，以便服務(wù)消費(fèi)者能夠通過服務(wù)注冊中心進(jìn)行查找； 當(dāng)服務(wù)提供者由于各種原因致使提供的服務(wù)停止時，需要向注冊中心注銷停止的服務(wù)； 服務(wù)的提供者需要定期向服務(wù)注冊中心發(fā)送心跳檢測，服務(wù)注冊中心如果一段時間未收到來自服務(wù)提供者的心跳后，認(rèn)為該服務(wù)提供者已經(jīng)停止服務(wù)，則將該服務(wù)從注冊中心上去掉。 2.2、從調(diào)用者的角度看： 服務(wù)的調(diào)用者啟動的時候根據(jù)自己訂閱的服務(wù)向服務(wù)注冊中心查找服務(wù)提供者的地址等信息； 當(dāng)服務(wù)調(diào)用者消費(fèi)的服務(wù)上線或者下線的時候，注冊中心會告知該服務(wù)的調(diào)用者； 服務(wù)調(diào)用者下線的時候，則取消訂閱。3、網(wǎng)絡(luò)傳輸 3.1、序列化 當(dāng)A機(jī)器上的應(yīng)用發(fā)起一個RPC調(diào)用時，調(diào)用方法和其入?yún)⒌刃畔⑿枰ㄟ^底層的網(wǎng)絡(luò)協(xié)議如TCP傳輸?shù)紹機(jī)器，由于網(wǎng)絡(luò)協(xié)議是基于二進(jìn)制的，所有我們傳輸?shù)膮?shù)數(shù)據(jù)都需要先進(jìn)行序列化（Serialize）或者編組（marshal）成二進(jìn)制的形式才能在網(wǎng)絡(luò)中進(jìn)行傳輸。然后通過尋址操作和網(wǎng)絡(luò)傳輸將序列化或者編組之后的二進(jìn)制數(shù)據(jù)發(fā)送給B機(jī)器。 3.2、反序列化 當(dāng)B機(jī)器接收到A機(jī)器的應(yīng)用發(fā)來的請求之后，又需要對接收到的參數(shù)等信息進(jìn)行反序列化操作（序列化的逆操作），即將二進(jìn)制信息恢復(fù)為內(nèi)存中的表達(dá)方式，然后再找到對應(yīng)的方法（尋址的一部分）進(jìn)行本地調(diào)用（一般是通過生成代理Proxy去調(diào)用, 通常會有JDK動態(tài)代理、CGLIB動態(tài)代理、Javassist生成字節(jié)碼技術(shù)等），之后得到調(diào)用的返回值。4、服務(wù)調(diào)用 B機(jī)器進(jìn)行本地調(diào)用（通過代理Proxy和反射調(diào)用）之后得到了返回值，此時還需要再把返回值發(fā)送回A機(jī)器，同樣也需要經(jīng)過序列化操作，然后再經(jīng)過網(wǎng)絡(luò)傳輸將二進(jìn)制數(shù)據(jù)發(fā)送回A機(jī)器，而當(dāng)A機(jī)器接收到這些返回值之后，則再次進(jìn)行反序列化操作，恢復(fù)為內(nèi)存中的表達(dá)方式，最后再交給A機(jī)器上的應(yīng)用進(jìn)行相關(guān)處理（一般是業(yè)務(wù)邏輯處理操作）。通常，經(jīng)過以上四個步驟之后，一次完整的RPC調(diào)用算是完成了，另外可能因為網(wǎng)絡(luò)抖動等原因需要重試等。