dubbo負載均衡演算法

⑴ bbo有哪些負載均衡演算法怎麼實現的負載均衡演算法bbo有幾層

常見的有LVS、Nginx和HAProxy，者者介紹分別如下：
LVS：使用集群技術和Linux操作系統實現一個高性能、高可用的伺服器，它具有很好的可伸縮性（Scalability)、可靠性（Reliability)和可管理性（Manageability)，感謝章文嵩博士為我們提供如此強大實用的開源軟體。
LVS的特點是：
1、抗負載能力強、是工作在網路4層之上僅作分發之用，沒有流量的產生，這個特點也決定了它在負載均衡軟體里的性能最強的；

2、配置性比較低，這是一個缺點也是一個優點，因為沒有可太多配置的東西，所以並不需要太多接觸，大大減少了人為出錯的幾率；
3、工作穩定，自身有完整的雙機熱備方案；
4、無流量，保證了均衡器IO的性能不會收到大流量的影響；

5、應用范圍比較廣，可以對所有應用做負載均衡；

6、軟體本身不支持正則處理，不能做動靜分離。

Nginx的特點是：
1、工作在網路的7層之上，可以針對http應用做一些分流的策略；
2、Nginx對網路的依賴非常小；
3、Nginx安裝和配置比較簡單，測試起來比較方便；
4、可以承擔高的負載壓力且穩定，一般能支撐超過幾萬次的並發量；
5、Nginx可以通過埠檢測到伺服器內部的故障，比如根據伺服器處理網頁返回的狀態碼、超時等等；
6、Nginx僅能支持http和Email；

HAProxy的特點是：
1、HAProxy是支持虛擬主機的；
2、能夠補充Nginx的一些缺點比如Session的保持，Cookie的引導等工作；
3、支持url檢測後端的伺服器出問題的檢測會有很好的幫助；
4、它跟LVS一樣，本身僅僅就只是一款負載均衡軟體；
5、HAProxy可以對Mysql讀進行負載均衡，對後端的MySQL節點進行檢測和負載均衡，不過在後端的MySQL slaves數量超過10台時性能不如LVS；
6、HAProxy的演算法多；

⑵ 史上最全 40 道 Dubbo 面試題及答案，看完碾壓面試官！

Dubbo是阿里巴巴開源的高性能RPC分布式服務框架，現已成為Apache基金會孵化項目。使用Dubbo可以將核心業務抽取為服務，形成穩定的服務中心，提高業務復用性和靈活性，應對市場多變需求。Dubbo內部使用了Netty和Zookeeper，確保高性能和高可用性。

選擇Dubbo的原因在於它是阿里開源項目，廣泛應用於國內互聯網公司，經過線上考驗。使用Dubbo可以提高業務復用和擴展性，實現分布式架構，以應對更大並發流量。以下是Dubbo的核心特點和部分面試問題答案：

1. Dubbo是什麼？
Dubbo是基於java的高性能RPC分布式服務框架。

2. 為什麼要用Dubbo？
Dubbo是阿里開源項目，具有高可用性和性能，適用於分布式架構，能夠提高業務復用性和擴展性。

3. Dubbo和Spring Cloud的區別？
Dubbo和Spring Cloud在通信方式、組成部分和特定功能上有所不同。

4. Dubbo支持哪些協議？
Dubbo支持多種協議，推薦使用RPC通信。

5. Dubbo需要Web容器嗎？
不需要，使用Web容器只會增加復雜性並浪費資源。

6. Dubbo內置了哪些服務容器？
Dubbo使用簡單的Spring容器來暴露服務。

7. Dubbo有哪些節點角色？
節點角色包括提供者、消費者、注冊中心、監控中心和容器。

8. 畫出服務注冊與發現流程圖。
服務注冊與發現流程圖展示了Dubbo服務注冊中心的運作。

9. Dubbo使用什麼注冊中心？
推薦使用Zookeeper作為注冊中心，還有其他選擇。

10. Dubbo的配置方式有哪些？
Dubbo支持Spring配置和Java API配置。

11. Dubbo的核心配置有哪些？
核心配置包括服務、引用、協議、應用、模塊、注冊中心、監控中心、提供者和消費者等。

12. 在Provider上可以配置哪些Consumer端屬性？
可以配置超時、重試次數、負載均衡演算法和並發限制。

13. Dubbo啟動時依賴服務不可用會怎樣？
Dubbo會在啟動時檢查依賴服務，不可用時拋出異常。

14. Dubbo推薦的序列化框架有哪些？
推薦Hessian序列化，還有Duddo、FastJson和Java序列化。

15. Dubbo的通信框架？
默認使用Netty框架，集成有Mina、Grizzly等。

16. Dubbo的集群容錯方案有哪些？
包括失敗自動切換、快速失敗、失敗安全、失敗自動恢復和並行調用等。

17. Dubbo的負載均衡策略有哪些？
包括隨機、輪詢、最少活躍調用數和一致性Hash。

18. 多個服務注冊時如何測試特定服務？
可以配置環境點對點直連，繞過注冊中心。

19. Dubbo支持多協議嗎？
支持配置多協議，允許在同一服務上使用多種協議。

20. 多種服務實現同一介面時如何處理？
使用group屬性分組，服務提供方和消費方都指定同一group。

21. 如何兼容舊版本？
使用版本號過渡，多個不同版本服務注冊，版本號不同不引用。

22. Dubbo支持緩存嗎？
提供聲明式緩存加速訪問。

23. Dubbo服務調用是阻塞的嗎？
默認阻塞，支持非同步調用。

24. Dubbo支持分布式事務嗎？
暫不支持，可能通過JTA/XA規范實現。

25. Dubbo telnet命令的作用？
用於服務治理，具體使用請參考文章。

26. Dubbo支持服務降級嗎？
2.2.0以上版本支持。

27. 如何優雅停機？
通過JDK的ShutdownHook完成，強制關閉不會執行。

28. 服務失效踢出原理？
基於Zookeeper的臨時節點原理。

29. 解決服務調用鏈過長？
使用Pinpoint和Apache Skywalking實現分布式服務追蹤。

30. 服務讀寫容錯策略？
讀操作建議使用失敗自動切換，寫操作快速失敗。

31. Dubbo必須依賴的包？
必須依賴JDK，其他為可選。

32. 管理控制台功能？
包含路由規則、動態配置、服務降級、訪問控制、權重調整、負載均衡等功能。

33. Dubbo服務暴露過程？
Spring實例化bean後，在容器刷新最後一步發布事件，通知ServiceBean回調事件方法，實現服務發布。

34. Dubbo的維護狀態？
2014年後停止維護，17年開始重新維護並進入Apache項目。

35. Dubbo和Dubbox的區別？
Dubbox是當當網基於Dubbo的擴展項目，增加了服務調用的RESTful特性等。

36. 其他分布式框架？
還有Spring Cloud、Facebook的Thrift、Twitter的Finagle等。

37. Dubbo能集成Spring Boot嗎？
可以集成，項目地址為Apache Dubbo的GitHub倉庫。

38. 遇到的問題？
在大數據量下性能不佳，建議使用RMI或HTTP協議。

39. 閱讀Dubbo源碼？
了解Dubbo原理需要閱讀源碼，網上有教程可供參考。

40. Dubbo和Spring Cloud的評價？
Spring Cloud組件頻繁更新，配置復雜，與Dubbo相比，個人更傾向於使用Dubbo。

以上內容涵蓋了Dubbo的常見面試問題和使用細節，希望對大家有所幫助。

⑶ Java教程：bbo源碼解析-網路通信

在之前的內容中，我們探討了消費者端服務發現與提供者端服務暴露的相關內容，同時了解到消費者端通過內置的負載均衡演算法獲取合適的調用invoker進行遠程調用。接下來，我們聚焦於遠程調用過程，即網路通信的細節。

網路通信位於Remoting模塊中，支持多種通信協議，包括但不限於：bbo協議、rmi協議、hessian協議、http協議、webservice協議、thrift協議、rest協議、grpc協議、memcached協議、redis協議等。每種協議具有獨特的特點和應用場景。

其中，bbo協議採用單一長連接和 NIO 非同步通訊方式，適用於小數據量大並發的服務調用場景，以及服務消費者機器數遠大於服務提供者機器數的情況。它基於 mina1.1.7 和 hessian 3.2.1 的 tbremoting 交互實現。

rmi協議基於JDK標準的java.rmi.*實現，採用阻塞式短連接和JDK標准序列化方式。Hessian協議用於集成Hessian的服務，底層採用Http通訊，通過Servlet暴露服務，Dubbo內置Jetty作為伺服器實現。Hessian協議可以與原生Hessian服務互操作。

基於HTTP表單的遠程調用協議（http協議）採用Spring的HttpInvoker實現，可以與原生HTTP服務互操作。基於WebService的遠程調用協議（webservice協議）基於Apache CXF實現，同樣可以與原生WebService服務互操作。

thrift協議當前支持的擴展了thrift原生協議，增加了額外的頭信息，如serviceName、magic number等。rest協議基於標準的Java REST API實現，JAX-RS 2.0（Java API for RESTful Web Services的簡寫）用於支持REST調用。grpc協議自Dubbo 2.7.5版本開始支持，適合HTTP/2通信場景，利用gRPC帶來的Stream、反壓、Reactive編程能力。

memcached協議基於memcached實現的RPC協議，而redis協議基於Redis實現的RPC協議。

在序列化方面，序列化是將對象轉成位元組流以用於網路傳輸及將位元組流轉為對象的過程。序列化的優勢包括安全性更好、跨平台等。Dubbo基於netty進行網路通訊，NettyClient.doOpen()方法中可以看到Netty的相關類。序列化介麵包括但不限於：Serialization介面、Hessian2Serialization介面、Kryo介面、FST介面等。

序列化方式如Kryo和FST，性能往往優於hessian2，能夠顯著提高序列化性能。這些高效Java序列化方式的引入，可以優化Dubbo的序列化過程。

在配置Dubbo RPC時，引入Kryo和FST非常簡單，只需在RPC的XML配置中添加相應的屬性即可。

關於服務消費方發送請求，Dubbo框架定義了私有的RPC協議，消息頭和消息體分別用於存儲元信息和具體調用消息。消息頭包括魔數、數據包類型、消息體長度等。消息體包含調用消息，如方法名稱、參數列表等。請求編碼和解碼過程涉及編解碼器的使用，編碼過程包括消息頭的寫入、序列化數據的存儲以及長度的寫入。解碼過程則涉及消息頭的讀取、序列化數據的解析以及調用方法名、參數等信息的提取。

提供方接收請求後，服務調用過程包含請求解碼、調用服務以及返回結果。解碼過程在NettyHandler中完成，通過ChannelEventRunnable和DecodeHandler進一步處理請求。服務調用完成後，通過Invoker的invoke方法調用服務邏輯。響應數據的編碼與請求數據編碼過程類似，涉及數據包的構造與發送。

服務消費方接收調用結果後，首先進行響應數據解碼，獲得Response對象，並傳遞給下一個處理器NettyHandler。處理後，響應數據被派發到線程池中，此過程與服務提供方接收請求的過程類似。

在非同步通信場景中，Dubbo在通信層面為非同步操作，通信線程不會等待結果返回。默認情況下，RPC調用被視為同步操作。Dubbo通過CompletableFuture實現了非同步轉同步操作，通過設置非同步返回結果並使用CompletableFuture的get()方法等待完成。

對於非同步多線程數據一致性問題，Dubbo使用編號將響應對象與Future對象關聯，確保每個響應對象被正確傳遞到相應的Future對象。通過在創建Future時傳入Request對象，可以獲取調用編號並建立映射關系。線程池中的線程根據Response對象中的調用編號找到對應的Future對象，將響應結果設置到Future對象中，供用戶線程獲取。

為了檢測Client端與Server端的連通性，Dubbo採用雙向心跳機制。HeaderExchangeClient初始化時，開啟兩個定時任務：發送心跳請求和處理重連與斷連。心跳檢測定時任務HeartbeatTimerTask確保連接空閑時向對端發送心跳包，而ReconnectTimerTask則負責檢測連接狀態，當判定為超時後，客戶端選擇重連，服務端採取斷開連接的措施。

⑷ bbo十層架構

Dubbo是Alibaba開源的分布式服務框架，它按照分層的方式來架構，使用這種方式可以使各層解耦。

Dubbo在調用遠程的服務的時候再本地有一個介面，就想調用本地方法一樣去調用，底層實現好參數傳輸和遠程服務運行結果傳回之後的返回。

Dubbo的特點：

（1）它主要使用高效的網路框架和序列化框架，讓分布式服務之間調用效率更高。

（2）採用注冊中心管理眾多的服務介面地址，當你想調用服務的時候只需要跟注冊中心詢問談殲瞎即可，不像使用WebService一樣每個服務都得記錄好介面調用方式。

（3）監控中心時實現服務方和調用方之間運行狀態的監控，還能控制服務的優先順序、許可權、權重、上下線等，讓整個龐大的分布式服務系統的維護和治理比較方便。

（4）高可用，如果有服務掛了，注冊中心就會從服務列表去掉該節點，客戶端會像注冊中心請求另一台可用的服務節點重新調用。同時注冊中心也能實現高可用（ZooKeeper）。

（5）負載均衡，採用軟負載均衡演算法實現對多個相同服務的節點的請求負載均衡。

Dubbo需要四大基本組件：Rigistry,Monitor,Provider,Consumer。

1、含空監控中心的配置文件-bbo.properties文件

（1）容器改改，監控中心是在jetty和spring環境下運行，依賴於注冊中心，日誌系統是log4j

??bbo.container=log4j,spring,registry,jetty

（2）監控服務的名稱，監控系統對整個Dubbo服務系統來說也是一個服務

??bbo.application.name=simple-monitor

（3）服務的所有者，這是Dubbbo的服務的功能，可以指定服務的負責人

??bbo.application.owner=coselding

（4）注冊中心的地址，配置後監控中心就能通過注冊中心獲取當前可用的服務列表及其狀態，在頁面向你匯報Dubbo中的服務運行情況。

??bbo.registr.address=multicast://{ip}:{port}//廣播

???bbo.registr.address=zookeeper://{ip}:{port}//zookeper

???bbo.registr.address=redis://{ip}:{port}//redis

???bbo.registr.address=bbo://{ip}:{port}//bbo

（5）bbo協議埠號

??bbo.protocol.port=7070

（6）jetty工作埠號

??bbo.jetty.port=8082

（7）工作目錄，用於存放監控中心的數據

??bbo.jetty.directory=${user.home}/monitor

（8）監控中心報表存放目錄

???bbo.charts.directory=${bbo.jetty.directory}/charts

（9）監控中心數據資料目錄

???bbo.statistics.directory=${user.home}/monitor/statistics

（10）監控中心日誌文件路徑

???bbo.log4j.file=logs/bbo-monitor-simple.log

（11）監控中心日誌記錄級別

???bbo.log4j.level=WARN

2、Dubbo提供負載均衡方式

（1）Random，隨機，按權重配置隨機概率，調用量越大分布越均勻，默認方式。

（2）RounRobin，輪詢，按權重設置輪詢比例，如果存在比較慢的機器容易在這台機器上請求阻塞較多。

（3）LeastActive，最少活躍調用數，不支持權重，只能根據自動識別的活躍數分配，不能靈活調配。

（4）ConsistenHash，一致性hash，對相同參數的請求路由到一個服務提供者上，如果有類似灰度發布需求可採用。

3、Dubbo過濾器

Dubbo初始化過程載入ClassPath下的META-INF/bbo/internal/，META-INF/bbo/，META-INF/services/三個路徑下的com.alibaba.bbo.rpc.Filter文件。文件內容：

??Name=FullClassName,這些類必須實現Filter介面。

自定義Filter類：

配置文件在配置過濾器，consumer.xml中：

Dubbo對過濾器的載入過程：

??先載入三個路徑下的com.alibaba.bbo.rpc.Filter文件裡面的鍵值對，key為過濾器名稱，value為過濾器的類的全限定名(這個類必須實現Dubbo中的Filter介面)。

??自定義的類中@Active註解是過濾器設定的全局基本屬性。

??Spring在載入consumer.xml文件時，通過bbo:consumerfilter="xxx"id="xxx"retrries="0"這個配置指定消費者端要載入的過濾器，通過filter屬性指定過濾器名稱。

@Activate註解-自動激活，group屬性是表示匹配了對應的角色才被載入，value表示表明過濾條件，不寫則表示所有條件都會被載入，寫了則只有bboURL中包含該參數名且參數值不為空才被載入，這個參數會以bbo協議的一個參數K-V對傳到Provider。

4、Dubbo的Provider配置

5、Dubbo的Consumer配置

1、Dubbo是什麼？

Dubbo是阿里巴巴開源的基於Java的高性能RPC分布式框架。

2、為什麼使用Dubbo？

很多公司都在使用，經過很多線上的考驗，內部使用了Netty，Zookeeper，保證了高性能可用性。

使用Dubbo可以將核心業務抽取出來，作為獨立的服務，逐漸形成穩定的服務中心，可以提高業務復用靈活性擴展，使前端應用能快速的響應對邊的市場需求。分布式架構可以承受更大規模的並發流量。

Dubbo的服務治理圖：

3、Dubbo和SpringCloud的區別

兩個沒有關聯，但是非要說區別，有如下幾點：

（1）通信方式不同，Dubbo使用RPC通信，SpringCloud使用HTTPRestful方式

（2）組成部分不同

4、Dubbo支持的協議

bbo://?（推薦）；rmi://；hessian://；http://；webservice://；thrift://；memcached://；redis://；rest://。

5、Dubbo需要容器嗎？

不需要，如果硬要容器的話，會增加復雜性，同時也浪費資源。

6、Dubbo內置的服務容器

SpringContainer；JettyContainer；Log4jContainer。

7、Dubbo中節點角色

Register，Monitor，Provider，Consumer，Container(服務運行的容器)。

8、Dubbo的服務注冊和發現的流程圖

9、Dubbo的注冊中心

默認使用Zookeper作為注冊中心，還有Redis，Multicast，bbo注冊中心。

10、Dubbo的配置方式

Spring配置方式和JavaAPI配置方式

11、Dubbo的核心配置

（1）bbo:service服務配置

（2）bbo:referece引用配置

（3）bbo:protocol協議配置

（4）bbo:application應用配置

（5）bbo:registry注冊中心配置

（6）bbo:monitor監控中心配置

（7）bbo:provider提供方配置

（8）bbo:consumer消費方配置

（9）bbo:method方法配置

（10）bbo:argument參數配置

12、在Provider節點上可以配置Consumer端的屬性有哪些？

（1）timeout：方法調用超時

（2）retries：失敗重試次數，默認是2次

（3）loadbalance：負載均衡演算法，默認隨機

（4）actives消費者端，最大並發調用控制

13、Dubbo啟動時如果依賴的服務不可用會怎樣

Dubbo預設會在啟動時檢查依賴的服務是否可用，不可用時會拋出異常，阻止Spring初始化完成。默認check="true"。

14、Dubbo序列化框架

推薦使用Hessian序列化，還有Dubbo，FastJson，Java自帶序列化。

15、Dubbo的通信框架

默認使用Netty框架，另外也提供了Mina，Grizzly。

16、Dubbo集群容錯方案

（1）FailoverCluster，失敗自動切換，自動重試其他伺服器。

（2）FailfastCluster，快速失敗，立即報錯，只發起一次調用。

（3）FailsafeCluster，失敗安全，出現異常時，直接忽略。

（4）FailbackCluster，失敗自動恢復，記錄失敗請求，定時重發。

（5）ForkingCluster，並行調用多個伺服器，只要一個返回成功即可。

（6）BroadcastCluster，廣播逐個調用所有提供者，任意一個報錯則報錯。

17、Dubbo的負載均衡策略

（1）RandomLoadBalance，隨機，按權重設置隨機概率，默認。

（2）RoundRobinLoadBalace，輪詢，按公約後的權重設置輪訓比例。

（3）LeastActiveLoadBalace，最少活躍調用數，相同活躍數的隨機。

（4）ConsistenHashLoadBalance，一致性hash，相同參數的請求總是發到用一個伺服器。

18、指定某一個服務

可以配置環境點對點直連，繞過注冊中心，將以服務介面為單位，忽略注冊中心的提供者列表。

bbo:referenceinterface="com.weidian.bbo.IMyDemo"version="1.0"id="myDemo"url="bbo://127.0.0.1:20880/"/bbo:reference

19、Dubbo多協議

Dubbo允許配置多協議，在不同伺服器上支持不同協議，或者同一服務支持多種協議。

20、當一個服務有多種實現時怎麼做？

當一個介面有多種是現實，可以用group屬性來分組，服務提供方和消費方都指定同一個group即可。

21、兼容舊版本

使用版本號過度，多個不同版本的服務注冊到注冊中心，版本號不同的服務相互間不引用。

22、Dubbo可以緩存嗎？

Dubbo提供聲明式緩存，用於加速熱門數據的訪問速度，以減少用戶加緩存的工作量。

23、Dubbo服務之間的調用時阻塞的嗎？

默認是同步等待結果阻塞的，支持非同步調用。Dubbo是基於NIO的非阻塞實現並行調用的，客戶端不需要啟動多線程即可完成並行調用多個遠程服務，相對多線程開銷較小，非同步調用會返回一個Future對象。

24、Dubbo不支持分布式事務

25、Dubbo必須依賴的包

Dubbo必須依賴JDK，其他為可選。

26、Dubbo使用過程中的問題

Dubbo的設計目的是為了滿足高並發小數據量的rpc請求，在大數據量下性能表現不是很好，建議使用rmi或http協議。

27、Dubbo的管理控制台的作用

路由規則，動態配置，服務降級，訪問控制，權重調整，負載均衡。

28、Springboot整合Dubbo

（1）添加依賴

????????!----

????dependency

??????groupIdcom.alibaba.boot/groupId

??????artifactIdbbo-spring-boot-starter/artifactId

??????version0.1.0/version

????/dependency

????!----

????dependency

??????groupIdcom.101tec/groupId

??????artifactIdzkclient/artifactId

??????version0.10/version

????/dependency

（2）配置bbo

????##Dubbo服務提供者配置

????spring.bbo.application.name=provider

????spring.bbo.registry.address=zookeeper://127.0.0.1:2181

????spring.bbo.protocol.name=bbo

????spring.bbo.protocol.port=20880

????spring.bbo.scan=org.spring.springboot.bbo

????##Dubbo服務消費者配置

????spring.bbo.application.name=consumer

????spring.bbo.registry.address=zookeeper://127.0.0.1:2181

????spring.bbo.scan=org.spring.springboot.bbo

隨著業務的發展、用戶量的增長、系統並發訪問需求越來越大，系統數量增多，調用依賴關系也變得復雜，為了確保系統高可用、高並發的要求，系統的架構也從單體時代慢慢遷移至服務SOA時代，根據不同服務對系統資源的要求不同，我們可以更合理的配置系統資源，使系統資源利用率最大化。而Dubbo則是SOA服務化治理方案的一個核心框架。

Dubbo作為阿里巴巴內部的SOA服務化治理方案的核心框架，在2012年時已經每天為2000+個服務提供3,000,000,000+次訪問量支持，並被廣泛應用於阿里巴巴集團的各成員站點。Dubbo自2011年開源後，已被許多肢啟知非阿里系公司使用，其中既有當當網、網易考拉等互聯網公司，也有中國人壽、青島海爾等傳統企業。

Dubbo是一個高性能服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案，使得應用可通過高性能RPC實現服務的輸出和輸入功能，和Spring框架可以無縫集成。

作為一個分布式服務框架，以及SOA治理方案，Dubbo其功能主要包括：

Dubbo最大的特點是按照分層架構思維構建應用服務，使用這種方式可以使各個層之間解耦合（或者最大限度地松耦合）。從服務模型的角度來看，Dubbo採用的是一種非常簡單的模型，要麼是提供方提供服務，要麼是消費方消費服務，所以基於這一點可以抽象出服務提供方（Provider）和服務消費方（Consumer）兩個角色。

Dubbo包含遠程通訊、服務集群和服務發現與注冊三個核心部分。提供透明化的遠程方法調用，實現像調用本地方法一樣調用遠程方法，只需簡單配置，沒有任何API侵入。同時具備軟負載均衡及容錯機制，可在內網替代F5等硬體負載均衡器，降低成本，減少單點。可以實現服旁則務自動注冊與發現，不再需要寫死服務提供方地址，注冊中心基於介面名查詢服務提供者的IP地址，並且能夠平滑添加或刪除服務提供者。

Dubbo服務組件調用關秕說明：

Dubbo框架設計一共劃分了10個層，而最上面的Service層是留給實際想要使用Dubbo開發分布式服務的開發者實現業務邏輯的介面層。圖中左邊淡藍背景的為服務消費方使用的介面，右邊淡綠色背景的為服務提供方使用的介面，位於中軸線上的為歷消雙方都用到的介面。

下面，結合Dubbo官方文檔，我們分別理解一下框架分層架構中，各個層次的設計要點：

從上圖可以看出，Dubbo對於服務提供方和服務消費方，從框架的10層中分別提供了各自需要關心和擴展的介面，構建整個服務生態系統（服務提供方和服務消費方本身就是一個以服務為中心的）。

根據官方提供的，對於上述各層之間關系的描述，如下所示：