溫馨提示×
您好，登錄后才能下訂單哦！
點擊 登錄注冊 即表示同意《億速云用戶服務條款》
您好，登錄后才能下訂單哦！
本篇內容介紹了“2021有哪些最新版的Dubbo面試題”的有關知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領大家學習一下如何處理這些情況吧！希望大家仔細閱讀，能夠學有所成！
隨著服務化的進一步發展，服務越來越多，服務之間的調用和依賴關系也越來越復雜，誕生了面向服務的架構體系(SOA)，也因此衍生出了一系列相應的技術，如對服務提供、服務調用、連接處理、通信協議、序列化方式、服務發現、服務路由、日志輸出等行為進行封裝的服務框架。就這樣為分布式系統的服務治理框架就出現了，Dubbo 也就這樣產生了。
Dubbo 是一款高性能、輕量級的開源 RPC 框架，提供服務自動注冊、自動發現等高效服務治理方案， 可以和 Spring 框架無縫集成。
透明化的遠程方法調用：就像調用本地方法一樣調用遠程方法，只需簡單配置，沒有任何API侵入。
軟負載均衡及容錯機制：可在內網替代 F5 等硬件負載均衡器，降低成本，減少單點。
服務自動注冊與發現：不再需要寫死服務提供方地址，注冊中心基于接口名查詢服務提供者的IP地址，并且能夠平滑添加或刪除服務提供者。
Remoting：網絡通信框架，提供對多種NIO框架抽象封裝，包括“同步轉異步”和“請求-響應”模式的信息交換方式。Cluster：服務框架，提供基于接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集群支持。
Registry：服務注冊，基于注冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方可以平滑增加或減少機器。
Provider：暴露服務的服務提供方
Consumer：調用遠程服務消費方
Registry：服務注冊與發現注冊中心
Monitor：監控中心和訪問調用統計
Container：服務運行容器
服務容器Container負責啟動，加載，運行服務提供者。
服務提供者Provider在啟動時，向注冊中心注冊自己提供的服務。
服務消費者Consumer在啟動時，向注冊中心訂閱自己所需的服務。
注冊中心Registry返回服務提供者地址列表給消費者，如果有變更，注冊中心將基于長連接推送變更數據給消費者。
服務消費者Consumer，從提供者地址列表中，基于軟負載均衡算法，選一臺提供者進行調用，如果調用失敗，再選另一臺調用。
服務消費者Consumer和提供者Provider，在內存中累計調用次數和調用時間，定時每分鐘發送一次統計數據到監控中心Monitor。
接口服務層（Service）：該層與業務邏輯相關，根據 provider 和 consumer 的業務設計對應的接口和實現
配置層（Confifig）：對外配置接口，以 ServiceConfifig 和 ReferenceConfifig 為中心
服務代理層（Proxy）：服務接口透明代理，生成服務的客戶端 Stub 和 服務端的 Skeleton，以
ServiceProxy 為中心，擴展接口為 ProxyFactory
服務注冊層（Registry）：封裝服務地址的注冊和發現，以服務 URL 為中心，擴展接口為
RegistryFactory、Registry、RegistryService
路由層（Cluster）：封裝多個提供者的路由和負載均衡，并橋接注冊中心，以Invoker 為中心，擴展接口為 Cluster、Directory、Router 和 LoadBlancce
監控層（Monitor）：RPC 調用次數和調用時間監控，以 Statistics 為中心，擴展接口為MonitorFactory、Monitor 和 MonitorService
遠程調用層（Protocal）：封裝 RPC 調用，以 Invocation 和 Result 為中心，擴展接口為Protocal、Invoker 和 Exporter
信息交換層（Exchange）：封裝請求響應模式，同步轉異步。以 Request 和Response 為中心，
擴展接口為 Exchanger、ExchangeChannel、ExchangeClient 和 ExchangeServer
網絡 傳輸 層（Transport）：抽象 mina 和 netty 為統一接口，以 Message 為中心，擴展接口為Channel、Transporter、Client、Server 和 Codec
數據序列化層（Serialize）：可復用的一些工具，擴展接口為 Serialization、ObjectInput、 ObjectOutput 和 ThreadPool
Consumer 端在發起調用之前會先走 fifilter 鏈；provider 端在接收到請求時也是先走 fifilter 鏈，然后才進行真正的業務邏輯處理。默認情況下，在 consumer 和 provider 的 fifilter 鏈中都會Monitorfifilter。
MonitorFilter 向 DubboMonitor 發送數據
DubboMonitor 將數據進行聚合后（默認聚合 1min 中的統計數據）暫存到ConcurrentMap<Statistics, AtomicReference> statisticsMap，然后使用一個含有 3 個線程（線程名字：DubboMonitorSendTimer）的線程池每隔 1min 鐘，調用 SimpleMonitorService 遍歷statisticsMap 中的統計數據，每發送完畢一個，就重置當前的 Statistics 的AtomicReference
SimpleMonitorService 將這些聚合數據塞入 BlockingQueue queue 中（隊列大寫為 100000）
SimpleMonitorService 使用一個后臺線程（線程名為：DubboMonitorAsyncWriteLogThread）將 queue 中的數據寫入文件（該線程以死循環的形式來寫）
SimpleMonitorService 還會使用一個含有 1 個線程（線程名字：DubboMonitorTimer）的線程池每隔 5min 鐘，將文件中的統計數據畫成圖表
比較著名的就是 Spring Cloud。
Dubbo 是 SOA 時代的產物，它的關注點主要在于服務的調用，流量分發、流量監控和熔斷。而Spring Cloud 誕生于微服務架構時代，考慮的是微服務治理的方方面面，另外由于依托了
Spring、Spring Boot 的優勢之上，兩個框架在開始目標就不一致，Dubbo 定位服務治理、Spring Cloud 是打造一個生態。
Dubbox 是繼 Dubbo 停止維護后，當當網基于 Dubbo 做的一個擴展項目，如加了服務可 Restful調用，更新了開源組件等。
Multicast 注冊中心：Multicast 注冊中心不需要任何中心節點，只要廣播地址，就能進行服務注冊和發現,基于網絡中組播傳輸實現。
Zookeeper 注冊中心：基于分布式協調系統 Zookeeper 實現，采用 Zookeeper 的 watch 機制實現數據變更。
Redis 注冊中心：基于 Redis 實現，采用 key/map 存儲，key 存儲服務名和類型，map 中 key 存儲服務 url，value 服務過期時間。基于 Redis 的發布/訂閱模式通知數據變更。
Simple 注冊中心。
推薦使用 Zookeeper 作為注冊中心
可以通訊。啟動 Dubbo 時，消費者會從 Zookeeper 拉取注冊的生產者的地址接口等數據，緩存在本地。每次調用時，按照本地存儲的地址進行調用。
Random LoadBalance: 隨機選取提供者策略，有利于動態調整提供者權重。截面碰撞率高，調用次數越多，分布越均勻。
RoundRobin LoadBalance: 輪循選取提供者策略，平均分布，但是存在請求累積的問題。
LeastActive LoadBalance: 最少活躍調用策略，解決慢提供者接收更少的請求。
ConstantHash LoadBalance: 一致性 Hash 策略，使相同參數請求總是發到同一提供者，一臺機器宕機，可以基于虛擬節點，分攤至其他提供者，避免引起提供者的劇烈變動。
Failover Cluster：失敗自動切換，當出現失敗，重試其它服務器。通常用于讀操作，但重試會帶來更長延遲。
Failfast Cluster：快速失敗，只發起一次調用，失敗立即報錯。通常用于非冪等性的寫操作，比如新增記錄。
Failsafe Cluster：失敗安全，出現異常時，直接忽略。通常用于寫入審計日志等操作。
Failback Cluster：失敗自動恢復，后臺記錄失敗請求，定時重發。通常用于消息通知操作。
Forking Cluster：并行調用多個服務器，只要一個成功即返回。通常用于實時性要求較高的讀操作，但需要浪費更多服務資源。可通過 forks=”2″ 來設置最大并行數。
Broadcast Cluster：廣播調用所有提供者，逐個調用，任意一臺報錯則報錯 。通常用于通知所有提供者更新緩存或日志等本地資源信息。
Spring 容器在啟動的時候，會讀取到 Spring 默認的一些 schema 以及 Dubbo 自定義的schema，每個 schema 都會對應一個自己的 NamespaceHandler，NamespaceHandler 里面通過 BeanDefifinitionParser 來解析配置信息并轉化為需要加載的 bean 對象！
Dubbo 超時設置有兩種方式：
服務提供者端設置超時時間，在Dubbo的用戶文檔中，推薦如果能在服務端多配置就盡量多配置，因為服務提供者比消費者更清楚自己提供的服務特性。
服務消費者端設置超時時間，如果在消費者端設置了超時時間，以消費者端為主，即優先級更高。因為服務調用方設置超時時間控制性更靈活。如果消費方超時，服務端線程不會定制，會產生警告。
dubbo 在調用服務不成功時，默認是會重試兩次。
默認使用 Netty 作為通訊框架。
Dubbo： 單一長連接和 NIO 異步通訊，適合大并發小數據量的服務調用，以及消費者遠大于提供者。傳輸協議 TCP，異步 Hessian 序列化。Dubbo推薦使用dubbo協議。
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：基于 Memcache實現的 RPC 協議。
Redis：基于 Redis 實現的RPC協議
Dubbo 框架在初始化和通信過程中使用了多種設計模式，可靈活控制類加載、權限控制等功能。
可以用版本號（version）過渡，多個不同版本的服務注冊到注冊中心，版本號不同的服務相互間不引用。這個和服務分組的概念有一點類似。
dubbo 服務發布之后，我們可以利用 telnet 命令進行調試、管理。Dubbo2.0.5 以上版本服務提供端口支持 telnet 命令
以通過 dubbo:reference 中設置 mock=“return null”。mock 的值也可以修改為 true，然后再跟接口同一個路徑下實現一個 Mock 類，命名規則是 “接口名稱+Mock” 后綴。然后在 Mock 類里實現自己的降級邏輯
Dubbo 是通過 JDK 的 ShutdownHook 來完成優雅停機的，所以如果使用kill -9 PID 等強制關閉指令，是不會執行優雅停機的，只有通過 kill PID 時，才會執行。
JDK SPI：
JDK 標準的 SPI 會一次性加載所有的擴展實現，如果有的擴展很耗時，但也沒用上，很浪費資源。所以只希望加載某個的實現，就不現實了
DUBBO SPI：
1、對 Dubbo 進行擴展，不需要改動 Dubbo 的源碼
2、延遲加載，可以一次只加載自己想要加載的擴展實現。
3、增加了對擴展點 IOC 和 AOP 的支持，一個擴展點可以直接 setter 注入其它擴展點。
4、Dubbo 的擴展機制能很好的支持第三方 IoC 容器，默認支持 Spring Bean。
目前暫時不支持，可與通過 tcc-transaction 框架實現
介紹：tcc-transaction 是開源的 TCC 補償性分布式事務框架
TCC-Transaction 通過 Dubbo 隱式傳參的功能，避免自己對業務代碼的入侵。
為了提高數據訪問的速度。Dubbo 提供了聲明式緩存，以減少用戶加緩存的工作量<dubbo:reference cache=“true” />
其實比普通的配置文件就多了一個標簽 cache=“true”
Dubbo 必須依賴 JDK，其他為可選。
默認使用 Hessian 序列化，還有 Duddo、FastJson、Java 自帶序列化。
Dubbo 通過 Token 令牌防止用戶繞過注冊中心直連，然后在注冊中心上管理授權。
Dubbo 還提供服務黑白名單，來控制服務所允許的調用方。
默認是阻塞的，可以異步調用，沒有返回值的可以這么做。Dubbo 是基于 NIO 的非阻塞實現并行調用，客戶端不需要啟動多線程即可完成并行調用多個遠程服務，相對多線程開銷較小，異步調用會返回一個 Future 對象。
服務失效踢出基于 zookeeper 的臨時節點原理。
可以點對點直連，修改配置即可，也可以通過 telnet 直接某個服務。
可以通過 dubbo:reference 中設置 mock=“return null”。mock 的值也可以修改為 true，然后再跟接口同一個路徑下實現一個 Mock 類，命名規則是 “接口名稱+Mock” 后綴。然后在 Mock 類里實現自己的降級邏輯
在注冊中心找不到對應的服務,檢查 service 實現類是否添加了@service 注解無法連接到注冊中心,檢查配置文件中的對應的測試 ip 是否正確
http接口是在接口不多、系統與系統交互較少的情況下，解決信息孤島初期常使用的一種通信手段；優點就是簡單、直接、開發方便。利用現成的http協議進行傳輸。但是如果是一個大型的網站，內部子系統較多、接口非常多的情況下，RPC框架的好處就顯示出來了，首先就是長鏈接，不必每次通信都要像http一樣去3次握手什么的，減少了網絡開銷；其次就是RPC框架一般都有注冊中心，有豐富的監控管理；發布、下線接口、動態擴展等，對調用方來說是無感知、統一化的操作。第三個來說就是安全性。最后就是最近流行的服務化架構、服務化治理，RPC框架是一個強力的支撐。
socket只是一個簡單的網絡通信方式，只是創建通信雙方的通信通道，而要實現rpc的功能，還需要對其進行封裝，以實現更多的功能。
RPC一般配合netty框架、spring自定義注解來編寫輕量級框架，其實netty內部是封裝了socket的，較新的jdk的IO一般是NIO，即非阻塞IO，在高并發網站中，RPC的優勢會很明顯
一個基本的RPC架構里面應該至少包含以下4個組件：
1、客戶端（Client）:服務調用方（服務消費者）
2、客戶端存根（Client Stub）:存放服務端地址信息，將客戶端的請求參數數據信息打包成網絡消息，再通過網絡傳輸發送給服務端
3、服務端存根（Server Stub）:接收客戶端發送過來的請求消息并進行解包，然后再調用本地服務進行處理4、服務端（Server）:服務的真正提供者
具體調用過程：
1、服務消費者（client客戶端）通過調用本地服務的方式調用需要消費的服務；
2、客戶端存根（client stub）接收到調用請求后負責將方法、入參等信息序列化（組裝）成能夠進行網絡傳輸的消息體；
3、客戶端存根（client stub）找到遠程的服務地址，并且將消息通過網絡發送給服務端；
4、服務端存根（server stub）收到消息后進行解碼（反序列化操作）；
5、服務端存根（server stub）根據解碼結果調用本地的服務進行相關處理；
6、本地服務執行具體業務邏輯并將處理結果返回給服務端存根（server stub）；
7、服務端存根（server stub）將返回結果重新打包成消息（序列化）并通過網絡發送至消費方；
8、客戶端存根（client stub）接收到消息，并進行解碼（反序列化）；
9、服務消費方得到最終結果；
1、REST
可以看著是HTTP協議的一種直接應用，默認基于JSON作為傳輸格式,使用簡單,學習成本低效率高,但是安全性較低。
2、SOAP
SOAP是一種數據交換協議規范,是一種輕量的、簡單的、基于XML的協議的規范。而SOAP可以看著是一個重量級的協議，基于XML、SOAP在安全方面是通過使用XML-Security和XML-Signature兩個規范組成了WS-Security來實現安全控制的,當前已經得到了各個廠商的支持 。它有什么優點？簡單總結為：易用、靈活、跨語言、跨平臺。
3、SOA
面向服務架構，它可以根據需求通過網絡對松散耦合的粗粒度應用組件進行分布式部署、組合和使用。服務層是SOA的基礎，可以直接被應用調用，從而有效控制系統中與軟件代理交互的人為依賴性。SOA是一種粗粒度、松耦合服務架構，服務之間通過簡單、精確定義接口進行通訊，不涉及底層程接口和通訊模型。SOA可以看作是B/S模型、XML（標準通用標記語言的子集）/Web Service技術之后的自然延伸。
4、REST 和 SOAP、RPC 有何區別呢?
沒什么太大區別，他們的本質都是提供可支持分布式的基礎服務，最大的區別在于他們各自的的特點所帶來的不同應用場景 。
1、如何確定客戶端和服務端之間的通信協議？
2、如何更高效地進行網絡通信？
3、服務端提供的服務如何暴露給客戶端？
4、客戶端如何發現這些暴露的服務？
5、如何更高效地對請求對象和響應結果進行序列化和反序列化操作？
1、需要有非常高效的網絡通信，比如一般選擇Netty作為網絡通信框架；
2、需要有比較高效的序列化框架，比如谷歌的Protobuf序列化框架；
3、可靠的尋址方式（主要是提供服務的發現），比如可以使用Zookeeper來注冊服務等等；
4、如果是帶會話（狀態）的RPC調用，還需要有會話和狀態保持的功能；
1、動態代理
生成Client Stub（客戶端存根）和Server Stub（服務端存根）的時候需要用到Java動態代理技術，可以使用JDK提供的原生的動態代理機制，也可以使用開源的：CGLib代理，Javassist字節碼生成技術。
2、序列化和反序列化
在網絡中，所有的數據都將會被轉化為字節進行傳送，所以為了能夠使參數對象在網絡中進行傳輸，需要對這些參數進行序列化和反序列化操作。序列化：把對象轉換為字節序列的過程稱為對象的序列化，也就是編碼的過程。反序列化：把字節序列恢復為對象的過程稱為對象的反序列化，也就是解碼的過程。 目前比較高效的開源序列化框架：如Kryo、FastJson和Protobuf等。反序列化：把字節序列恢復為對象的過程稱為對象的反序列化，也就是解碼的過程。 目前比較高效的開源序列化框架：如Kryo、FastJson和Protobuf等。
3、NIO通信
出于并發性能的考慮，傳統的阻塞式 IO 顯然不太合適，因此我們需要異步的 IO，即 NIO。Java 提供了 NIO 的解決方案，Java 7 也提供了更優秀的 NIO.2 支持。可以選擇Netty或者MINA來解決NIO數據 傳輸的問題。
4、服務注冊中心
可選：Redis、Zookeeper、Consul 、Etcd。一般使用ZooKeeper提供服務注冊與發現功能，解決單點故障以及分布式部署的問題(注冊中心)。
也就是說兩臺服務器A，B，一個應用部署在A服務器上，想要調用B服務器上應用提供的函數/方法，由于不在一個內存空間，不能直接調用，需要通過網絡來表達調用的語義和傳達調用的數據。
比如說，A服務器想調用B服務器上的一個方法：
1、建立通信
首先要解決通訊的問題：即A機器想要調用B機器，首先得建立起通信連接。主要是通過在客戶端和服務器之間建立TCP連接，遠程過程調用的所有交換的數據都在這個連接里傳輸。連接可以是按需連接，調用結束后就斷掉，也可以是長連接，多個遠程過程調用共享同一個連接。通常這個連接可以是按需連接（需要調用的時候就先建立連接，調用結束后就立馬斷掉），也可以是長 連接（客戶端和服務器建立起連接之后保持長期持有，不管此時有無數據包的發送，可以配合心跳檢測機制定期檢測建立的連接是否存活有效），多個遠程過程調用共享同一個連接。
2、服務尋址
要解決尋址的問題，也就是說，A服務器上的應用怎么告訴底層的RPC框架，如何連接到B服務器（如主機或IP地址）以及特定的端口，方法的名稱名稱是什么。通常情況下我們需要提供B機器（主機名或IP地址）以及特定的端口，然后指定調用的方法或者函數的名稱以及入參出參等信息，這樣才能完成服務的一個調用。可靠的尋址方式（主要是提供服務的發現）是RPC的實現基石，比如可以采用Redis或者Zookeeper來注冊服務等等。
2.1、從服務提供者的角度看：
當服務提供者啟動的時候，需要將自己提供的服務注冊到指定的注冊中心，以便服務消費者能夠通過服務注冊中心進行查找；當服務提供者由于各種原因致使提供的服務停止時，需要向注冊中心注銷停止的服務；服務的提供者需要定期向服務注冊中心發送心跳檢測，服務注冊中心如果一段時間未收到來自服務提供者的心跳后，認為該服務提供者已經停止服務，則將該服務從注冊中心上去掉。
2.2、從調用者的角度看：
服務的調用者啟動的時候根據自己訂閱的服務向服務注冊中心查找服務提供者的地址等信息；
當服務調用者消費的服務上線或者下線的時候，注冊中心會告知該服務的調用者；
服務調用者下線的時候，則取消訂閱。
3、網絡傳輸
3.1、序列化
當A機器上的應用發起一個RPC調用時，調用方法和其入參等信息需要通過底層的網絡協議如TCP傳輸到B機器，由于網絡協議是基于二進制的，所有我們傳輸的參數數據都需要先進行序列化（Serialize）或者編組（marshal）成二進制的形式才能在網絡中進行傳輸。然后通過尋址操作和網絡傳輸將序列化或者編組之后的二進制數據發送給B機器。
3.2、反序列化
當B機器接收到A機器的應用發來的請求之后，又需要對接收到的參數等信息進行反序列化操作（序列化的逆操作），即將二進制信息恢復為內存中的表達方式，然后再找到對應的方法（尋址的一部分）進行本地調用（一般是通過生成代理Proxy去調用, 通常會有JDK動態代理、CGLIB動態代理、Javassist生成字節碼技術等），之后得到調用的返回值。
4、服務調用
B機器進行本地調用（通過代理Proxy和反射調用）之后得到了返回值，此時還需要再把返回值發送回A機器，同樣也需要經過序列化操作，然后再經過網絡傳輸將二進制數據發送回A機器，而當A機器接收到這些返回值之后，則再次進行反序列化操作，恢復為內存中的表達方式，最后再交給A機器上的應用進行相關處理（一般是業務邏輯處理操作）。
“2021有哪些最新版的Dubbo面試題”的內容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站，小編將為大家輸出更多高質量的實用文章！
免責聲明：本站發布的內容（圖片、視頻和文字）以原創、轉載和分享為主，文章觀點不代表本網站立場，如果涉及侵權請聯系站長郵箱：is@yisu.com進行舉報，并提供相關證據，一經查實，將立刻刪除涉嫌侵權內容。
