這周淺顯的學習了springcloud.簡單聊一下微服務.所謂的微服務遠遠沒有我想想的那麼高階難以理解,簡單說,就是多個服務分布在不同的伺服器上,由這些服務互相配合完成某一項任務.那服務和服務之間呼叫的方式就得用restful,通俗講就是服務和服務之間通過訪問對方的controller而完成服務呼叫.這樣的局面就是在同乙個生態系統中的某個服務,它既可能是服務端(提供資料)也可能是客戶端(發出請求).
接下來我們假設當前有訂單服務(a),購物車服務(b),這兩個服務都可以互相呼叫,訂單可以讀取購物車的商品形成訂單,當下單完成,訂單要負責呼叫購物車服務清除已經購買的商品.現在有個問題出現了,設a服務的服務位址為 設b的服務位址為 此時我們要呼叫api是不是需要把ip和埠硬編碼到**中,好一點的方式放到配置檔案.可是這不太好,既然我們是微服務,我們是分布式,那必須得高大上.
高大上的第一步引入eureka(註冊微服務)
高大上的第二步引入ribbon(負載均衡)
上邊咱們說到,如果只有乙個a訂單服務,那麼a掛掉了,咋辦,使用者下不了單?這不妥,這樣的東西怎麼能出現在乙個健康的生態環境呢?所以ribbon來了.他可以做負載均衡,好了,很直白了.玩過nginx的都知道,a1,a2兩個伺服器,a1掛掉了,nginx引導我們訪問a2.ribbon大概做的也是這個事情.但是首先說一點,ribbon本身是依賴eureka的,那麼怎麼配置ribbon呢?其實不用,當我們把a服務註冊到ribbon時,b服務通過a服務那個牛逼的aaa服務名呼叫時,ribbon已經在工作了.這裡我們需要嘮一嘮ribbon實現負載均衡的步驟.當客戶端去通過aaa這個別名去訪問a伺服器時,ribbon會先從先找到eureka集群,通過他自己的牛逼演算法,算出來,當前哪乙個eureka狀態較好,然後他就從這個eureka中拿到被註冊的所有別名和他們的實際ip.如果aaa這個別名對應的只有a1這乙個訂單伺服器,那沒得選,就用它,如果aaa這個別名對應了兩個訂單服務a1,a2那麼ribbon將使用他牛逼的演算法,找出狀態較好的訂單服務,然後訪問它.(ps對演算法不了解的我,只能說牛逼的演算法..所以大家還是要多看書)
高大上的第三步引入feign(另一種訪問方式)
服務之間的呼叫就真的只能 httpclient.post(url,responseobj)這種方式嗎?no!身為乙個高階的程式設計師,我們習慣抽象,習慣用註解,我們要直接,我們要面向介面.所以feign就誕生了.我們將建立乙個介面,在這個介面上放上註解,放上需要訪問的位址.別的我們什麼都不做,然後客戶端呼叫這個介面,由這個介面自己搞什麼httpclient.(ps對於某些程式設計師來說,這個操作好像顯示的很浮誇,通過httpclient訪問不好嗎?何況springboot已經幫我們最大限度的封裝了.何必在建立乙個莫須有的介面呢?嗯,實際上我就是這類人,不過,人家有這個東西,並且能在springcloud生態系統中混得風生水起,那自然有他們自己的高明之處可以不用,但是不要diss)
高大上的第四步引入是hystrix(熔斷器)
這個熔斷器講真的,我覺得他的名字比負載均衡還牛逼.熔斷,熔斷,莫名我就想起乙個大爐子,武俠**中打造兵器的那種大熔爐.書歸正題,其實沒有那麼神奇啦.我們思考乙個場景,如果a訂單服務呼叫b購物車服務,這是購物車服務他內部計算錯誤了,比如1/0了.呵呵呵.(ps在模擬丟擲異常時,我百分比用這個,不用丟擲,也不用捕獲.寫的還少.)那這事b購物車服務將不能正常返回資料給a購物車.那怎麼辦,a服務也要跟著拋異常.這不好,非常不好,不能因為你自己搞事情,就要整個生態系統一塊搞事情啊.那麼我們能怎麼解決呢?兩種方式,第一:在a呼叫處做判斷,如果拿到的資料結構不是合格的,客戶端做容錯處理.第二:在b服務提供處做處理,如果發現自己拋異常了,提前捕獲掉,不要連累呼叫者,並且返回乙個友好的格式通知呼叫者,我內部搞事情了,你自己保重.這是兩種常規做法,那略微高階點,我們可以做aop操作,用過springboot的同志們都知道,在springboot中有乙個註解可以在controller節點處理異常,這其實也是aop操作.好了.說了這麼多我們還是看看hystrix是怎麼玩的.對於客戶端容錯和服務端容錯hystrix都可以支援.對於服務端來說,只用把在controller方法處使用註解,給註解乙個值這個值可以是某個類的某個方法,如果是本類方法,則可以直接寫方法名.這樣在異常出現是,hystrix就執行這乙個備用方法,返回客戶端資訊.至於客戶端,feign是支援hystrix的,之前我們說過,當我們使用feign宣告服務時,可以只寫乙個介面,那在feign上使用熔斷器只需要寫乙個服務的實現類就可以了,服務的哪個方法異常,hystrix就呼叫實現類的哪個方法.這也許也是feign立足之地的一方面吧.
高大上的第五步引入zuul(路由閘道器)
還記得我們最開始給a服務配置的aaa這個牛逼的別名不?我們雖然給a服務配置了別名,但是這個別名也只能是在生態系統內部使用,在具體點,只有發現eureka服務才可以使用這個別名對a服務進行訪問.如果你從瀏覽器訪問http://aaa/product/get ... 那肯定是訪問不到的.但是引入了zuul閘道器就不同了,首先我們做乙個zuul閘道器,並將這個閘道器註冊到eureka服務,自然而然zuul就可以在eureka中找到儲存別名的名單.這是我們訪問zuul服務+別名也是可以訪問a服務的.例如的zuul服務位址是那麼我們就能用/aaa/product/get來請求訂單服務了.除此之外,我們還可以對aaa這個服務在進行乙個別名對映.我們配置乙個指定的路徑例如/product/**然後在配置乙個具體的eureka對映路徑aaa這樣我們訪問/product的所有請求都會被**到aaa這個微服務中.除此之外,對於每乙個zuul我們還能增加一層過濾器,通過繼承zuul的抽象類,然後覆蓋其中的方法,就可以對該閘道器進行過濾.
關於springcloud生態系統還有很多有用的中介軟體可以使用,每個中介軟體的自己的功能特性,我們在專案中,可以根據實際情況選擇適用當前專案的中介軟體.
spring cloud快速指引
獲取當前服務例項的監控狀況 只能監控單個例項 http localhost 7901 hystrix.stream 獲取多個服務的例項的監控狀況 http localhost 8031 turbine.stream 可以指定要監控的服務,加?cluster microservice consumer...
SpringCloud微服務初步認識
什麼是微服務呢？就目前而言，對於微服務並沒有乙個統一的，標準的定義。但通常而言，微服務架構是一種架構模式，或者說是一種架構風格，它提倡將單一的應用程式劃分為一組小的服務，每個服務執行在其獨立的自己的程序內，服務之間相互協調，互相配置，為使用者提供最終價值。服務之間採用輕量級的通訊機制相互溝通，每個服...
快速認識OTS
ots 是open table service的簡稱，現在已更名為 儲存table store，官網對它的解釋為 ots是構建在阿里雲飛天分布式系統之上的 nosql 資料庫服務，提供海量結構化資料的儲存和實時訪問。ots 以例項和表的形式組織資料，通過資料分片和負載均衡技術，達到規模的無縫擴充套件...