Dubbo是阿里巴巴公司開源的一個高性能優秀的服務框架,使得應用可經過高性能的 RPC實現服務的輸出和輸入功能 ,能夠和Spring框架無縫集成。是一款高性能、輕量級的開源Java RPC框架,它提供了三大核心能力:面向接口的 遠程方法調用,智能容錯和負載均衡,以及服務自動註冊和發現。
上面提到了一個名字RPC,RPC是什麼呢?在這裏簡單的介紹一個概念。 RPC(Remote Procedure Call)—遠程過程調用,它是一種經過網絡從遠程計算機程序上請求服務,而不須要了解底層網絡技術的協議。簡單點說呢就是好比你在你本身本地能夠調用別人在他服務器上部署的服務,至於在哪裏部署,你徹底不須要了解。對你來講是透明的。須要詳細瞭解的能夠參照一下url:參考1,參考2。
下面咱們開始dubbo,在咱們使用任何一門技術或者學習一門技術的時候確定有必定的緣由,不可能平白無故,那麼咱們爲何要使用Dubbo?它能解決咱們什麼問題?
首先你們能夠想一想在工做中是否有這樣的場景?
若是咱們是在作一個很小的資訊類軟件,流量很小的時候咱們確定只會是單服務器,一個項目把這個軟件的業務所有承包起來。這樣是徹底能夠知足需求的。可是但咱們的這款產品上線獲得好評,有人開始關注了,流量上來的時候,單應用加單服務器的缺點就顯示出來了,服務器不能及時響應,前端渲染太慢,這個時候咱們就須要將服務拆分好比先後段分離,添加服務器。熬過這段時間後,哎呀哈,有人融資了,有錢了,項目要作的更加精細話,用戶體驗,後臺處理數據的能力須要更加深一步的提升了,這個時候咱們就須要把以前的項目再進一步的進行拆分,好比用戶模塊,訂單模塊等核心模塊專門提取出來,造成服務,業務層依靠底層模塊進行開發。以後隨着訪問量愈來愈大,咱們添加了硬件負載均衡F5,可是咱們的單個模塊的服務數量會愈來愈多,並且再加上服務器集羣,這樣url的配置會變的很是麻煩,咱們須要一個服務註冊中心,動態的註冊和發現服務,使服務的位置透明,並依靠軟件實現部分負載均衡的壓力,減小硬件壓力。可是如今服務太多了,除了架構師可能不多有人能理清楚服務間的依賴關係,再加上系統總體訪問量上來的時候咱們須要更加科學的可以統計每一個服務的請求量,評測服務器數量,又或者某些服務的請求量不是很高,是否是能夠適量的下降?Dubbo就是用來處理上面的問題的。
咱們看下Dubbo官網的架構圖: html
調用關係咱們舉個例子來講:好比如今有訂單服務,它就是服務提供者(Provider)。註冊中心(Registry)就比如咱們剛上學,咱們都去老師那裏報名,老師有咱們全部人的信息。當咱們系統各個服務啓動的時候,咱們的訂單Provider會去在註冊中心register本身,把本身註冊成一個對外的服務,這樣別人就能夠經過老師這個註冊中心知道咱們的任何信息了。與此同時消費者(Customer)想要去知道某我的的訂單信息的時候就能夠經過註冊中心subscribe去獲取。因此咱們在前端點擊用戶訂單信息的時候,customer由於訂閱了對應的訂單服務,就能準確調用的找到對應的服務找到對應的信息。前端