現在我們來設想一個場景,當前起了10個微服務,比如訂單,廣告,商品,支付,用戶,等等等等,那客戶端要怎么調用呢,和每一個服務一個一個打交道,這顯然是不現實的,肯定需要一個角色,來充當request請求的統一入口,充當這個角色的,就是服務網關,一旦有了服務網關,所有請求都通過它,隨著而來我們可以想一下,他要發揮什么作用,他要具備什么樣的要素

一旦有了服務網關,所有請求都通過它,隨著而來我們可以想一下,他要發揮什么作用,他要具備什么樣的要素,服務網關作為請求的入口,可以預見他必須保證,24小時可用,網關癱瘓,系統全掛,完全不能對外服務,影響可能是致命的,所以穩定性和高可用,是我心目中對網關的第一要求,第二點是性能和并發性,所有的請求都會經過網關,可想而知,網關的訪問壓力是巨大的,所以網關的性能也必須高,然后網關的安全性也是非常注重的,要確保服務使用的安全,防止外部的惡意訪問,有些比如金融行業,它會采用通信數據加密措施,最后是擴展性,因為各種請求都經過網關服務,所以網關上大有文章可做,理論上網關上是處理費業務功能的絕佳場所,諸如協議轉發,防刷,流量管控,日志監控,都可以考慮,大家要明白,網關并不是微服務出現后的新鮮事物,業界的成熟網關方案挺多的,我舉一些例子吧,常見的有Nginx+Lua,Nginx大名鼎鼎,用的也非常的多,性能和高可用是Nginx傲視群雄的資本,它性能極高,先天的全異步IO設置,極少的進程間切換,以及許多優化設計,都使得Nginx天生適合高并發請求,擴展性上Nginx做的非常棒,它本身上被設計為不同層次不同類型,且耦合度極低的模塊組成,當對某一個模塊修復Bug,或者升級時,國內就有很多基于Nginx二次開發的,比如KONG,它是API管理軟件,他本身是基于Nginx+Lua的,但是比Nginx提供了更簡單的配置方式,由于本身是源于Nginx,所以在性能和穩定性上,是沒有什么大問題的,不過KONG是一款商業軟件,有很多付費的商業插件,所以這個東西好還是很好地,就是得花錢,然后下一種方案就是TYK,Tyk是一種開源的,輕量級快速可伸縮的API網關,支持配額和速度限制,支持認證數據分析,支持多用戶多組織,感覺一直為他打廣告,各種好處,他還提供全RESTFul API,值得注意,Tyk是GO語言開發的,大家應該有所了解,GO語言最近也是特別的火,作為GOOGLE爸爸的親兒子,GO在并發編程上,從語言層面上,就有天然的優勢,Tyk在性能和擴展性上,最后就是我們的主角,Spring Cloud Zuul,Zuul是Netflix出品的基于路由和服務端的負載均衡器,可以說他天生服務于微服務,這個是他的特點和優勢,Zuul的優勢在于,如果你是以JAVA技術棧為主,構建微服務的話,和Spring Cloud的治理體系,Zuul提供了認證,限流,動態路由,監控,彈性,安全,負載均衡,看我特性特別多,還沒講完,協助單點壓測,靜態響應,等邊緣服務的框架,我是覺得你使用Spring的話,特別是你使用了SpringCloud,那么你再使用Zuul,如果你團隊規模不大,沒有專門的網關開發人員的情況下,Zuul是一款快速的好方案,從前幾個要素來衡量的話,Zuul在性能上,并不具備優勢,直白一些就是不能和Nginx比性能,當然據說,第二代Zuul有較大的提升,但是還是有待觀察,所以這方面我持保留意見,那小伙伴可能要說了,你把Zuul說的這么爛的樣子,那我還學他干嘛,其實話也不能這么說,我們學技術的,一定要靈活,要學會混搭,原始我們的點餐項目,是Nginx在前,tomcat在后,Nginx做了負載均衡和反向代理,現在我們依然可以讓Nginx發揮負載均衡和反向代理的優勢,后面的TOMCAT呢,可以換成Zuul,讓Nginx繼續發揮他性能上的優勢,而讓Zuul好好發揮他性能上的優勢,這不就皆大歡喜了嗎,項目改造工程中,合理利用原來的資源,發揮新加入的事務的優勢,因地制宜解決問題,這一點特別重要,Zull雖然在并發性性能等方面,相較于Nginx呢,那肯定是有所不足,但是他作為SpringCloud完整服務構建體系,前置網關服務,還是一個非常不錯的選擇,有一種說法呢,叫做路由加過濾器,等于Zuul,Servlet的過濾器,相信大家都不會陌生,個人覺得Zuul組建的核心,就是一系列的過濾器,我們用Zull就應該利用Zuul的特點,發揮它的優勢,過濾器可以說是實現API網關,最核心的組件了,每一個進入Zuul HTTP請求,都會經過這一系列的過濾器,處理之后,得到響應并返回給客戶端,Zuul里面定義了四種,標準過濾器類型,第一是前置,路由,后置Post,最后一個是Error,這四個類型會詳細的給大家介紹

這幅圖就是Zuul整個組建的架構圖,可以看到,他們過濾器之間,是沒有直接通信的,他們之間有一個Request Context,就是上下文,通過這來進行數據傳遞

我們在看在Zuul組件里面,一次HTTP請求,生命周期是什么樣子的,上面就是一個請求進來,這些紅的就是他的過濾器,最下面這個Orgin Server,就是我們后面的服務,比如上面提到的Product服務,可以看到進過一系列的過濾器之后,才返回這個請求,那么這些過濾器,我們依次的來看一下,他首先是到Pre過濾器,他不是一個過濾器,在這個類型下面又寫了很多個過濾器類,所以看似一次簡單的請求返回,其實這里實現 還是很復雜很多的,首先到達的是Pre Filter,過濾器,從名字也可以看出來,這里做的事情主要是對路由前置的一些加工,比如我們要做的參數校驗,你就放到這個地方來做,接下來是Routing Filter,Routing Filter做的事情,就是將WEB的請求,給他轉發到Orgin Server上去,那你覺得他這個HTTP請求,他用的方式性能不夠高,或者不夠優雅,你想重寫它的HTTP請求,那么你可以到這個地方來做,再往后呢,POST Filter,這個時候你已經拿到了返回的結果,假如你想對結果進行處理和加工,那么你可以在這個地方來做,下面有一個Error Filter,Error Filter是在上面提到的這三個,過濾器發生異常之后,他就會到達Error Filter,所以如果要做一些統一異常處理的話,你要在Error Filter這個類里來做,最左邊左下方,左下方的Custom Filter,定制的過濾器,他的意思是說我們自己定義的可以放到這邊來,事實上不僅可以放到Pre Filter這邊,也可以放到Post這邊,都是可以的

?

總結

以上是生活随笔為你收集整理的服务网关和Zuul的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。