SpringCloud中Zuul網(wǎng)關(guān)原理及其配置,看它就夠了!
今日推薦
作者:kosamino
cnblogs.com/jing99/p/11696192.html
正文
Zuul是spring cloud中的微服務(wù)網(wǎng)關(guān)。網(wǎng)關(guān):是一個網(wǎng)絡(luò)整體系統(tǒng)中的前置門戶入口。請求首先通過網(wǎng)關(guān),進(jìn)行路徑的路由,定位到具體的服務(wù)節(jié)點(diǎn)上。
Zuul是一個微服務(wù)網(wǎng)關(guān),首先是一個微服務(wù)。也是會在Eureka注冊中心中進(jìn)行服務(wù)的注冊和發(fā)現(xiàn)。也是一個網(wǎng)關(guān),請求應(yīng)該通過Zuul來進(jìn)行路由。
Zuul網(wǎng)關(guān)不是必要的。是推薦使用的。
使用Zuul,一般在微服務(wù)數(shù)量較多(多于10個)的時候推薦使用,對服務(wù)的管理有嚴(yán)格要求的時候推薦使用,當(dāng)微服務(wù)權(quán)限要求嚴(yán)格的時候推薦使用。
一、Zuul網(wǎng)關(guān)的作用
網(wǎng)關(guān)有以下幾個作用:
統(tǒng)一入口:未全部為服務(wù)提供一個唯一的入口,網(wǎng)關(guān)起到外部和內(nèi)部隔離的作用,保障了后臺服務(wù)的安全性。 鑒權(quán)校驗(yàn):識別每個請求的權(quán)限,拒絕不符合要求的請求。 動態(tài)路由:動態(tài)的將請求路由到不同的后端集群中。 減少客戶端與服務(wù)端的耦合:服務(wù)可以獨(dú)立發(fā)展,通過網(wǎng)關(guān)層來做映射。

二、Zuul網(wǎng)關(guān)的應(yīng)用
1、網(wǎng)關(guān)訪問方式
通過zuul訪問服務(wù)的,URL地址默認(rèn)格式為:http://zuulHostIp:port/要訪問的服務(wù)名稱/服務(wù)中的URL
服務(wù)名稱:properties配置文件中的spring.application.name。
服務(wù)的URL:就是對應(yīng)的服務(wù)對外提供的URL路徑監(jiān)聽。
2、網(wǎng)關(guān)依賴注入
<!-- spring cloud Eureka Client 啟動器 -->
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-eureka</artifactId>
</dependency>
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-zuul</artifactId>
</dependency>
<!-- zuul網(wǎng)關(guān)的重試機(jī)制,不是使用ribbon內(nèi)置的重試機(jī)制
是借助spring-retry組件實(shí)現(xiàn)的重試
開啟zuul網(wǎng)關(guān)重試機(jī)制需要增加下述依賴
-->
<dependency>
<groupId>org.springframework.retry</groupId>
<artifactId>spring-retry</artifactId>
</dependency>
3、網(wǎng)關(guān)啟動器
/**
* @EnableZuulProxy - 開啟Zuul網(wǎng)關(guān)。
* 當(dāng)前應(yīng)用是一個Zuul微服務(wù)網(wǎng)關(guān)。會在Eureka注冊中心中注冊當(dāng)前服務(wù)。并發(fā)現(xiàn)其他的服務(wù)。
* Zuul需要的必要依賴是spring-cloud-starter-zuul。
*/
@SpringBootApplication
@EnableZuulProxy
public class ZuulApplication {
public static void main(String[] args) {
SpringApplication.run(ZuulApplication.class, args);
}
}
4、網(wǎng)關(guān)全局變量配置
4.1 URL路徑匹配
# URL pattern
# 使用路徑方式匹配路由規(guī)則。
# 參數(shù)key結(jié)構(gòu):zuul.routes.customName.path=xxx
# 用于配置路徑匹配規(guī)則。
# 其中customName自定義。通常使用要調(diào)用的服務(wù)名稱,方便后期管理
# 可使用的通配符有: * ** ?
# ? 單個字符
# * 任意多個字符,不包含多級路徑
# ** 任意多個字符,包含多級路徑
zuul.routes.eureka-application-service.path=/api/**
# 參數(shù)key結(jié)構(gòu):zuul.routes.customName.url=xxx
# url用于配置符合path的請求路徑路由到的服務(wù)地址。
zuul.routes.eureka-application-service.url=http://127.0.0.1:8080/
4.2 服務(wù)名稱匹配
# service id pattern 通過服務(wù)名稱路由
# key結(jié)構(gòu) :zuul.routes.customName.path=xxx
# 路徑匹配規(guī)則
zuul.routes.eureka-application-service.path=/api/**
# key結(jié)構(gòu) :zuul.routes.customName.serviceId=xxx
# serviceId用于配置符合path的請求路徑路由到的服務(wù)名稱。
zuul.routes.eureka-application-service.serviceId=eureka-application-service
服務(wù)名稱匹配也可以使用簡化的配置:
# simple service id pattern 簡化配置方案
# 如果只配置path,不配置serviceId。則customName相當(dāng)于服務(wù)名稱。
# 符合path的請求路徑直接路由到customName對應(yīng)的服務(wù)上。
zuul.routes.eureka-application-service.path=/api/**
4.3 路由排除配置
# ignored service id pattern
# 配置不被zuul管理的服務(wù)列表。多個服務(wù)名稱使用逗號','分隔。
# 配置的服務(wù)將不被zuul代理。
zuul.ignored-services=eureka-application-service
# 此方式相當(dāng)于給所有新發(fā)現(xiàn)的服務(wù)默認(rèn)排除zuul網(wǎng)關(guān)訪問方式,只有配置了路由網(wǎng)關(guān)的服務(wù)才可以通過zuul網(wǎng)關(guān)訪問
# 通配方式配置排除列表。
zuul.ignored-services=*
# 使用服務(wù)名稱匹配規(guī)則配置路由列表,相當(dāng)于只對已配置的服務(wù)提供網(wǎng)關(guān)代理。
zuul.routes.eureka-application-service.path=/api/**
# 通配方式配置排除網(wǎng)關(guān)代理路徑。所有符合ignored-patterns的請求路徑都不被zuul網(wǎng)關(guān)代理。
zuul.ignored-patterns=/**/test/**
zuul.routes.eureka-application-service.path=/api/**
4.4 路由前綴配置
# prefix URL pattern 前綴路由匹配
# 配置請求路徑前綴,所有基于此前綴的請求都由zuul網(wǎng)關(guān)提供代理。
zuul.prefix=/api
# 使用服務(wù)名稱匹配方式配置請求路徑規(guī)則。
# 這里的配置將為:http://ip:port/api/appservice/**的請求提供zuul網(wǎng)關(guān)代理,可以將要訪問服務(wù)進(jìn)行前綴分類。
# 并將請求路由到服務(wù)eureka-application-service中。
zuul.routes.eureka-application-service.path=/appservice/**
5 Zuul網(wǎng)關(guān)配置總結(jié)
網(wǎng)關(guān)配置方式有多種,默認(rèn)、URL、服務(wù)名稱、排除|忽略、前綴。
網(wǎng)關(guān)配置沒有優(yōu)劣好壞,應(yīng)該在不同的情況下選擇合適的配置方案。擴(kuò)展:大公司為什么都有API網(wǎng)關(guān)?聊聊API網(wǎng)關(guān)的作用
zuul網(wǎng)關(guān)其底層使用ribbon來實(shí)現(xiàn)請求的路由,并內(nèi)置Hystrix,可選擇性提供網(wǎng)關(guān)fallback邏輯。使用zuul的時候,并不推薦使用Feign作為application client端的開發(fā)實(shí)現(xiàn)。畢竟Feign技術(shù)是對ribbon的再封裝,使用Feign本身會提高通訊消耗,降低通訊效率,只在服務(wù)相互調(diào)用的時候使用Feign來簡化代碼開發(fā)就夠了。而且商業(yè)開發(fā)中,使用Ribbon+RestTemplate來開發(fā)的比例更高。
三、Zuul網(wǎng)關(guān)過濾器
Zuul中提供了過濾器定義,可以用來過濾代理請求,提供額外功能邏輯。如:權(quán)限驗(yàn)證,日志記錄等。
Zuul提供的過濾器是一個父類。父類是ZuulFilter。通過父類中定義的抽象方法filterType,來決定當(dāng)前的Filter種類是什么。有前置過濾、路由后過濾、后置過濾、異常過濾。
前置過濾:是請求進(jìn)入Zuul之后,立刻執(zhí)行的過濾邏輯。 路由后過濾:是請求進(jìn)入Zuul之后,并Zuul實(shí)現(xiàn)了請求路由后執(zhí)行的過濾邏輯,路由后過濾,是在遠(yuǎn)程服務(wù)調(diào)用之前過濾的邏輯。 后置過濾:遠(yuǎn)程服務(wù)調(diào)用結(jié)束后執(zhí)行的過濾邏輯。 異常過濾:是任意一個過濾器發(fā)生異常或遠(yuǎn)程服務(wù)調(diào)用無結(jié)果反饋的時候執(zhí)行的過濾邏輯。無結(jié)果反饋,就是遠(yuǎn)程服務(wù)調(diào)用超時。
3.1 過濾器實(shí)現(xiàn)方式
繼承父類ZuulFilter。在父類中提供了4個抽象方法,分別是:filterType, filterOrder, shouldFilter, run。其功能分別是:
filterType:方法返回字符串?dāng)?shù)據(jù),代表當(dāng)前過濾器的類型。可選值有-pre, route, post, error。
pre - 前置過濾器,在請求被路由前執(zhí)行,通常用于處理身份認(rèn)證,日志記錄等; route - 在路由執(zhí)行后,服務(wù)調(diào)用前被調(diào)用; error - 任意一個filter發(fā)生異常的時候執(zhí)行或遠(yuǎn)程服務(wù)調(diào)用沒有反饋的時候執(zhí)行(超時),通常用于處理異常; post - 在route或error執(zhí)行后被調(diào)用,一般用于收集服務(wù)信息,統(tǒng)計服務(wù)性能指標(biāo)等,也可以對response結(jié)果做特殊處理。
filterOrder:返回int數(shù)據(jù),用于為同filterType的多個過濾器定制執(zhí)行順序,返回值越小,執(zhí)行順序越優(yōu)先。
shouldFilter:返回boolean數(shù)據(jù),代表當(dāng)前filter是否生效。
run:具體的過濾執(zhí)行邏輯。如pre類型的過濾器,可以通過對請求的驗(yàn)證來決定是否將請求路由到服務(wù)上;如post類型的過濾器,可以對服務(wù)響應(yīng)結(jié)果做加工處理(如為每個響應(yīng)增加footer數(shù)據(jù))。
3.2 過濾器的生命周期

3.3 代碼示例
/**
* Zuul過濾器,必須繼承ZuulFilter父類。
* 當(dāng)前類型的對象必須交由Spring容器管理。使用@Component注解描述。
* 繼承父類后,必須實(shí)現(xiàn)父類中定義的4個抽象方法。
* shouldFilter、 run、 filterType、 filterOrder
*/
@Component
public class LoggerFilter extends ZuulFilter {
private static final Logger logger = LoggerFactory.getLogger(LoggerFilter.class);
/**
* 返回boolean類型。代表當(dāng)前filter是否生效。
* 默認(rèn)值為false。
* 返回true代表開啟filter。
*/
@Override
public boolean shouldFilter() {
return true;
}
/**
* run方法就是過濾器的具體邏輯。
* return 可以返回任意的對象,當(dāng)前實(shí)現(xiàn)忽略。(spring-cloud-zuul官方解釋)
* 直接返回null即可。
*/
@Override
public Object run() throws ZuulException {
// 通過zuul,獲取請求上下文
RequestContext rc = RequestContext.getCurrentContext();
HttpServletRequest request = rc.getRequest();
logger.info("LogFilter1.....method={},url={}",
request.getMethod(),request.getRequestURL().toString());
// 可以記錄日志、鑒權(quán),給維護(hù)人員記錄提供定位協(xié)助、統(tǒng)計性能
return null;
}
/**
* 過濾器的類型。可選值有:
* pre - 前置過濾
* route - 路由后過濾
* error - 異常過濾
* post - 遠(yuǎn)程服務(wù)調(diào)用后過濾
*/
@Override
public String filterType() {
return "pre";
}
/**
* 同種類的過濾器的執(zhí)行順序。
* 按照返回值的自然升序執(zhí)行。
*/
@Override
public int filterOrder() {
return 0;
}
}
四、Zuul網(wǎng)關(guān)的容錯(與Hystrix的無縫結(jié)合)
在spring cloud中,Zuul啟動器中包含了Hystrix相關(guān)依賴,在Zuul網(wǎng)關(guān)工程中,默認(rèn)是提供了Hystrix Dashboard服務(wù)監(jiān)控數(shù)據(jù)的(hystrix.stream),但是不會提供監(jiān)控面板的界面展示。可以說,在spring cloud中,zuul和Hystrix是無縫結(jié)合的。
4.1 Zuul中的服務(wù)降級處理
在Edgware版本之前,Zuul提供了接口ZuulFallbackProvider用于實(shí)現(xiàn)fallback處理。從Edgware版本開始,Zuul提供了ZuulFallbackProvider的子接口FallbackProvider來提供fallback處理。
Zuul的fallback容錯處理邏輯,只針對timeout異常處理,當(dāng)請求被Zuul路由后,只要服務(wù)有返回(包括異常),都不會觸發(fā)Zuul的fallback容錯邏輯。
因?yàn)閷τ赯uul網(wǎng)關(guān)來說,做請求路由分發(fā)的時候,結(jié)果由遠(yuǎn)程服務(wù)運(yùn)算的。那么遠(yuǎn)程服務(wù)反饋了異常信息,Zuul網(wǎng)關(guān)不會處理異常,因?yàn)闊o法確定這個錯誤是否是應(yīng)用真實(shí)想要反饋給客戶端的。
4.2 代碼示例
/**
* 如果需要在Zuul網(wǎng)關(guān)服務(wù)中增加容錯處理fallback,需要實(shí)現(xiàn)接口ZuulFallbackProvider
* spring-cloud框架,在Edgware版本(包括)之后,聲明接口ZuulFallbackProvider過期失效,
* 提供了新的ZuulFallbackProvider的子接口 - FallbackProvider
* 在老版本中提供的ZuulFallbackProvider中,定義了兩個方法。
* - String getRoute()
* 當(dāng)前的fallback容錯處理邏輯處理的是哪一個服務(wù)。可以使用通配符‘*’代表為全部的服務(wù)提供容錯處理。
* 如果只為某一個服務(wù)提供容錯,返回對應(yīng)服務(wù)的spring.application.name值。
* - ClientHttpResponse fallbackResponse()
* 當(dāng)服務(wù)發(fā)生錯誤的時候,如何容錯。
* 新版本中提供的FallbackProvider提供了新的方法。
* - ClientHttpResponse fallbackResponse(Throwable cause)
* 如果使用新版本中定義的接口來做容錯處理,容錯處理邏輯,只運(yùn)行子接口中定義的新方法。也就是有參方法。
* 是為遠(yuǎn)程服務(wù)發(fā)生異常的時候,通過異常的類型來運(yùn)行不同的容錯邏輯。
*/
@Component
public class TestFallBbackProvider implements FallbackProvider {
/**
* return - 返回fallback處理哪一個服務(wù)。返回的是服務(wù)的名稱
* 推薦 - 為指定的服務(wù)定義特性化的fallback邏輯。
* 推薦 - 提供一個處理所有服務(wù)的fallback邏輯。
* 好處 - 服務(wù)某個服務(wù)發(fā)生超時,那么指定的fallback邏輯執(zhí)行。如果有新服務(wù)上線,未提供fallback邏輯,有一個通用的。
*/
@Override
public String getRoute() {
return "eureka-application-service";
}
/**
* fallback邏輯。在早期版本中使用。
* Edgware版本之后,ZuulFallbackProvider接口過期,提供了新的子接口FallbackProvider
* 子接口中提供了方法ClientHttpResponse fallbackResponse(Throwable cause)。
* 優(yōu)先調(diào)用子接口新定義的fallback處理邏輯。
*/
@Override
public ClientHttpResponse fallbackResponse() {
System.out.println("ClientHttpResponse fallbackResponse()");
List<Map<String, Object>> result = new ArrayList<>();
Map<String, Object> data = new HashMap<>();
data.put("message", "服務(wù)正忙,請稍后重試");
result.add(data);
ObjectMapper mapper = new ObjectMapper();
String msg = "";
try {
msg = mapper.writeValueAsString(result);
} catch (JsonProcessingException e) {
msg = "";
}
return this.executeFallback(HttpStatus.OK, msg,
"application", "json", "utf-8");
}
/**
* fallback邏輯。優(yōu)先調(diào)用。可以根據(jù)異常類型動態(tài)決定處理方式。
*/
@Override
public ClientHttpResponse fallbackResponse(Throwable cause) {
System.out.println("ClientHttpResponse fallbackResponse(Throwable cause)");
if(cause instanceof NullPointerException){
List<Map<String, Object>> result = new ArrayList<>();
Map<String, Object> data = new HashMap<>();
data.put("message", "網(wǎng)關(guān)超時,請稍后重試");
result.add(data);
ObjectMapper mapper = new ObjectMapper();
String msg = "";
try {
msg = mapper.writeValueAsString(result);
} catch (JsonProcessingException e) {
msg = "";
}
return this.executeFallback(HttpStatus.GATEWAY_TIMEOUT,
msg, "application", "json", "utf-8");
}else{
return this.fallbackResponse();
}
}
/**
* 具體處理過程。
* @param status 容錯處理后的返回狀態(tài),如200正常GET請求結(jié)果,201正常POST請求結(jié)果,404資源找不到錯誤等。
* 使用spring提供的枚舉類型對象實(shí)現(xiàn)。HttpStatus
* @param contentMsg 自定義的響應(yīng)內(nèi)容。就是反饋給客戶端的數(shù)據(jù)。
* @param mediaType 響應(yīng)類型,是響應(yīng)的主類型, 如:application、text、media。
* @param subMediaType 響應(yīng)類型,是響應(yīng)的子類型, 如:json、stream、html、plain、jpeg、png等。
* @param charsetName 響應(yīng)結(jié)果的字符集。這里只傳遞字符集名稱,如:utf-8、gbk、big5等。
* @return ClientHttpResponse 就是響應(yīng)的具體內(nèi)容。
* 相當(dāng)于一個HttpServletResponse。
*/
private final ClientHttpResponse executeFallback(final HttpStatus status,
String contentMsg, String mediaType, String subMediaType, String charsetName) {
return new ClientHttpResponse() {
/**
* 設(shè)置響應(yīng)的頭信息
*/
@Override
public HttpHeaders getHeaders() {
HttpHeaders header = new HttpHeaders();
MediaType mt = new MediaType(mediaType, subMediaType, Charset.forName(charsetName));
header.setContentType(mt);
return header;
}
/**
* 設(shè)置響應(yīng)體
* zuul會將本方法返回的輸入流數(shù)據(jù)讀取,并通過HttpServletResponse的輸出流輸出到客戶端。
*/
@Override
public InputStream getBody() throws IOException {
String content = contentMsg;
return new ByteArrayInputStream(content.getBytes());
}
/**
* ClientHttpResponse的fallback的狀態(tài)碼 返回String
*/
@Override
public String getStatusText() throws IOException {
return this.getStatusCode().getReasonPhrase();
}
/**
* ClientHttpResponse的fallback的狀態(tài)碼 返回HttpStatus
*/
@Override
public HttpStatus getStatusCode() throws IOException {
return status;
}
/**
* ClientHttpResponse的fallback的狀態(tài)碼 返回int
*/
@Override
public int getRawStatusCode() throws IOException {
return this.getStatusCode().value();
}
/**
* 回收資源方法
* 用于回收當(dāng)前fallback邏輯開啟的資源對象的。
* 不要關(guān)閉getBody方法返回的那個輸入流對象。
*/
@Override
public void close() {
}
};
}
}
五、Zuul網(wǎng)關(guān)的限流保護(hù)
Zuul網(wǎng)關(guān)組件也提供了限流保護(hù)。當(dāng)請求并發(fā)達(dá)到閥值,自動觸發(fā)限流保護(hù),返回錯誤結(jié)果。只要提供error錯誤處理機(jī)制即可。
Zuul的限流保護(hù)需要額外依賴spring-cloud-zuul-ratelimit組件。
<dependency>
<groupId>com.marcosbarbero.cloud</groupId>
<artifactId>spring-cloud-zuul-ratelimit</artifactId>
<version>1.3.4.RELEASE</version>
</dependency>
5.1 全局限流配置
使用全局限流配置,zuul會對代理的所有服務(wù)提供限流保護(hù)。
# 開啟限流保護(hù)
zuul.ratelimit.enabled=true
# 60s內(nèi)請求超過3次,服務(wù)端就拋出異常,60s后可以恢復(fù)正常請求
zuul.ratelimit.default-policy.limit=3
zuul.ratelimit.default-policy.refresh-interval=60
# 針對IP進(jìn)行限流,不影響其他IP
zuul.ratelimit.default-policy.type=origin
5.2 局部限流配置
使用局部限流配置,zuul僅針對配置的服務(wù)提供限流保護(hù)。
# 開啟限流保護(hù)
zuul.ratelimit.enabled=true
# hystrix-application-client服務(wù)60s內(nèi)請求超過3次,服務(wù)拋出異常。
zuul.ratelimit.policies.hystrix-application-client.limit=3
zuul.ratelimit.policies.hystrix-application-client.refresh-interval=60
# 針對IP限流。
zuul.ratelimit.policies.hystrix-application-client.type=origin
5.3 限流參數(shù)簡介

六、Zuul網(wǎng)關(guān)性能調(diào)優(yōu):網(wǎng)關(guān)的兩層超時調(diào)優(yōu)
使用Zuul的spring cloud微服務(wù)結(jié)構(gòu)圖:

從上圖中可以看出。整體請求邏輯還是比較復(fù)雜的,在沒有zuul網(wǎng)關(guān)的情況下,app client請求app service的時候,也有請求超時的可能。那么當(dāng)增加了zuul網(wǎng)關(guān)的時候,請求超時的可能就更明顯了。
當(dāng)請求通過zuul網(wǎng)關(guān)路由到服務(wù),并等待服務(wù)返回響應(yīng),這個過程中zuul也有超時控制。zuul的底層使用的是Hystrix+ribbon來實(shí)現(xiàn)請求路由。結(jié)構(gòu)如下:

zuul中的Hystrix內(nèi)部使用線程池隔離機(jī)制提供請求路由實(shí)現(xiàn),其默認(rèn)的超時時長為1000毫秒。ribbon底層默認(rèn)超時時長為5000毫秒。如果Hystrix超時,直接返回超時異常。如果ribbon超時,同時Hystrix未超時,ribbon會自動進(jìn)行服務(wù)集群輪詢重試,直到Hystrix超時為止。如果Hystrix超時時長小于ribbon超時時長,ribbon不會進(jìn)行服務(wù)集群輪詢重試。
那么在zuul中可配置的超時時長就有兩個位置:Hystrix和ribbon。具體配置如下:
# 開啟zuul網(wǎng)關(guān)重試
zuul.retryable=true
# hystrix超時時間設(shè)置
# 線程池隔離,默認(rèn)超時時間1000ms
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=8000
# ribbon超時時間設(shè)置:建議設(shè)置比Hystrix小
# 請求連接的超時時間: 默認(rèn)5000ms
ribbon.ConnectTimeout=5000
# 請求處理的超時時間: 默認(rèn)5000ms
ribbon.ReadTimeout=5000
# 重試次數(shù):MaxAutoRetries表示訪問服務(wù)集群下原節(jié)點(diǎn)(同路徑訪問);MaxAutoRetriesNextServer表示訪問服務(wù)集群下其余節(jié)點(diǎn)(換臺服務(wù)器)
ribbon.MaxAutoRetries=1
ribbon.MaxAutoRetriesNextServer=1
# 開啟重試
ribbon.OkToRetryOnAllOperations=true
Spring-cloud中的zuul網(wǎng)關(guān)重試機(jī)制是使用spring-retry實(shí)現(xiàn)的。工程必須依賴下述資源:
<dependency>
<groupId>org.springframework.retry</groupId>
<artifactId>spring-retry</artifactId>
</dependency>推薦文章
更多項目源碼
