爲何要用 Dubbo？
隨着服務化的進一步發展，服務愈來愈多，服務之間的調用和依賴關係也愈來愈複雜，誕生了面向服務的架構體系(SOA)，也所以衍生出了一系列相應的技術，如對服務提供、服務調用、鏈接處理、通訊協議、序列化方式、服務發現、服務路由、日誌輸出等行爲進行封裝的服務框架。就這樣爲分佈式系統的服務治理框架就出現了，Dubbo 也就這樣產生了。java
Dubbo 的總體架構設計有哪些分層?
•接口服務層（Service）：該層與業務邏輯相關，根據 provider 和 consumer 的業務設計對應的接口和實現•配置層（Config）：對外配置接口，以 ServiceConfig 和 ReferenceConfig 爲中心•服務代理層（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 和 ThreadPoolspring
Dubbo 用到哪些設計模式？
Dubbo 框架在初始化和通訊過程當中使用了多種設計模式，可靈活控制類加載、權限控制等功能。apache
工廠模式
Provider 在 export 服務時，會調用 ServiceConfig 的 export 方法。ServiceConfig中有個字段：設計模式
private static final Protocol protocol =ExtensionLoader.getExtensionLoader(Protocol.class).getAdaptiveExtension();
複製代碼Dubbo 裏有不少這種代碼。這也是一種工廠模式，只是實現類的獲取採用了 JDKSPI 的機制。這麼實現的優勢是可擴展性強，想要擴展實現，只須要在 classpath下增長個文件就能夠了，代碼零侵入。另外，像上面的 Adaptive 實現，能夠作到調用時動態決定調用哪一個實現，可是因爲這種實現採用了動態代理，會形成代碼調試比較麻煩，須要分析出實際調用的實現類。springboot
裝飾器模式
Dubbo 在啓動和調用階段都大量使用了裝飾器模式。以 Provider 提供的調用鏈爲例，具體的調用鏈代碼是在 ProtocolFilterWrapper 的 buildInvokerChain 完成的，具體是將註解中含有 group=provider 的 Filter 實現，按照 order 排序，最後的調用順序是：微信
EchoFilter -> ClassLoaderFilter -> GenericFilter -> ContextFilter ->ExecuteLimitFilter -> TraceFilter -> TimeoutFilter -> MonitorFilter ->ExceptionFilter
複製代碼更確切地說，這裏是裝飾器和責任鏈模式的混合使用。例如，EchoFilter 的做用是判斷是不是回聲測試請求，是的話直接返回內容，這是一種責任鏈的體現。而像ClassLoaderFilter 則只是在主功能上添加了功能，更改當前線程的 ClassLoader，這是典型的裝飾器模式。網絡
觀察者模式
Dubbo 的 Provider 啓動時，須要與註冊中心交互，先註冊本身的服務，再訂閱本身的服務，訂閱時，採用了觀察者模式，開啓一個 listener。註冊中心會每 5 秒定時檢查是否有服務更新，若是有更新，向該服務的提供者發送一個 notify 消息，provider 接受到 notify 消息後，運行 NotifyListener 的 notify 方法，執行監聽器方法。架構
動態代理模式
Dubbo 擴展 JDK SPI 的類 ExtensionLoader 的 Adaptive 實現是典型的動態代理實現。Dubbo 須要靈活地控制實現類，即在調用階段動態地根據參數決定調用哪一個實現類，因此採用先生成代理類的方法，可以作到靈活的調用。生成代理類的代碼是 ExtensionLoader 的 createAdaptiveExtensionClassCode 方法。代理類主要邏輯是，獲取 URL 參數中指定參數的值做爲獲取實現類的 key。app
dubbo與spring cloud
dubbo 如今歸到 apache 旗下管理。開了新的維護，對 springboot 也作了適配更新。負載均衡
可能提及來Dubbo，不少人都不陌生，這畢竟是一款從2012年就開始開源的Java RPC框架，中間因爲各類各樣的緣由中止更新4年半的時間，中間只發過一個小版本修了一個小bug，甚至你們都覺得這個項目已經死掉了，居然又在2017年9月份恢復了更新，不可謂不神奇。
網絡上不少人都拿Dubbo和Spring Cloud作對比，可能在你們的心目中，這兩個框架是能夠畫上等號的吧，後來在網絡上有一個很是流行的表格，比較詳細的對比了 Spring Cloud 和 Dubbo ，表格以下：
以上列舉了一些核心部件，固然這裏須要申明一點，Dubbo對於上表中總結爲「無」的組件不表明不能實現，而只是Dubbo框架自身不提供，須要另外整合以實現對應的功能，這樣看起來確實Dubbo更像是Spring Cloud的一個子集。
Dubbo 在國內擁有着巨大的用戶羣，你們但願在使用 Dubbo 的同時享受 Spring Cloud 的生態，出現各類各樣的整合方案，可是由於服務中心的不一樣，各類整合方案並非那麼天然，直到 Spring Cloud Alibaba 這個項目出現，由官方提供了 Nacos 服務註冊中心後，纔將這個問題完美的解決。而且提供了 Dubbo 和 Spring Cloud 整合的方案，命名爲：Dubbo Spring Cloud 。
Dubbo Spring Cloud 概述
Dubbo Spring Cloud 構建在原生的 Spring Cloud 之上，其服務治理方面的能力可認爲是 Spring Cloud Plus， 不只徹底覆蓋 Spring Cloud 原生特性，並且提供更爲穩定和成熟的實現，特性比對以下表所示：
以上對比表格摘自Dubbo Spring Cloud官方文檔。
並且Dubbo Spring Cloud 基於 Dubbo Spring Boot 2.7.1 和 Spring Cloud 2.x 開發，不管開發人員是 Dubbo 用戶仍是 Spring Cloud 用戶， 都能輕鬆地駕馭，並以接近「零」成本的代價使應用向上遷移。Dubbo Spring Cloud 致力於簡化雲原生開發成本，以達成提升研發效能以及提高應用性能等目的。
Dubbo Spring Cloud 主要特性
•面向接口代理的高性能RPC調用：提供高性能的基於代理的遠程調用能力，服務以接口爲粒度，屏蔽了遠程調用底層細節。•智能負載均衡：內置多種負載均衡策略，智能感知下游節點健康情況，顯著減小調用延遲，提升系統吞吐量。•服務自動註冊與發現：支持多種註冊中心服務，服務實例上下線實時感知。•高度可擴展能力：遵循微內核+插件的設計原則，全部核心能力如Protocol、Transport、Serialization被設計爲擴展點，平等對待內置實現和第三方實現。•運行期流量調度：內置條件、腳本等路由策略，經過配置不一樣的路由規則，輕鬆實現灰度發佈，同機房優先等功能。•可視化的服務治理與運維：提供豐富服務治理、運維工具：隨時查詢服務元數據、服務健康狀態及調用統計，實時下發路由策略、調整配置參數。
Spring Cloud 爲何須要RPC
在Spring Cloud構建的微服務系統中，大多數的開發者使用都是官方提供的Feign組件來進行內部服務通訊，這種聲明式的HTTP客戶端使用起來很是的簡潔、方便、優雅，可是有一點，在使用Feign消費服務的時候，相比較Dubbo這種RPC框架而言，性能堪憂。
雖然說在微服務架構中，會講按照業務劃分的微服務獨立部署，而且運行在各自的進程中。微服務之間的通訊更加傾向於使用HTTP這種簡答的通訊機制，大多數狀況都會使用REST API。這種通訊方式很是的簡潔高效，而且和開發平臺、語言無關，可是一般狀況下，HTTP並不會開啓KeepAlive功能，即當前鏈接爲短鏈接，短鏈接的缺點是每次請求都須要創建TCP鏈接，這使得其效率變的至關低下。
對外部提供REST API服務是一件很是好的事情，可是若是內部調用也是使用HTTP調用方式，就會顯得顯得性能低下，Spring Cloud默認使用的Feign組件進行內部服務調用就是使用的HTTP協議進行調用，這時，咱們若是內部服務使用RPC調用，對外使用REST API，將會是一個很是不錯的選擇，恰巧，Dubbo Spring Cloud給了咱們這種選擇的實現方式。
dubbo or spring cloud
dubbo徹底能夠和springcloud共存，架構圖以下所示（圖片來源自技術交流羣）。因此說用springcloud並不表明項目多麼先進，用dubbo也並不就表示項目是落後的。微服務是如此龐大且複雜的工程，複雜到即便springcloud也不能cover住每個環節，並且，springcloud已有的一些方案作的並不理想，甚至都達不到生產標準。咱們要作的就是針對每個技術環節，結合本身的業務特色，千萬不要僅侷限在springcloud體系，從而選擇出最有利於本身項目的開源產品。
本文分享自微信公衆號 - soft張三丰（aguzhangsanfeng）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。