SpringCloud實戰6-Zuul閘道器服務
為什麼需要閘道器呢?
我們知道我們要進入一個服務本身,很明顯我們沒有特別好的辦法,直接輸入IP地址+埠號,我們知道這樣的做法很糟糕的,這樣的做法大有問題,首先暴露了我們實體機器的IP地址,別人一看你的IP地址就知道服務部署在哪裡,讓別人很方便的進行攻擊操作。
第二,我們這麼多服務,我們是不是要挨個呼叫它呀,我們這裡假設做了個許可權認證,我們每一個客戶訪問的都是跑在不同機器上的不同的JVM上的服務程式,我們每一個服務都需要一個服務認證,這樣做煩不煩呀,明顯是很煩的。
那麼我們這時候面臨著這兩個極其重要的問題,這時我們就需要一個辦法解決它們。首先,我們看IP地址的暴露和IP地址寫死後帶來的單點問題,我是不是對這麼服務本身我也要動態的維護它服務的列表呀,我需要呼叫這服務本身,是不是也要一個負載均衡一樣的玩意,
還有關於IP地址暴露的玩意,我是不是需要做一個代理呀,像Nginx的反向代理一樣的東西,還有這玩意上部署公共的模組,比如所有入口的許可權校驗的東西。因此我們現在需要Zuul API閘道器。它就解決了上面的問題,你想呼叫某個服務,它會給你對映,把你服務的IP地址對映成
某個路徑,你輸入該路徑,它匹配到了,它就去替你訪問這個服務,它會有個請求轉發的過程,像Nginx一樣,服務機器的具體例項,它不會直接去訪問IP,它會去Eureka註冊中心拿到服務的例項ID,即服務的名字。我再次使用客戶端的負載均衡ribbon訪問其中服務例項中的一臺。
API閘道器主要為了服務本身對外的呼叫該怎麼呼叫來解決的,還有解決許可權校驗的問題,你可以在這裡整合呼叫一系列過濾器的,例如整合shiro,springsecurity之類的東西。
Zuul可以通過載入動態過濾機制,從而實現以下各項功能:
1.驗證與安全保障: 識別面向各類資源的驗證要求並拒絕那些與要求不符的請求。
2.審查與監控: 在邊緣位置追蹤有意義資料及統計結果,從而為我們帶來準確的生產狀態結論。
3.動態路由: 以動態方式根據需要將請求路由至不同後端叢集處。
4.壓力測試: 逐漸增加指向叢集的負載流量,從而計算效能水平。
5.負載分配: 為每一種負載型別分配對應容量,並棄用超出限定值的請求。
6.靜態響應處理: 在邊緣位置直接建立部分響應,從而避免其流入內部叢集。
7.多區域彈性: 跨越AWS區域進行請求路由,旨在實現ELB使用多樣化並保證邊緣位置與使用者儘可能接近。
接著下來進行實戰小Demo
第一步,在原來的工程下,新建一個Zuul模組,引入依賴,程式碼如下:
<dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-eureka</artifactId> <version>1.3.5.RELEASE</version> </dependency> <dependency> <groupId>org.springframework.cloud</groupId> <artifactId>spring-cloud-starter-zuul</artifactId> <version>1.3.5.RELEASE</version> </dependency>
接著在啟動類上打上@EnableZuulProxy註解,程式碼如下:
server: port: 5000 spring: application: name: api-geteway zuul: routes: #標識你服務的名字,這裡可以自己定義,一般方便和規範來講還是跟自己服務的名字一樣 hello-service: #服務對映的路徑,通過這路徑就可以從外部訪問你的服務了,目的是為了不爆露你機器的IP,面向服務的路由了,給你選一個可用的出來, #這裡zuul是自動依賴hystrix,ribbon的,不是面向單機 path: /hello-service/** #這裡一定要是你Eureka註冊中心的服務的名稱,是所以這裡配置serviceId因為跟eureka結合了,如果單獨使用zuul,那麼就必須寫自己機器的IP了, #如url:http://localhost:8080/ 這樣的不好就是寫死IP了,萬一這IP掛了,這高可用性,服務註冊那套東西就用不起來了 serviceId: hello-service eureka: #客戶端 client: #註冊中心地址 service-url: defaultZone: http://localhost:8888/eureka/,http://localhost:8889/eureka/
接著啟動先前文章中的註冊中心和兩個hello-service服務提供者,接著我們執行,看一下它的請求轉發功能,看他有沒有輪詢進入兩個服務,
輸入localhost:5000/hello-service/hello,如下:
接著再重新整理一遍:
可以看到zuul進行了請求分發了。它是根據你的服務名字hello-servie來對映到具體的機器上,這不就是一個反向代理的功能嗎?
zuul還能進行請求過濾,那麼我們進行一下token校驗來演示一下,首先我們需要先新建一個TokenFilter類來繼承ZuulFilter這個類,實現它的四個介面,程式碼如下:
package hjc.zuul; import com.netflix.zuul.ZuulFilter; import com.netflix.zuul.context.RequestContext; import javax.servlet.http.HttpServletRequest; /** * Created by cong on 2018/5/18. */ public class TokenFilter extends ZuulFilter { //四種類型:pre,routing,error,post //pre:主要用在路由對映的階段是尋找路由對映表的 //routing:具體的路由轉發過濾器是在routing路由器,具體的請求轉發的時候會呼叫 //error:一旦前面的過濾器出錯了,會呼叫error過濾器。 //post:當routing,error執行完後才會呼叫該過濾器,是在最後階段的 @Override public String filterType() { return "pre"; } //自定義過濾器執行的順序,數值越大越靠後執行,越小就越先執行 @Override public int filterOrder() { return 0; } //控制過濾器生效不生效,可以在裡面寫一串邏輯來控制 @Override public boolean shouldFilter() { return true; } //執行過濾邏輯 @Override public Object run() { RequestContext context = RequestContext.getCurrentContext(); HttpServletRequest request = context.getRequest(); String token = request.getParameter("token"); if (token == null){ context.setSendZuulResponse(false); context.setResponseStatusCode(401); context.setResponseBody("unAuthrized"); return null; } return null; } }
filterType:返回一個字串代表過濾器的型別,在zuul中定義了四種不同生命週期的過濾器型別,具體如下:
1.pre
:可以在請求被路由之前呼叫,用在路由對映的階段是尋找路由對映表的
2.route
:在路由請求時候被呼叫,具體的路由轉發過濾器是在routing路由器具體的請求轉發的時候會呼叫
3.error
:處理請求時發生錯誤時被呼叫
4.post
:當routing,error執行完後才會呼叫該過濾器,是在最後階段的
這裡宣告一下zuul過濾器執行網路請求發生的異常,過濾器裡面是不能直接將try-catch捕捉的異常丟擲給頁面的。應用程式丟擲的異常是可以返回出的需解決辦法就是在catch裡面用context.set()方法返回給頁面。如下:
try{ 業務邏輯...... }catch(Exception e){ RequestContext context = RequestContext.getCurrentContext(); context.set("error.status_code",401); context.set("error.exception",e); context.set("error.message","sfdfsdf"); }
接著,你還需要把這個過濾器加入spring中,讓spring管理,程式碼如下:
package hjc; import hjc.zuul.TokenFilter; import org.springframework.boot.SpringApplication; import org.springframework.boot.autoconfigure.SpringBootApplication; import org.springframework.cloud.netflix.zuul.EnableZuulProxy; import org.springframework.context.annotation.Bean; @SpringBootApplication @EnableZuulProxy public class ZuulApplication { public static void main(String[] args) { SpringApplication.run(ZuulApplication.class, args); } //將過濾器交給Spring管理 @Bean public TokenFilter tokenFilter(){ return new TokenFilter(); } }
接著,讓我們啟動啟動類,先進行不帶token的訪問,如下:
可以看到,返回一個沒許可權的資訊,這裡要說一下,Token一般都是放在請求頭中的,這裡我們只是為了演示才沒那麼幹,
接著將token帶上再去訪問,如下:
可以看到這是已經將我們的請求放過去了。
這裡我還要講一下什麼是預設路由,將zuul的配置刪除路由配置,如下:
server: port: 5000 spring: application: name: api-geteway eureka: #客戶端 client: #註冊中心地址 service-url: defaultZone: http://localhost:8888/eureka/,http://localhost:8889/eureka/
接著,重啟繼續訪問,如下:
、
可以看到,還是能繼續訪問,我們什麼都沒配,居然還能訪問,那是因為,這裡預設用你的服務名字hello-service自動聲明瞭。
那麼,如果說我不想讓它幫我自動宣告,我要我自己定義,那麼可以在yml配置檔案中使用zuu.ignored-services就可以把自己像過濾的過濾,如下:”
zuul: #如果ignored-services:* 表示所有的預設路由都失效了,要自己一個個配,沒人會那麼操蛋,除非遇到奇葩業務 ignored-services:
接著我們再說一下對映規則,比方說
zuul: routes: #標識你服務的名字,這裡可以自己定義,一般方便和規範來講還是跟自己服務的名字一樣 hello-service: #服務對映的路徑,通過這路徑就可以從外部訪問你的服務了,目的是為了不爆露你機器的IP,面向服務的路由了,給你選一個可用的出來, #這裡zuul是自動依賴hystrix,ribbon的,不是面向單機 path: /hello-service/** #這裡一定要是你Eureka註冊中心的服務的名稱,是所以這裡配置serviceId因為跟eureka結合了,如果單獨使用zuul,那麼就必須寫自己機器的IP了, #如url:http://localhost:8080/ 這樣的不好就是寫死IP了,萬一這IP掛了,這高可用性,服務註冊那套東西就用不起來了 serviceId: hello-service zuul: routes: hello-service: path: /hello-service/ext/** serviceId: hello-service
這裡的兩個zuul配置對映路徑都有/hello-service/,可以看到/hello-service/**是包括/hello-service/ext/**的,這兩個路徑進行匹配的時候是不是有衝突呀,怎麼處理呢?誰先匹配呢?
這裡是yml中定義的順序來匹配的。如果是application.properties格式的配置檔案,它這個順序是不能保證的,yml格式的配置檔案是有順序的,可以保證,這裡要注意下一下。
如果我們想定義一下匹配規則怎麼辦呢?那麼我們就需要在啟動類中定義一個bean,這個類就是決定你的路由的,如下:
這裡就不演示了,需要用到的時候自己再去慢慢查詢資料吧。
還有就是ignored-patterns:,如下:
zuul: routes: #標識你服務的名字,這裡可以自己定義,一般方便和規範來講還是跟自己服務的名字一樣 hello-service: #服務對映的路徑,通過這路徑就可以從外部訪問你的服務了,目的是為了不爆露你機器的IP,面向服務的路由了,給你選一個可用的出來, #這裡zuul是自動依賴hystrix,ribbon的,不是面向單機 path: /hello-service/** #這裡一定要是你Eureka註冊中心的服務的名稱,是所以這裡配置serviceId因為跟eureka結合了,如果單獨使用zuul,那麼就必須寫自己機器的IP了, #如url:http://localhost:8080/ 這樣的不好就是寫死IP了,萬一這IP掛了,這高可用性,服務註冊那套東西就用不起來了 serviceId: hello-service ignored-patterns: /hello/**
ignored-patterns:表示遮蔽掉/hello/**的路徑,就算你/hello-service/hello/**也不行,照樣遮蔽。這個配置我們可以進一步細化,比如說我不想給/hello介面路由,那我們可以按照上面方式配置
如果我們還想配置一個服務的字首該怎麼辦?程式碼如下:
zuul: routes: #標識你服務的名字,這裡可以自己定義,一般方便和規範來講還是跟自己服務的名字一樣 hello-service: #服務對映的路徑,通過這路徑就可以從外部訪問你的服務了,目的是為了不爆露你機器的IP,面向服務的路由了,給你選一個可用的出來, #這裡zuul是自動依賴hystrix,ribbon的,不是面向單機 path: /hello-service/** #這裡一定要是你Eureka註冊中心的服務的名稱,是所以這裡配置serviceId因為跟eureka結合了,如果單獨使用zuul,那麼就必須寫自己機器的IP了, #如url:http://localhost:8080/ 這樣的不好就是寫死IP了,萬一這IP掛了,這高可用性,服務註冊那套東西就用不起來了 serviceId: hello-service prefix: /api/**
可以看到那麼你訪問的服務都必須要加/api/字首,例如/api/hello-service/**
如果我們還想進行一個路徑訪問就跳轉到我的本地,那該怎麼辦呢?
我希望使用者在訪問/local時能夠自動跳轉到這個方法上來處理,那麼此時我們需要用到Zuul的本地跳轉,配置方式如下:
zuul: prefix: /api ignored-patterns: /**/hello/** routes: local: path: /hello-service/** url: forward:/local
我們常用的一些,對接springsecurity,或者是一些第三方元件,它們會獲取你的一些cookie資訊,那麼Zuul閘道器為了安全起見,把你的cookie資訊都給幹掉了,這個是沒辦法去搞cookie的。它是預設幹掉的。
這裡Zuul提供了zuul.sensitive-headers來給你搞這些cookie,header,這些資訊不要進行過濾。控制你的敏感資訊。
預設情況下,敏感的頭資訊無法經過API閘道器進行傳遞,我們可以通過如下配置使之可以傳遞:
zuul: routes: hello-service: path: /hello-service/** serviceId: hello-service sensitive-headers: cookie,header之類額東西
還可以配合Hystrix的一些詳細配置一起使用,前面也講過了。這裡就不說了