從對dubbo理解到Restful風格使用

最近在Restful遠程調用和dubbo之間弄得迷迷糊糊的,碰到很多腦洞大開的問題,問部門大佬有時都不能理解我問的是啥。最近一直在研究,看到一篇噹噹網dubbox團隊寫的文章,感覺有點頭緒了,所以趕緊寫下來,怕回頭又忘了。下面寫下我問題的一個產生過程,在講下我後來理解。如有不對的地方,真的希望多多指點下我....大四出來實習,感覺會的東西真的不夠用。剛剛說的那篇文章地址在Dubbo中開發REST風格的遠程調用(RESTful Remoting)

我產生腦洞的過程和重新的理解:

1.大學期間,網上找教學視頻看,第一次聽到了分佈式的概念,前面文章總結了,並將當時自己寫的“玩具”(就是一整套項目頁面 控制層 服務層 Dao層在一個項目的那種),改造了下。將前端(頁面 控制層)抽出來做了一個單獨的項目,後端(服務層 Dao層)抽出一個單獨的項目,中間通過dubbo調用。在這兩個項目Spring裏整合dubbo,配置像下面這個樣子

<!--服務提供方名稱,後端項目中-->
<dubbo:application name="service-product"/>
<!-- 連接zookeeper註冊中心 127.0.0.1:2181 -->
<dubbo:registry address="127.0.0.1" protocol="zookeeper"></dubbo:registry>
<!-- 對外提供服務的端口號  默認20880 -->
<dubbo:protocol host="127.0.0.1" port="20880"></dubbo:protocol>
<!-- 對外暴露的接口 ref爲接口對應的實現類 
cn.chengl.service.TestService 是服務的接口。
testService是spring 爲我們創建service對象
-->
<dubbo:service interface="cn.chengl.service.TestService" ref="testService"></dubbo:service>
|------------------------------------------------------------------------------------------------------------|
<!--配置消費方名稱  -->
<dubbo:application name="sport-console"/>
<!--註冊zookeeper 連接  192.168.200.128:2181  -->
<dubbo:registry address="192.168.200.128:2181" protocol="zookeeper"></dubbo:registry>
<!-- 獲取服務
前臺頁面只要導入後臺項目的接口jar包就可以了
就可以通過這方式拿到一個testService對象,來調用後臺項目的方法
 -->
<dubbo:reference interface="cn.lx.sport.service.TestService"  id="testService"></dubbo:reference>
我們可以看到,上面這種操作,給我的感覺就是服務端創建了service的對象,而前端有好像“拿到”了這個對象,當時蠢萌蠢萌的我,直接說呵呵,不就是一個對象流在網絡上傳遞嗎,把service對象序列化下,在前端反序列化下,大功告成~現在想想真的傻,首先序列化對象,只會序列化對象 類名 屬性類型 屬性值,你傳過去給前端,你的方法實現前端還是沒有啊。其次,即使我們有種技術可以把對象傳到我這個前臺項目,那分佈式的一個意義,就是分佈式之後我們可以更具併發量的不同,來安排每個項目或者叫服務安排機器,那如果你全部項目都是把對象給前端項目來執行,那併發量還不是落在了前端項目上?最近網上了解下,其實dubbo是創建了代理對象來兩個項目間通信,當我們在前端調用對象的方法時,實際上調用代理對象的方法來發請求,我沒有深入瞭解,但大體方向應該是沒錯的,等到畢設做完再來鑽研鑽研吧。

2.這個問題還是在我以前做的“玩具”與公司項目之間差別產生的。以前我寫的項目 瀏覽器或者用jQuery發RestFul請求(我不知道瀏覽器怎麼發delete和put請求..)到springmvc,springmvc攔截到請求分發給controller,然後controller調用dubbo給的service對象的後臺方法。好了,這樣Rest也用到了dubbo遠程調用也用到了,完美....

但是,敲公司的代碼的時候,他並沒有所謂controller這一層,而是前臺直接通過jQuery發請求(沒有了java代碼了),到service上(service接口上面寫有rest形式 註解@path(/v1/xxx)),實現了前後端的分離。

可是這下我就蒙了,那我所有的前臺頁面直接通過Rest格式請求我服務層的業務了我要啥業務直接用請求取就好了,要你dubbo有個錘子用。跑去問有經驗同事,同事問,你服務與服務之間怎麼調用呢?我說也可以通過請求工具發請求啊,同事問那我一個服務調用5個服務,而這個服務還集羣,那五個服務還調用其他亂七八在的服務。你這url圖得多亂?dubbo就是幹這件事的啊!....我說對喲..之前看過dubbo用zookeepr做註冊中心的時候瞭解過.....而且下圖還有一個問題,當存在b需要調d服務時 d和d’是集羣,b怎麼知道知道調那個d呢?一個d蹦了怎麼辦? dubbo有集羣容錯和負載均衡功能。

這個問題本質上還是我理解得不夠深,半桶水。像我上面有controller層的那個無非可以理解成 前端頁面發請求 請求我controller服務,controller服務在調用了後臺服務。 還有一個點就是,我前臺界面請求後臺服務的url路由亂怎麼辦,我的理解是,對於單種服務獲取必須得記,但是單種服務下的集羣,可以用nginx來做負載均衡(這個是我猜的,百度查不到,具體也沒實際做過這種項目,還望懂得大佬指點)。

3.這個是關於上面問題。我對真正服務端接收請求有了一些理解。我們的項目之所以能接到請求Url,在最早學習javaweb的時候我們知道可以配servlet有servlet-mapping,而後來學習springmvc時候,我麼只需配一個dispatcherservlet,在springmvc中他用一個分發servlet幫我們處理所有請求到對應的有@requestmapping的controller。而在我上面說的前臺頁面直接ajax請求到服務的時候,我們沒有springmvc,這個時候dubbo提供了一個請求分發servlet(com.alibaba.dubbo.remoting.http.servlet.DispatcherServlet),他能分發請求到  有 標準Java REST API:JAX-RS 的註解@path 的服務層實現或者接口上。具體的可以看我上面給的鏈接,感覺寫的很好很容易明白。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章