冰河開始對Dubbo下手了！

寫在前面

對冰河有必定了解的讀者都知道，冰河經歷了一個高併發電商系統用戶從零到上億的整個研發過程，後期也由此衍生出電商系統（商城+秒殺）和基於海量數據的實時精準商品推薦平臺。部分核心知識已總結到我出版的兩本書籍——《海量數據處理與大數據技術實戰》和《MySQL技術大全：開發、優化與運維實戰》中。隨着電商系統業務的不斷髮展，咱們須要對系統不斷的迭代升級，這期間，Dubbo功不可沒。

在微服務領域有兩個比較出名的技術棧：SpringCloud / SpringCloud Alibaba（目前SpringCloud Alibaba有超過SpringCloud的勢頭）和Dubbo。而Dubbo做爲一個服務治理的RPC框架，在大廠面試的過程當中，幾乎是一個必問的技術。因此，我打算寫一個深度解析Dubbo的系列專題，揭開Dubbo的神祕面紗，讓更多的小夥伴完全掌握Dubbo。

這篇就做爲Dubbo源碼系列的開篇吧！！

注：寫完Dubbo再寫SpringCloud Alibaba系列。

文章已收錄到：

https://github.com/sunshinelyz/technology-binghe

https://gitee.com/binghe001/technology-binghe

Dubbo的核心能力

整體來講，Apache Dubbo是一款高性能，輕量級的開源RPC框架，提供了六大核心能力：

• 面向接口代理的高性能RPC調用。
• 智能容錯和負載均衡。
• 服務自動註冊和發現。
• 高度可擴展能力。
• 運行期流量調度。
• 可視化的服務治理與運維。

具體細節小夥伴們能夠參見Dubbo官方文檔。

爲什麼學Dubbo

爲什麼要深度學習Dubbo，那確定是要解決某種業務場景啊。接下來，咱們就聊一聊爲什麼學習Dubbo。不過在介紹爲什麼學習Dubbo前，咱們先來看看隨着業務的不斷髮展，咱們的系統在架構上會有哪些變化。

單體應用架構

在企業發展的初期，通常公司的網站流量都比較小，只須要一個應用，將全部的功能代碼打包成一個服務，部署到服務器上就能支撐公司的業務。這樣也可以減小開發、部署和維護的成本。

好比，你們都很熟悉的電商系統，裏面涉及的業務主要有：用戶管理、商品管理、訂單管理、支付管理、庫存管理、物流管理等等模塊，初期咱們會將全部模塊寫到一個Web項目中，而後統一部署到一個Web服務器中。

這種架構特色有其優勢：

• 架構簡單，項目開發和維護成本低。
• 全部項目模塊部署到一塊兒，對於小型項目來講，維護方便。

可是，其缺點也是比較明顯的：

• 全部模塊耦合在一塊兒，雖然對於小型項目來講，維護方便。可是，對於大型項目來講，倒是不易開發和維護的。
• 項目的各模塊以前過於耦合，若是一旦有一個模塊出現問題，則整個項目將不可用。
• 沒法針對某個具體模塊來提高性能。
• 沒法對項目進行水平擴展。

正是因爲單體應用架構存在着諸多的缺點，才逐漸演變爲垂直應用架構。接下來，咱們就來看看垂直應用架構。

垂直應用架構

隨着企業業務的不斷髮展，發現單節點的單體應用不足以支撐業務的發展，因而企業會將單體應用部署多份，分別放在不一樣的服務器上。可是，此時會發現不是全部的模塊都會有比較大的訪問量。若是想針對項目中的某些模塊進行優化和性能提高，此時對於單體應用來講，是作不到的。因而乎，垂直應用架構誕生了。

垂直應用架構，就是將原來一個項目應用進行拆分，將其拆分爲互不想幹的幾個應用，以此來提高系統的總體性能。

這裏，咱們一樣以電商系統爲例，在垂直應用架構下，咱們能夠將整個電商項目拆分爲：電商交易系統、後臺管理系統、CMS管理系統等。

咱們將單體應用架構拆分爲垂直應用架構以後，一旦訪問量變大，咱們只須要針對訪問量大的業務增長服務器節點便可，無需針對整個項目增長服務器節點了。

這種架構的優勢：

• 系統進行了拆分，可根據不一樣系統的訪問狀況，有針對性的進行優化。
• 可以實現應用的水平擴展。
• 各系統可以分擔總體訪問的流量，解決了併發問題。
• 一個系統發生了故障，不該用其餘系統的運行狀況，提升了總體的容錯率。

這種架構的缺點：

• 拆分後的各系統之間相對比較獨立，沒法進行互相調用。
• 各系統不免存在重疊的業務，會存在重複開發的業務，後期維護比較困難。

分佈式架構

咱們將系統演變爲垂直應用架構以後，當垂直應用愈來愈多，重複編寫的業務代碼就會愈來愈多。此時，咱們須要將重複的代碼抽象出來，造成統一的服務供其餘系統或者業務模塊來進行調用。此時，系統就會演變爲分佈式架構。

在分佈式架構中，咱們會將系統總體拆分爲服務層和表現層。服務層封裝了具體的業務邏輯供表現層調用，表現層則負責處理與頁面的交互操做。

這種架構的優勢：

• 將重複的業務代碼抽象出來，造成公共的訪問服務，提升了代碼的複用性。
• 能夠有針對性的對系統和服務進行性能優化，以提高總體的訪問性能。

這種架構的缺點：

系統之間的耦合度變高，調用關係變得複雜，難以維護。

SOA架構

在分佈式架構下，當部署的服務愈來愈多，重複的代碼就會愈來愈多，對於容量的評估，小服務資源的浪費等問題比較嚴重。此時，咱們就須要增長一個統一的調度中心來對集羣進行實時管理。此時，系統就會演變爲SOA（面向服務）的架構。

這種架構的優勢：

使用註冊中心解決了各個服務之間的服務依賴和調用關係的自動註冊與發現。

這種架構的缺點：

• 各服務之間存在依賴關係，若是某個服務出現故障可能會形成服務的雪崩（關於穿透、擊穿和雪崩的問題，小夥伴們能夠參見我以前寫的《【高併發】面試官：講講什麼是緩存穿透？擊穿？雪崩？如何解決？》一文）。
• 服務之間的依賴與調用關係複雜，測試部署的困難比較大。

微服務架構

隨着業務的發展，咱們在SOA架構的基礎上進一步擴展，將其完全拆分爲微服務架構。在微服務架構下，咱們將一個大的項目拆分爲一個個小的能夠獨立部署的微服務，每一個微服務都有本身的數據庫。

這種架構的優勢：

• 服務完全拆分，各服務獨立打包、獨立部署和獨立升級。
• 每一個微服務負責的業務比較清晰，利於後期擴展和維護。
• 微服務之間能夠採用REST和RPC協議進行通訊。

這種架構的缺點：

• 開發的成本比較高。
• 涉及到各服務的容錯性問題。
• 涉及到數據的一致性問題。
• 涉及到分佈式事務問題（小夥伴們能夠參見我後續會持續更新的【分佈式事務】專題）。

爲什麼學習Dubbo？

（1）系統升級過程當中須要使用dubbo解決問題。

在系統架構升級和微服務落地的過程當中，咱們須要解決不少的問題，好比：

• 將一個項目拆分爲多個服務以後，服務於服務之間如何高效的通訊？
• 服務的調用如何作到負載均衡和高可用？
• 服務的調用如何作到限流？又如何快速的感知到依賴服務宕機？
• 服務的邊界如何定義？
• 當系統中存在的服務愈來愈多時，如何進行服務治理等等。

這些問題，咱們均可以使用Dubbo來解決。

（2）互聯網大廠須要掌握Dubbo技術。

很明確，不少互聯網大廠都須要深度掌握Dubbo這項技術。這裏說的深度掌握，並不僅是停留在簡單的使用層面，而是對Dubbo的核心原理和源碼有必定的理解。換句話說：就是你要對Dubbo的核心原理和源碼很熟，在高併發、大流量場景下要可以結合Dubbo的原理和源碼分析出問題所在，並可以進行相應的性能調優。

因此說，若是你想進互聯網大廠，最好是掌握Dubbo的核心原理和源碼。

Dubbo的使用場景

在分佈式架構、SOA架構和微服務架構下，Dubbo有其充分的用武之地。有些小夥伴可能會說：咱們系統中使用的是SpringCloud技術棧，不須要使用Dubbo呀！其實，使用SpringCloud和Dubbo是不衝突的，甚至兩者也能夠結合使用。例如，我所經歷的項目，有些獨立的模塊使用了Dubbo做爲RPC框架，有些模塊則使用了SpringCloud，兩者並非衝突的，能夠作到互相促進的做用。

整體來講，Dubbo的使用場景以下：

RPC分佈式服務

當網站變大後，不可避免的須要拆分應用進行服務化，以提升開發效率，調優性能，節省關鍵競爭資源等。

好比：爲了適用不斷變化的市場需求，以及多個垂直應用之間數據交互方便，咱們把公共的業務抽取出來做爲獨立的模塊，爲其餘的應用提供服務，系統逐漸依賴於抽象和rpc遠程服務調用。

配置管理

當服務愈來愈多時，服務的URL地址信息就會爆炸式增加，配置管理變得很是困難，F5硬件負載均衡器的單點壓力也愈來愈大。

服務依賴

當進一步發展，服務間依賴關係變得錯蹤複雜，甚至分不清哪一個應用要在哪一個應用以前啓動，架構師都不能完整的描述應用的架構關係。

服務擴容

接着，服務的調用量愈來愈大，服務的容量問題就暴露出來，這個服務須要多少機器支撐？何時該加機器？等等……

Dubbo總結

總之，用官方的話說：Apache Dubbo 是一款高性能、輕量級的開源 Java 服務框架，提供了六大核心能力：面向接口代理的高性能RPC調用，智能容錯和負載均衡，服務自動註冊和發現，高度可擴展能力，運行期流量調度，可視化的服務治理與運維。

Dubbo的六大核心能力可以爲咱們在快速迭代微服務項目時，更好的提供RPC和服務治理能力。若是你想進大廠，就最好掌握Dubbo。

好了，今天就到這兒吧，我是冰河，你們有啥問題能夠在下方留言，也能夠加我微信：sun_shine_lyz，一塊兒交流技術，一塊兒進階，一塊兒牛逼~~