SpringCloud微服務原理、學習、使用
SpringCloud微服務
微服務的模式和形式我在前面已經進行部分的提及,但是一直沒落實到技術層面,這段時間我也在次研究了一下微服務,下面我先貼出SpringCloud整體涉及的結構
上面展示的這些是SpringCloud整體的結構
先對這些空間做一個初步的介紹:
Ribbon,客戶端負載均衡,重試機制。
Hystrix,客戶端容錯保護,服務熔斷、請求緩存、請求合併、依賴隔離。
Feign,聲明式服務調用,本質上就是Ribbon+Hystrix(優化代碼,避免直接使用RestTemplate的混亂)
Bus,消息總線,配合Config倉庫修改的一種Stream實現,
獨自啓動不需要依賴其它組件。
Eureka,服務註冊中心,特性有失效剔除、服務保護。
Dashboard,Hystrix儀表盤,監控集羣模式和單點模式,其中集羣模式需要收集器Turbine配合。
Zuul,API服務網關,功能有路由分發和過濾。
還有其它服務空間,包括configuration等等
那麼什麼是註冊中心呢?
註冊中心,是服務的提供者發佈自己服務的地方,傳統手寫的restful接口提供的服務會涉及到服務發佈者的端口IP等等,通過註冊中心可以直接調用已經發布在上面的服務,只需要通過服務名即可
從圖中可以看出,服務提供者將自己的服務發佈到註冊中心,消費者從註冊中心取出服務,然後消費,這樣生產者只需要關注自身的業務,將自己的服務發佈到註冊中心就行了,消費者無需關注生產者的內容,只需要從註冊中心取出服務就行了,這樣將生產者和消費者直接的耦合給斷絕了
爲什麼使用Restful?
首先springcloud對比dubbo,最大的特點之一就是使用Restful的模式進行交互,dubbo是基於RPC進行通信的,而Restful是基於Http協議進行的,從協議的角度上來說Http和RPC都是基於TCP進行研發的協議,Http是最廣泛的,不僅支持瀏覽器還支持各種APP通信,這麼來說吧Http就是大家都在用的協議,而RPC是針對某一個平臺某一個環節針對性開發的自定義協議,Http由於大衆化,所以本身協議會有點笨重,解析起來自然也比RPC要慢,這也是RPC的優勢之一,但是Http具有良好的跨平臺性質,如下圖:
SpringCloud服務的橫向拓展
使用SpringCloud的另一個目的就是便於服務的橫向拓展,大家都知道,當某一個服務由於訪問壓力變成瓶頸的時候,我們常常希望這個服務能進行負載均衡,分攤壓力,以便於更好的像外界提供服務
我們可以在圖片中看出,用戶服務是具有兩個實例的,但是消費者並不知道用戶服務是具有兩個實例,消費者只知道,當前有用戶服務對外提供服務,所以消費者只需要知道服務名就行了,不用在意是哪個服務實例對其提供服務,這樣也是進一步封裝生產者對外提供服務,同時做了負載均衡,這樣加入用戶服務突然增加業務量,那麼我們只需要再運行多個用戶服務的實例即可
SpringCloud熔斷機制
在開始熔斷機制原理講解之前,先理解一下什麼是服務依賴
從圖片上來看,第一行服務A是調用服務B,第二行服務A調用服務B,服務B調用服務C,這樣就有一個服務鏈,A->B->C,假設現在由於網絡動盪或者服務器奔潰的原因,服務C掛掉了,然而服務A的訪問仍然很大,這樣服務A繼續請求服務B,而服務B由於無法調用服務C一直在等待,最後導致請求過多,服務B也被壓垮了
熔斷的原理
熔斷的原理其實就和保險絲差不多
當C服務停止的時候,B自動調用寫死的數據進行回覆,從而避免因爲請求過多導致A服務奔潰的情況
以上就是大致一些原理,我對一些demo已經做了修改併發布到github上面
感興趣的朋友可以先下載看看源碼,後續會進一步講解
github:https://github.com/zsljaygeskjay/springcloud