通過前面幾次的分享，我們了解了微服務架構的幾個核心設施，通過這些組件我們可以搭建簡單的微服務架構系統。比如通過spring cloud eureka搭建高可用的服務注冊中心并實現服務的注冊和發現；
通過spring cloud ribbon或feign進行負載均衡；通過spring cloud hystrix進行服務容錯保護以避免故障蔓延。微服務搭建好了之后我們肯定會提供給外部系統一些統一的restful api服務接口進行調用，
但是當外部系統調用我們的restful api的時候，怎么確定它需要的功能具體是哪個服務提供的呢？這個就涉及到一個路由規則和服務實例列表的維護問題。
這就引入了我們今天的主角--spring cloud zuul，它是基于netflix zuul實現的api網關組件。它可以解決兩個大問題：
- 就是我們上面提到的路由規則和服務實例的維護問題
- 對于一些校驗（比如登錄校驗等）冗余問題。 按照我們的習慣的做法，是在每個服務中都需要加入這些校驗，但是這樣會導致代碼冗余并且維護也比較麻煩，有了spring cloud zuul這個網關服務之后，我們可以將這些共通的校驗放到網關里面統一維護。
好，接下來我們就來看下怎么實現這個網關服務。
一、構建網關，配置路由
這里我們還是需要使用到前面的hello-service和feign-consumer服務。我們之前把feign-consumer作為服務消費者，但是別忘了在eureka體系里面，每個服務既是服務提供者又是服務消費者，所以feign-consumer也是一個服務提供者，并且http://localhost:9001/feign-consumer等接口就是它提供的服務。
接下來我們構建一個網關服務，代碼結構如下：
代碼實現步驟：
新建maven工程api-gateway
修改pom文件
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
|
<project xmlns="http://maven.apache.org/pom/4.0.0" xmlns:xsi="http://www.w3.org/2001/xmlschema-instance" xsi:schemalocation="http://maven.apache.org/pom/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd"> <modelversion>4.0.0</modelversion> <groupid>com.sam</groupid> <artifactid>api-gateway</artifactid> <version>0.0.1-snapshot</version> <parent> <groupid>org.springframework.boot</groupid> <artifactid>spring-boot-starter-parent</artifactid> <version>1.5.1.release</version> </parent> <properties> <javaversion>1.8</javaversion> </properties> <!-- 使用dependencymanagement進行版本管理 --> <dependencymanagement> <dependencies> <dependency> <groupid>org.springframework.cloud</groupid> <artifactid>spring-cloud-dependencies</artifactid> <version>camden.sr6</version> <type>pom</type> <scope>import</scope> </dependency> </dependencies> </dependencymanagement> <dependencies> <!-- 引入zuul依賴 , 它依賴了spring-boot-starter-actuator/spring-boot-starter-hystrix/spring-boot-starter-ribbon--> <dependency> <groupid>org.springframework.cloud</groupid> <artifactid>spring-cloud-starter-zuul</artifactid> </dependency> </dependencies></project> |
新建啟動類
|
1
2
3
4
5
6
7
8
9
10
11
12
|
/** * @enablezuulproxy 開啟zuul 的api網關服務功能 * */@enablezuulproxy@springcloudapplicationpublic class gatewayapp { public static void main(string[] args) { springapplication.run(gatewayapp.class, args); }} |
新建application.properties
|
1
2
3
4
5
6
7
8
9
10
|
server.port=5555spring.application.name=api-gateway#增加路由規則的配置#通過zuul.routes.<route>.path和zuul.routes.<route>.url進行配置，<route>為路由的名字，可以任意指定，但是一組path和url的路由名要相同#如下面的例子：所有滿足/api-a/** 規則的訪問都會被路由轉發到//localhost:9001的地址#也就是說，我們訪問http://localhost:5555/api-a/hello的時候，api網關服務就會將該請#求路由到 http://localhost:9001/hello提供的微服務接口上zuul.routes.api-a.path=/api-a/**zuul.routes.api-a.url=http://localhost:9001zuul.routes.api-b.path=/api-b/**zuul.routes.api-b.url=http://localhost:9090 |
測試，啟動eureka、hello-service、feign-consumer以及本次新加的api-gateway服務，然后訪問http://localhost:5555/api-a/feign-consumer
成功訪問到了feign-consumer的服務接口--feign-consonsumer。
以上步驟實現了傳統路由的配置，這種配置有個大的缺點，就是需要手工在application.properties文件中進行路由規則的配置，當服務很多的時候，維護工作量就會很大。為了減小維護成本，還有另外一種路由--面向服務的路由。
二、面向服務的路由
spring cloud zuul和eureka進行整合，我們可以讓路由的path不是映射具體的url，而是具體的某個服務，而服務的url則交給eureka服務發現機制自動維護,這類路由就是面向服務的路由。具體代碼配置如下：
修改pom文件，引入eureka依賴
|
1
2
3
4
5
|
<!-- 引入eureka依賴 --> <dependency> <groupid>org.springframework.cloud</groupid> <artifactid>spring-cloud-starter-eureka</artifactid> </dependency> |
修改application.properties配置文件
|
1
2
3
4
5
6
|
server.port=5555spring.application.name=api-gatewayzuul.routes.api-a.path=/api-a/**#這里用serviceid代替url，用服務名代替ip+端口號zuul.routes.api-a.serviceid=hello-serviceeureka.client.service-url.defaultzone=http://localhost:1111/eureka |
注意：zuul.routes.api-a.url=hello-service也能實現功能，但是它不能進行正常的負載均衡和容錯保護。
測試,訪問http://localhost:5555/api-a/hello
訪問成功。
三、服務路由的默認規則
在面向服務的路由中，由于<route>名字是隨意起的，那么是不是可以這樣：
|
1
2
|
zuul.routes.hello-service.path=/hello-service/**zuul.routes.hello-service.serviceid=hello-service |
<route>名字就是服務名，其實在實際的應用中，我們往往就是這樣命名的。如果有這樣的規則的話，那zuul就可以幫我們默認實現這樣的功能，進一步省去了配置的麻煩。
我們來做個實驗，將配置文件改為：
|
1
2
3
|
server.port=5555spring.application.name=api-gatewayeureka.client.service-url.defaultzone=http://localhost:1111/eureka |
然后頁面訪問驗證
訪問成功。
但是由于默認情況下，eureka上的服務都會被zuul創建默認的映射關系來進行路由，使得我們不想對外開放的服務也被外部訪問到，這個時候可以通過配置zuul.ignored-services來進行配置不需要自動創建路由的規則。當zuul.ignored-services=*的時候，所有的服務都不會自動創建路由規則，這個時候需要通過前面的配置進行相關路由配置了。
================華麗的分割線===================
前面說了那么多都是圍繞一個問題展開的：路由規則和服務實例的維護問題，那么怎么解決第二個問題（校驗冗余問題）呢？
四、請求過濾
為了在api網關中實現對客戶端請求的校驗，我們可以通過過濾器來實現對請求的攔截和過濾，實現方法比較簡單，只需要繼承zuulfilter抽象類并實現其四個方法就行了。
修改api-gateway：
新增過濾器類
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
|
/** * 繼承zuulfilter，并且實現其4個接口 * * 用來進行請求過濾 * */public class accessfilter extends zuulfilter { logger logger = loggerfactory.getlogger(accessfilter.class); /* * shouldfilter 判斷該過濾器是否需要被執行 * * 這里直接返回true，表示該過濾器對所有請求都會生效。 * 實際運用中我們可以利用該函數指定過濾器的有效范圍 */ @override public boolean shouldfilter() { return true; } /* * 過濾器的具體邏輯 * * 這里我們通過ctx.setsendzuulresponse(false)讓zuul過來請求，不對其進行路由 * 然后通過ctx.setresponsestatuscode(401)設置了返回的錯誤碼 * */ @override public object run() { requestcontext context = requestcontext.getcurrentcontext(); httpservletrequest request = context.getrequest(); object accesstoken = request.getparameter("accesstoken"); logger.info("send {} request to {}", request.getmethod(),request.getrequesturl().tostring()); if(accesstoken == null) { context.setsendzuulresponse(false); context.setresponsestatuscode(401); } return null; } /* filtertype 返回過濾器類型 * 他決定了過濾器在請求的哪個生命周期中執行。這里定義為pre，代表會在請求被路由前執行。 * * pre:請求執行之前filter * route: 處理請求，進行路由 * post: 請求處理完成后執行的filter * error:出現錯誤時執行的filter */ @override public string filtertype() { return "pre"; } /* * filterorder 返回過濾器的執行順序 * * 當請求在一個階段有多個過濾器是，需要根據該方法的返回值來一次執行 * */ @override public int filterorder() { return 0; }} |
修改啟動類
|
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
|
/** * @enablezuulproxy 開啟zuul 的api網關服務功能 * */@enablezuulproxy@springcloudapplicationpublic class gatewayapp { //追加bean的是實現 @bean public accessfilter accessfilter() { return new accessfilter(); } public static void main(string[] args) { springapplication.run(gatewayapp.class, args); }} |
測試
)訪問http://localhost:5555/hello-service/hello，訪問失敗
)訪問http://localhost:5555/hello-service/hello?accesstoken=token，正常訪問
修改后的代碼結構：
五、拓展延伸
其實路由功能在真正運行時，他的路由映射和請求轉發都是由幾個不同的過濾器完成的。
路由映射主要通過pre類型的過濾器完成，他將請求路徑與配置的路由規則進行匹配，找到需要轉發的目標地址。
而請求轉發的部分則是由route類型的過濾器完成的，對pre類型過濾器獲取的路由地址進行轉發。
所以，過濾器可以說是zuul實現api網關功能最為核心的部件，每一個進入zuul的http請求都會經過一系列的過濾器處理鏈得到請求響應并返回給客戶端。
總結
以上所述是小編給大家介紹的spring cloud 使用zuul 實現api網關服務問題，希望對大家有所幫助，如果大家有任何疑問請給我留言，小編會及時回復大家的。在此也非常感謝大家對服務器之家網站的支持！
原文鏈接：https://www.cnblogs.com/sam-uncle/p/9011400.html
