原文地址：https://blog.csdn.net/chenli522/article/details/47082433前端
dubbo總結(1)——關於我和dubbo
我和dubbo這個東西結緣純屬一次意外中的意外，就在兩年前，在csdn博客上隨意瀏覽，開始是被dubbo這個單詞吸引了，開始只是糾結於他的發音，後來當我慢慢的深刻去了解它，或者是在兩年間的使用過程當中，它已經成爲了技術生涯中的重要里程碑。spring
dubbo這個東西，起源於阿里巴巴，對於作電商開發的人來講，dubbo彷佛已經成爲了一個代名詞，有的人以爲它高大上，有的人以爲也不過就是soa的一個服務治理框架。也曾經同樣在dubbo的官方羣和一羣人一塊兒討論dubbo和soa的區別，也曾和梁飛作過交流，過往的總總如今回憶起來，帶有不少美好的糊塗和豁然開朗。sql
這東西使用了兩年，也曾莫名其妙出現服務掛掉以後沒法啓動，也曾在作集羣過程當中，系統掛掉出現選不出leader的時候影響dubbo，總之在個人技術進程中，是dubbo成就了我，讓我站在巨人的肩膀上看到了更廣闊的技術。數據庫
因此，當我在這家公司準備離職的時候，恰好這幾天能夠閒下來，對前幾年作個總結，我把我對dubbo的總結和整個學習的過程記錄下來，確定寫不出高大上的東西，或許更多的只是本身的回憶，也但願能把我學習dubbo的經驗帶給讀者吧，互相進步。緩存
dubbo總結(2)——dubbo的使用場景
關於dubbo的使用場景，這個要從系統的演變開始將起，既然dubbo的使用不少是在電商系統中，那麼就從電商系統的演變開始講起。服務器
一個簡單的電商網站提及，它可能包含以下的幾個模塊和功能，如首頁、detail頁、list頁、下單頁、支付頁以及後臺管理等頁面和功能。單一的系統架構，使得在開發過程當中，佔用的資源愈來愈多，並且隨着流量的增長使得維護起來愈來愈難以維護。
網絡
因而就產生了垂直應用架構，垂直應用架構解決了單一應用架構所面臨的擴容問題，流量可以分散到各個子系統當中，且系統的體積可控，必定程度上下降了開發人員之間協同以及維護的成本，提高了開發效率。可是在垂直架構中相同邏輯代碼須要不斷的複製，不能複用。因此分佈式系統就這樣應運而生了。架構
公共的邏輯業務提取出來造成服務，對外提供。這樣對於維護和升級都只須要切分紅一個一個的小系統去維護，也可讓前端業務系統與底層數據訪問分離，團隊分工更爲明確。負載均衡
分佈式系統所依賴的基礎設施包括服務框架、消息中間件、數據訪問中間件、配置中心、分佈式緩存系統、持久化存儲(關係數據庫、nosql數據庫)、搜索引擎、CDN網絡、負載均衡系統、運維自動化系統、硬件虛擬化及鏡像管理系統、分佈式文件系統、日誌收集系統、監控系統、離線計算、實時計算、數據倉庫等等。隨着服務化的進一步發展，服務愈來愈多，服務之間的調用和依賴關係也愈來愈複雜，誕生了面向服務的架構體系(SOA)，也所以衍生出了一系列相應的技術，如對服務提供、服務調用、鏈接處理、通訊協議、序列化方式、服務發現、服務路由、日誌輸出等行爲進行封裝的服務框架。框架
就這樣爲分佈式系統的服務治理框架就出現了，dubbo也就這樣產生了。dubbo在整個分佈式系統的架構中，按照分層的架構來架構，使得各個層級之間最大限度的鬆耦合.
Dubbo（三）Dubbo的詳細介紹、設計思路、以及4大適用場景
轉自：https://baijiahao.baidu.com/s?id=1612574809664801766&wfr=spider&for=pc
Dubbo是什麼？
Dubbo是一個分佈式服務框架，致力於提供高性能和透明化的RPC遠程服務調用方案，以及SOA服務治理方案。
簡單的說，dubbo就是個服務框架，若是沒有分佈式的需求，實際上是不須要用的，只有在分佈式的時候，纔有dubbo這樣的分佈式服務框架的需求，而且本質上是個服務調用的東東，說白了就是個遠程服務調用的分佈式框架（告別Web Service模式中的WSdl，以服務者與消費者的方式在dubbo上註冊）。
其核心部分包含:
1. 遠程通信:
提供對多種基於長鏈接的NIO框架抽象封裝，包括多種線程模型，序列化，以及「請求-響應」模式的信息交換方式。
2. 集羣容錯:
提供基於接口方法的透明遠程過程調用，包括多協議支持，以及軟負載均衡，失敗容錯，地址路由，動態配置等集羣支持。
3. 自動發現
基於註冊中心目錄服務，使服務消費方能動態的查找服務提供方，使地址透明，使服務提供方能夠平滑增長或減小機器。
Dubbo能作什麼？
1.透明化的遠程方法調用
就像調用本地方法同樣調用遠程方法，只需簡單配置，沒有任何API侵入。
2.軟負載均衡及容錯機制
可在內網替代F5等硬件負載均衡器，下降成本，減小單點。
3. 服務自動註冊與發現
再也不須要寫死服務提供方地址，註冊中心基於接口名查詢服務提供者的IP地址，而且可以平滑添加或刪除服務提供者。
Dubbo採用全spring配置方式，透明化接入應用，對應用沒有任何API侵入，只需用Spring加載Dubbo的配置便可，Dubbo基於Spring的Schema擴展進行加載。
Dubbo的架構和設計思路
Dubbo框架具備極高的擴展性，主要採用微核+插件體系，而且文檔齊全，很方便二次開發，適應性極強。
Dubbo的整體架構，如圖所示：
Dubbo框架設計一共劃分了10個層，而最上面的Service層是留給實際想要使用Dubbo開發分佈式服務的開發者實現業務邏輯的接口層。圖中左邊淡藍背景的爲服務消費方使用的接口，右邊淡綠色背景的爲服務提供方使用的接口， 位於中軸線上的爲雙方都用到的接口。
Dubbo框架設計一共劃分了10個層：
服務接口層（Service）：該層是與實際業務邏輯相關的，根據服務提供方和服務消費方的業務設計對應的接口和實現。配置層（Config）：對外配置接口，以ServiceConfig和ReferenceConfig爲中心，能夠直接new配置類，也能夠經過spring解析配置生成配置類。服務代理層（Proxy）：服務接口透明代理，生成服務的客戶端Stub和服務器端Skeleton，以ServiceProxy爲中心，擴展接口爲ProxyFactory。服務註冊層（Registry）：封裝服務地址的註冊與發現，以服務URL爲中心，擴展接口爲RegistryFactory、Registry和RegistryService。可能沒有服務註冊中心，此時服務提供方直接暴露服務。集羣層（Cluster）：封裝多個提供者的路由及負載均衡，並橋接註冊中心，以Invoker爲中心，擴展接口爲Cluster、Directory、Router和LoadBalance。將多個服務提供方組合爲一個服務提供方，實現對服務消費方來透明，只須要與一個服務提供方進行交互。監控層（Monitor）：RPC調用次數和調用時間監控，以Statistics爲中心，擴展接口爲MonitorFactory、Monitor和MonitorService。遠程調用層（Protocol）：封將RPC調用，以Invocation和Result爲中心，擴展接口爲Protocol、Invoker和Exporter。Protocol是服務域，它是Invoker暴露和引用的主功能入口，它負責Invoker的生命週期管理。Invoker是實體域，它是Dubbo的核心模型，其它模型都向它靠擾，或轉換成它，它表明一個可執行體，可向它發起invoke調用，它有多是一個本地的實現，也多是一個遠程的實現，也可能一個集羣實現。信息交換層（Exchange）：封裝請求響應模式，同步轉異步，以Request和Response爲中心，擴展接口爲Exchanger、ExchangeChannel、ExchangeClient和ExchangeServer。網絡傳輸層（Transport）：抽象mina和netty爲統一接口，以Message爲中心，擴展接口爲Channel、Transporter、Client、Server和Codec。數據序列化層（Serialize）：可複用的一些工具，擴展接口爲Serialization、 ObjectInput、ObjectOutput和ThreadPool。和淘寶HSF相比，Dubbo的特色是什麼？
1. Dubbo比HSF的部署方式更輕量
HSF要求使用指定的JBoss等容器，還須要在JBoss等容器中加入sar包擴展，對用戶運行環境的侵入性大，若是你要運行在Weblogic或Websphere等其它容器上，須要自行擴展容器以兼容HSF的ClassLoader加載，而Dubbo沒有任何要求，可運行在任何Java環境中。
2. Dubbo比HSF的擴展性更好，很方便二次開發
一個框架不可能覆蓋全部需求，Dubbo始終保持平等對待第三方理念，即全部功能，均可以在不修改Dubbo原生代碼的狀況下，在外圍擴展，包括Dubbo本身內置的功能，也和第三方同樣，是經過擴展的方式實現的，而HSF若是你要加功能或替換某部分實現是很困難的，好比支付寶和淘寶用的就是不一樣的HSF分支，由於加功能時改了核心代碼，不得不拷一個分支單獨發展，HSF現階段就算開源出來，也很難複用，除非對架構重寫。
3. HSF依賴比較多內部系統
好比配置中心，通知中心，監控中心，單點登陸等等，若是要開源還須要作不少剝離工做，而Dubbo爲每一個系統的集成都留出了擴展點，並已梳理幹清全部依賴，同時爲開源社區提供了替代方案，用戶能夠直接使用。
4. Dubbo比HSF的功能更多
除了ClassLoader隔離，Dubbo基本上是HSF的超集，Dubbo也支持更多協議，更多註冊中心的集成，以適應更多的網站架構。
Dubbo適用於哪些場景？
1.RPC分佈式服務
當網站變大後，不可避免的須要拆分應用進行服務化，以提升開發效率，調優性能，節省關鍵競爭資源等。
好比：爲了適用不斷變化的市場需求，以及多個垂直應用之間數據交互方便，咱們把公共的業務抽取出來做爲獨立的模塊，爲其餘的應用提供服務，系統逐漸依賴於抽象和rpc遠程服務調用。
2.配置管理
當服務愈來愈多時，服務的URL地址信息就會爆炸式增加，配置管理變得很是困難，F5硬件負載均衡器的單點壓力也愈來愈大。
3.服務依賴
當進一步發展，服務間依賴關係變得錯蹤複雜，甚至分不清哪一個應用要在哪一個應用以前啓動，架構師都不能完整的描述應用的架構關係。
4.服務擴容
接着，服務的調用量愈來愈大，服務的容量問題就暴露出來，這個服務須要多少機器支撐？何時該加機器？等等……
在遇到這些問題時，均可以用Dubbo來解決