spring-cloud應用網關之zuul
前言
應用網關這個組件，想必大家應該都不陌生，特別是在當下微服務盛行的互聯(lián)網時代，應用網關有著非常重要的作用，也是微服務必不可少的組件之一。
通常我們將應用網關放在企業(yè)應用的最外層，作為企業(yè)應用的第一道大門，所有服務都經過應用網關來訪問，這樣做有很多好處，比如更安全，所有應用只對外暴漏應用網關的服務映射地址，隱藏服務實際地址、部署節(jié)點等信息，確保服務系統(tǒng)安全性；更易于擴展，通過應用網關，我們可以把集成很多其他功能，比如權限中心、用戶中心、服務負載中心等服務，這樣其他服務只需要接入應用網關即可使用相關公共服務提供的服務，而不用單獨集成。好了，關于應用網關我們暫時就說這么多，下面我們看下zuul網關的簡單應用。
ZUUL
創(chuàng)建項目
首先，我們要先創(chuàng)建一個spring boot項目。然后引入zuul和eureka的相關依賴。
核心依賴
下面就是zuul的核心依賴，必須引入。
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-zuul</artifactId>
<version>2.2.9.RELEASE</version>
</dependency>
引入zuul的依賴后，我發(fā)現(xiàn)zuul還依賴了ribbon、feign、hystrix等組件，說明zuul本身也為我們提供負載均衡的相關實現(xiàn)，關于這一點，后面我們會展示。
eureka依賴
引入eureka的客戶端依賴是因為zuul應用網關的核心實現(xiàn)其實是基于eureka實現(xiàn)的，沒有eureka的支持，zuul本身是無法發(fā)現(xiàn)服務具體地址的，關于這一點，有興趣的小伙伴可以親測下。
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
<version>2.2.9.RELEASE</version>
</dependency>
基本配置
我們只需要在項目主類加上@EnableZuulProxy即可啟用zuul應用網關
@SpringBootApplication
@EnableZuulProxy
public class SpirngCloudZuulDemoApplication {
public static void main(String[] args) {
SpringApplication.run(SpirngCloudZuulDemoApplication.class, args);
}
}
同時，點開@EnableZuulProxy注解，我們會發(fā)現(xiàn)，其實它默認為我們集成并啟用了熔斷器，當然從最前面的依賴也可以看出這一點。
關于啟用Hystrix斷路器，從業(yè)務上也很好理解，應用網關作為對外提供服務的窗口，在前后端交互方面是絕對的挑大梁角色，如果因為某個服務長時間未響應，導致請求阻塞，最后導致網關宕機，這種情景是不敢想象的，網關一掛，意味著企業(yè)服務都涼涼了，所以集成斷路器就很有必要了。
這里就是應用網關的配置文件了，配置內容也很簡單，一個是指定端口，一個是設定eureka注冊中心的地址。用80端口的好處，就是可以省掉端口，就很方便了
server.port=80
eureka.client.service-url.defaultZone=http://localhost:8999/eureka/
訪問測試
下面我們來進行一些簡單的測試，首先啟動我們的注冊中心，為了方便測試，這里我們就啟動一個注冊中心，同時我們啟動應用網關服務spring-cloud-zuul和產品服務product-service。
在產品服務中，我們有一個簡單的controller接口，這個接口就是上次我們測試feign負載均衡組件的時候用的，這里就直接用了。
下面我們通過應用網關訪問下我們的產品服務，地址如下：
http://localhost/product-service/feign
這里解釋下我們上面的地址，localhost是應用網關的服務地址，product-service是我們要訪問的服務id，這個id是我們eureka中注冊的服務id，也就是我們服務中配置的spring.application.name的值，/feign就是我們接口的地址了。這里再啰嗦一下，通過zuul網關訪問的服務，必須在eureka中心注冊，否則無法發(fā)現(xiàn)服務。
下面就是我們訪問結果：
和我們直接訪問服務實際地址返回的結果也是一致的：
同時在后端控制臺，我們會發(fā)現(xiàn)zuul的負載均衡默認是通過ribbon實現(xiàn)的：
內容擴展
服務配置
下面是zuul應用網關的一些特殊配置：
# 微服務映射規(guī)則
# 配置訪問規(guī)則
zuul.routes.product-service.path=/p/**
# 配置服務地址
#zuul.routes.product-service.url=http://baidu.com/
zuul.routes.product-service.url=http://localhost:9001/
# 指定服務id
zuul.routes.product-service.service-id=product-service
上面這些配置是一些特殊的訪問規(guī)則，下面簡單解釋下：
第一行配置是設定product-service的訪問規(guī)則，也就是說只要我們的訪問地址符合/p/**的匹配規(guī)則，也就是說我們可以通過/p來訪問我們的服務，而不必再指定serviceId；
第二行配置設置的是product-service的服務地址；
第三行配置設定的是服務的service-id；
只是上面這種配置式的訪問規(guī)則，并不會觸發(fā)負載均衡，只是單純的請求轉發(fā)。關于這一點，各位小伙伴可以訪問同一個服務試下，配置式的訪問規(guī)則，服務訪問的時候只會訪問我們設定的url，而通過serviceId的方式訪問，則會默認走負載均衡：
總結
好了，zuul應用網關的相關知識點暫時就先分享到這里，我們目前就先分享一些簡單的應用，后期有機會的話，我們再進一步挖掘。
最近一段時間，分享知識節(jié)奏有點快
，到今天差不多一周的時間，我們已經分享了eureka、feign、fibbon、hystrix、zuul等組件，雖然節(jié)奏快，但是內容方面我覺得應該算是盡可能詳實了吧，當然很多內容的深度可能還不夠，但是現(xiàn)階段我們的目標只是了解和應用這些常用組件，至于各個組件的實現(xiàn)原理和高級用法，那是我的下階段目標，所以暫時就先這樣。
項目源碼還是在老地方獲取，不清楚的小伙伴可以留言！