dubbo本質:一個Jar套件,一個分散式框架,,一個遠端服務呼叫的分散式框架。
1)既然是新手教學,肯定很多同學不明白什麼是分散式和遠端服務調用,為什麼要分散式,為什麼要遠端調用。我簡單畫個對比圖說明(圖1看到圖2。畫板畫的,勿噴)。
你想一下,以前什麼的都在一個伺服器上,呼叫方法直接就自然而然地呼叫了,沒啥問題。現在因為需求增多拆分了這麼多,部署在不同的伺服器上,那是不是相對以前都在一個伺服器上,現在分散式後,web層呼叫service層的服務變成了遠端呼叫?那怎麼像以前一樣都在一個伺服器上自然而然地呼叫方法呢? dubbo來解決。這就是下面dubbo的好處。
1.透明化的遠端方法調用,就像調用本地方法一樣調用遠端方法,只需簡單配置,沒有任何API侵入。
2.軟負載平衡及容錯機制,可在內網取代F5等硬體負載平衡器,降低成本,減少單點。
3. 服務自動註冊與發現,不再需要寫死服務提供者位址,註冊中心基於介面名稱查詢服務提供者的IP位址,並且能夠平滑新增或刪除服務提供者。 (下面講解)
Dubbo採用全Spring配置方式,透明化接入應用,對應用沒有任何API侵入,只需用Spring加載Dubbo的配置即可,Dubbo基於Spring的Schema擴展進行加載。
在講解他的架構圖之前,我們先普及下幾個概念。
節點角色說明:
Provider(生產者): 暴露服務的服務提供者。
Consumer(消費者): 呼叫遠端服務的服務消費方。
如圖,我們可以簡單理解為web1234需要呼叫service1234的服務,所以web1234是消費者,service1234是生產者。
那如果按照上面,消費者呼叫生產者的服務,那是不是如下圖:
你看暈不暈?暈不暈?暈不暈?反正我是暈了,萬一分散式得更多呢? ,所以我們需要他:
Registry(註冊中心): 服務註冊與發現的註冊中心。 dubbo推薦的是zookeeper。什麼是zookeeper? zookeeper是用於分散式中一致性處理的框架。更多的可以查看我之前的文章:這麼說吧,zookeeper 很簡單,其實就是個框架,是一致性處理用的。簡單的講,zookeeper就是個中介,賣樓的(生產者)把樓盤資訊放在中介(註冊中心)那裡,想買樓的(消費者)去中介那裡取得樓盤資源清單。於是,我們的圖變成了這樣:
是不是好很多了?還不夠, 我們還需要個監控中心(幹嘛用的?當然是監控用的,呼叫失敗怎麼辦?掛了怎麼辦?): Monitor: 統計服務的呼叫次調和呼叫時間的監控中心。 (不畫圖了)
然後,Provider放在容器裡運行,就叫做Container服務運行容器。 (不畫圖了)
最終dubbo架構,如圖(從0開始看起):
相關推薦:
以上是Dubbo+zokeeper基礎講解的詳細內容。更多資訊請關注PHP中文網其他相關文章!