SpringCloud微服務_1 Ribbon實現客戶端負載均衡

               SpringCloud微服務_1 Ribbon實現客戶端負載均衡

                                                                                                                            作者:田超凡

版權所有,轉載請註明原作者,仿冒侵權必究法律責任

 

1 Ribbon+LoadBalance基本概念和實現原理        

在客戶端採用輪詢的機制從註冊中心基於REST傳輸機制(HTTP+JSON)一次性獲取所有已經註冊的服務列表並封裝爲Map返回到客戶端HTTP線程池中,由於ribbon採用的是LocalThread和線程池的機制,所有客戶端加載的註冊中心服務列表每個服務都存在不同線程池中,線程池和線程池完全艙壁,基於LocalThread共享註冊中心公共資源,但是對於每個服務所佔用的線程數量卻是相互隔離的,確保微服務架構的彈性和容災性(當然這只是一種基本的保護機制,主要的微服務容災處理和事件響應定時渲染機制以及可伸縮性的保障需要結合Hystrix熔斷器使用,後期再專門針對Hystrix熔斷機制和容災防護實現原理做相關補充說明),ribbon在客戶端輪詢到的服務列表會根據url中的serviceid進行解析,解析成serviceid對應的主機和端口號,然後就可以基於REST傳輸機制進行服務調用,這是基本原理。


       再來說下實現,首先引入starter依賴,然後在Spring ioc配置類中註冊RestTemplate組件,使用LoadBalanced標註RestTemplate,表示對RestTemplate調用機制採用ribbon,然後在需要調用服務的地方注入RestTemplate,RestTemplate封裝了各類針對不同請求方式的調用方法,總的來說按調用服務返回類型分爲2種,一種是直接顯式指定調用服務接口返回類型並接收對應類型數據,一種是統一返回spring-web內置的ResponseEntity,這是一個泛型類,封裝了HTTP請求頭,請求體,響應頭,響應體,請求類型,狀態響應碼等HTTP協議請求響應機制基本信息。當然了,這樣對於跨服務參數傳遞還是不太方便,尤其是提供者定義的服務接口中的方法參數形態各異的情況。沒關係,這一點RestTemplate早都幫我們考慮到了,提供了通用的基於豪豬Hystrix的通用斷路方法exchange,可以直接以參數的形式一次性指定請求url,請求方式,請求參數(HttpEntity泛型包裝機制,構造注入參數和HttpHeaders請求頭),返回類型。是不是一下子全都搞定了!當然了,這個方法也有一個瓶頸,就是返回值都是ResponseEntity,不過也可以理解,畢竟面相層級不同,如果說Object所有子類都是一圈,那麼ResponseEntity強大泛型也是一圈,對於響應數據類型的靈活性來說,當然是ResponseEntity更勝一籌,springcloud官方推薦的方法自然也是exchange了,不然豪豬的意義根本體現不來。由於ResponseEntity在原始架構中的作用基本是作爲通用層的控制器處理方法響應模型類,通用層數據響應模型的規範性和重要性肯定是不言而喻的,畢竟隨着架構升級演變,ResultT站到最後。再說一下關於ribbon和nginx的區別,ribbon是客戶端負載均衡,nginx是服務器端負載均衡,就功能完整性來說,肯定是nginx功能更加完善,因爲nginx除了負載均衡還有反向代理等功能,但是請記住nginx永遠只作用在服務器端,而且要進行大量複雜的配置和搭建集羣,不然服務器一旦出現問題,nginx就手足無措了,並且nginx安裝使用過的都知道,太重!這和SpringBoot提倡的微型和輕便完全是大相徑庭,所以在SpringBoot2.0到來之後,也就是SpringCloud微服務框架問世之後,nginx的地位被逐漸縮小,SpringBoot和SpringCloud也就把他趨之門外了。同時,ribbon得到了廣泛的支持,無論是配置的靈活性還是體型的輕量級都做到了極致,在客戶端負載均衡調度器角色上愈演愈烈。


2 Feign實現聲明式負載均衡服務調度器

        對於服務調用方式,其實除了ribbon還有一個聲明式的客戶端負載均衡調度器feign,相比較對於服務之間依賴關係比較複雜和服務接口數量龐大的微服務體系中,使用聲明式調度器feign的頻率更高,因爲feign調用機制底層實際上還是基於ribbon實現的,但是feign針對請求信息的組裝機制更加靈活,可以把需要調用的服務的所有方法統一定義在一個接口中,基於FeignClient註解指定需要調用的服務提供者,基於各類Mapping註解標註接口方法,feign會基於JDK動態代理機制掃描所有EnableFeignClients註解中指定的基準包及其子包中的所有FeignClient映射接口並註冊動態代理實例,根據接口中方法的簽名和服務提供者信息自動構建請求信息並調用對應服務提供者中和Feign映射接口對應方法簽名相同的方法執行,在視圖層控制器就可以直接注入Feign映射接口並調用接口中的方法實現服務調用,Feign優點就是服務調用方式更加靈活,由於把需要調用的服務方法封裝成了接口,所以對於請求服務信息的組裝更加靈活,同時對於需要調用的服務提供者數量比較多和微服務之間關係比較複雜的情況下,Feign的調用關係清晰,這樣做的好處就是,當服務提供者信息出現變動,只需要改動消費者的Feign映射接口部分聲明信息即可,如果是使用傳統ribbon原始方式調用服務,每次調用的url都是顯式指定了的,如果調用次數很多改動量可想而知,間接破壞微服務架構的彈性和伸縮性。Feign還提供了服務降級機制實現高可用提高伸縮性,具體的服務降級機制實現和高可用實現原理放到後續Hystrix總結再來細說。綜上所述,所以在客戶端負載均衡調用機制的臨牀運用中,Feign調用機制更爲常用。

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