電商系統的演變能夠看出架構演變 Dubbo入門 遠程過程調用 須要解決的問題

 

 

Dubbo入門---搭建一個最簡單的Demo框架 - CSDN博客 https://blog.csdn.net/noaman_wgs/article/details/70214612

 

Dubbo背景和簡介

Dubbo開始於電商系統，所以在這裏先從電商系統的演變講起。

單一應用框架(ORM)
當網站流量很小時，只需一個應用，將全部功能以下單支付等都部署在一塊兒，以減小部署節點和成本。
缺點：單一的系統架構，使得在開發過程當中，佔用的資源愈來愈多，並且隨着流量的增長愈來愈難以維護 

 

二、垂直應用框架(MVC) 
垂直應用架構解決了單一應用架構所面臨的擴容問題，流量可以分散到各個子系統當中，且系統的體積可控，必定程度上下降了開發人員之間協同以及維護的成本，提高了開發效率。 
缺點：可是在垂直架構中相同邏輯代碼須要不斷的複製，不能複用。

 

 三、分佈式應用架構(RPC) 
當垂直應用愈來愈多，應用之間交互不可避免，將核心業務抽取出來，做爲獨立的服務，逐漸造成穩定的服務中心 

 

四、流動計算架構(SOA) 
隨着服務化的進一步發展，服務愈來愈多，服務之間的調用和依賴關係也愈來愈複雜，誕生了面向服務的架構體系(SOA)，也所以衍生出了一系列相應的技術，如對服務提供、服務調用、鏈接處理、通訊協議、序列化方式、服務發現、服務路由、日誌輸出等行爲進行封裝的服務框架

從以上是電商系統的演變能夠看出架構演變的過程： 

 

 

單一應用架構

當網站流量很小時，只需一個應用，將全部功能都部署在一塊兒，以減小部署節點和成本。
此時，用於簡化增刪改查工做量的 數據訪問框架(ORM) 是關鍵。
垂直應用架構

當訪問量逐漸增大，單一應用增長機器帶來的加速度愈來愈小，將應用拆成互不相干的幾個應用，以提高效率。
此時，用於加速前端頁面開發的 Web框架(MVC) 是關鍵。
分佈式服務架構
當垂直應用愈來愈多，應用之間交互不可避免，將核心業務抽取出來，做爲獨立的服務，逐漸造成穩定的服務中心，使前端應用能更快速的響應多變的市場需求。
此時，用於提升業務複用及整合的 分佈式服務框架(RPC) 是關鍵。
流動計算架構
當服務愈來愈多，容量的評估，小服務資源的浪費等問題逐漸顯現，此時需增長一個調度中心基於訪問壓力實時管理集羣容量，提升集羣利用率。
此時，用於提升機器利用率的 資源調度和治理中心(SOA) 是關鍵。

在這裏插播一條關於RPC的簡介：
RPC(Remote Procedure Call Protocol)：遠程過程調用：
兩臺服務器A、B，分別部署不一樣的應用a,b。當A服務器想要調用B服務器上應用b提供的函數或方法的時候，因爲不在一個內存空間，不能直接調用，須要經過網絡來表達調用的語義傳達調用的數據。
說白了，就是你在你的機器上寫了一個程序，我這邊是沒法直接調用的，這個時候就出現了一個遠程服務調用的概念。

RPC是一種經過網絡從遠程計算機程序上請求服務，而不須要了解底層網絡技術的協議。RPC協議假定某些傳輸協議的存在，如TCP或UDP，爲通訊程序之間攜帶信息數據。在OSI網絡通訊模型中，RPC跨越了傳輸層和應用層。RPC使得開發包括網絡分佈式多程序在內的應用程序更加容易。
RPC採用客戶機/服務器模式。請求程序就是一個客戶機，而服務提供程序就是一個服務器。首先，客戶機調用進程發送一個有進程參數的調用信息到服務進程，而後等待應答信息。在服務器端，進程保持睡眠狀態直到調用信息到達爲止。當一個調用信息到達，服務器得到進程參數，計算結果，發送答覆信息，而後等待下一個調用信息，最後，客戶端調用進程接收答覆信息，得到進程結果，而後調用執行繼續進行。
RPC須要解決的問題：
(能夠稍做了解，詳情可查看別的博文)

通信問題 : 主要是經過在客戶端和服務器之間創建TCP鏈接，遠程過程調用的全部交換的數據都在這個鏈接裏傳輸。鏈接能夠是按需鏈接，調用結束後就斷掉，也能夠是長鏈接，多個遠程過程調用共享同一個鏈接。
尋址問題 ： A服務器上的應用怎麼告訴底層的RPC框架，如何鏈接到B服務器（如主機或IP地址）以及特定的端口，方法的名稱名稱是什麼，這樣才能完成調用。好比基於Web服務協議棧的RPC，就要提供一個endpoint URI，或者是從UDDI服務上查找。若是是RMI調用的話，還須要一個RMI Registry來註冊服務的地址。
序列化 與 反序列化 ： 當A服務器上的應用發起遠程過程調用時，方法的參數須要經過底層的網絡協議如TCP傳遞到B服務器，因爲網絡協議是基於二進制的，內存中的參數的值要序列化成二進制的形式，也就是序列化（Serialize）或編組（marshal），經過尋址和傳輸將序列化的二進制發送給B服務器。
同理，B服務器接收參數要將參數反序列化。B服務器應用調用本身的方法處理後返回的結果也要序列化給A服務器，A服務器接收也要通過反序列化的過程。 

 

 

Dubbo入門Demo

瞭解了Dubbo之後，天然要搭建一個簡單的Demo實現。本文采用Dubbo與Zookeeper、Spring框架的整合。

主要是如下幾個步驟：
1. 安裝Zookeeper,啓動；
2. 建立MAVEN項目，構建Dubbo+Zookeeper+Spring實現的簡單Demo；
3. 安裝Dubbo-admin，實現監控。

1 Zookeeper介紹與安裝

本Demo中的Dubbo註冊中心採用的是Zookeeper。爲何採用Zookeeper呢？

Zookeeper是一個分佈式的服務框架，是樹型的目錄服務的數據存儲，能作到集羣管理數據 ，這裏能很好的做爲Dubbo服務的註冊中心。
Dubbo能與Zookeeper作到集羣部署，當提供者出現斷電等異常停機時，Zookeeper註冊中心能自動刪除提供者信息，當提供者重啓時，能自動恢復註冊數據，以及訂閱請求
具體的安裝方法在此不一一敘述，可參考博文：
http://blog.csdn.net/tlk20071/article/details/52028945

安裝完成後，進入到bin目錄，而且啓動zkServer.cmd，這個腳本中會啓動一個java進程： (注：須要先啓動zookeeper後，後續dubbo demo代碼運行才能使用zookeeper註冊中心的功能)