1. 程式人生 > >Spring Cloud的Zuul高可用的理解

Spring Cloud的Zuul高可用的理解

之前做過一個專案,是將頁面渲染都放在了zuul上,然後在zuul所在的微服務中用Feign去請求service層的資料。

這樣一來,我其實沒有用到Zuul的閘道器功能,所以我後來就Zuul給去掉了。。。

但是我部署的方式是分散式的,所以我打算想要把把它單獨拿出來做負載均衡。

然後在四臺伺服器上各自放了一個Feign服務(之前叫Zuul服務的),本來應該有Zuul做負載均衡的,結果我的一個學長告訴我說,Zuul比不上Nginx,所以後來的結果就是我沒有用Zuul。整個專案就把Zuul服務去掉了。。。

回頭一想,不行啊,不是說Spring Cloud是做了一個完整的體系的麼?負載均衡,門面啊,咋這坑呢?

然後我讀了周立的《Spring Cloud與Docker微服務架構實戰》,可能我的理解有點慢,所以思考了半天,有點眉目了。感覺網上也好多地方沒有明說,也看到有人提問,但是沒人回答。。。我想寫一下。

以下是我的理解:

18年11月24日新增:

作為大四找實習的學生,昨天被問有沒有部落格,我很光棍說了沒有。。。結果今天無聊點開自己的csdn,前幾天在家寫的東西,居然有288的瀏覽量。感覺那時候寫的不是很好,加上最近學到的一些東西。修改修改

在Spring Cloud中國社群的QQ群內看各位大佬們聊天。結合自己腦袋裡的一點東西,想到一個完整的思路。

思路〇:

  • 在最外部,做Nginx的負載均衡。這裡知道所有zuul服務的地址。可以把請求分發到正確的zuul中。
  • 再加上Zuul做服務閘道器,這裡做zuul的路由功能,以及鑑權的任務。
    • 可以加一個過濾器方面的功能。通過藉助閘道器的特點,還可以做對外部的其他應用呼叫Mysql,Redis這些東西的鑑權。或者說路由
    • 建議是把zuul之後的東西放在內網訪問。如果非要跨越千山萬水,那就加上view模組裡的Feign和Freemarker。減少網路開銷。而且如果對鑑權不是很感冒的話,直接把Zuul去掉就好了。簡單粗暴
  • 接下來是Feign或者Ribbon部分。這裡做資料的請求,包裝的這些工作。這裡對其他資料服務的包裝作用,把不同位置的資料整合到一塊來,同一個服務裡可以請求SaaS那兒的資料,還可以去拿自己寫的資料服務。這裡有Hystrix需要注意。
    • 在這一級,Feign可以有倆種類型,一種是專門提供rest風格的資料介面展現
    • 另一種是結合Freemarker方面的東西,做頁面渲染。在這裡有個css,js,pic這些的靜態資源。如果有條件可以把這些放在cdn裡面,那速度,美滋滋。
    • 不過我以前經歷過一個事兒!就是pic本來是動態生成的!但是cdn非要給你優化,程式設計師給那些圖片的名字都是一樣一樣的!然後所有人下載證書的時候,都下載成了一個人的。。。。。。我被拉過去做了一個多月的客服,一直搞不清楚這是為啥。那邊擅自做了cdn,我們不知道的情況下,那幾天頭都炸了!
  • 最後邊需要開發的就是涉及Mybatis部分的內容了。這一層比較容易了,針對某個資料庫去做一個服務,每個表做個Dao。
    • 至於其他地方的資料呼叫的話,就不要放在這一層了。網路開銷儘量少一點吧。這裡還是好好的放在內網裡,讓自家的Feign或者Ribbon部分去呼叫就好了。

思路一:

Zuul是分為倆部分,一個是Zuul的服務端,另一個是Zuul的客戶端。他們都是註冊在Eureka這樣的註冊中心上的。

  1. Zuul客戶端,對外網公開的

    設想為只部署一個。只做到Zuul服務端的路由功能。負責負載均衡和向Eureka註冊的功能。不做過濾器,和到其他服務的路由。這個地方用到的東西儘量少一點。不求達到Nginx的水平,但是減少多餘的處理。而且不做驗證,如果可以,關閉到除了路由以外的其他步驟。這樣子就不用外邊加一個單獨的Nginx了。
  2. Zuul服務端,針對於內網中的

    做一些必要的路由和過濾器,服務端設立的出發點就是要部署多個,以達到高可用的目的。在這個部分,可以加上頁面渲染的模組。也就是把Ribbon層或者Feign層加到這裡面來,在這個服務中加上Freemarker來渲染資料。在同一個服務中處理這部分內容,減少http請求中的網路耗時。

現在再思考一下,覺得這個方法可能有些不靠譜。因為這樣子相當於增加了一個外部的模組開發。有些多次一舉的感覺了。

不過呢,zuul這裡的思路,就是把其中的一個zuul作為負載均衡。不用Nginx的前提下對外公開的那種。那樣子可以把鑑權,路由到其他地方的功能加到那個Zuul裡面。只要負載均衡不至於被影響,那應該也是可以做為一個備選方案的。

思路二:

這個是我之前用過的方法,但是我覺得有點子坑。

就是把Zuul只作為一個整體,不分服務端客戶端啥的,該做的都正常的做。做路由,做過濾,加Ribbon或者Feign,做Freemarker渲染。

這裡也需要吧Zuul註冊到Eureka上,畢竟裡面有用到路由和Ribbon或者Feign。

將這個服務部署到多個伺服器上,或者部署到多個埠上,通過主伺服器上的Nginx做負載均衡。。。

這是我去年做的一個專案的方法。

以上是我的思路,如果有什麼問題,還請指出。可以一起討論一下。沒準能鬧出個非常方便的思路