SpringCloud中Zuul網(wǎng)關(guān)原理及其配置，看它就夠了！

Zuul是spring cloud中的微服務(wù)網(wǎng)關(guān)。網(wǎng)關(guān)：是一個網(wǎng)絡(luò)整體系統(tǒng)中的前置門戶入口。請求首先通過網(wǎng)關(guān)，進行路徑的路由，定位到具體的服務(wù)節(jié)點上。

Zuul是一個微服務(wù)網(wǎng)關(guān)，首先是一個微服務(wù)。也是會在Eureka注冊中心中進行服務(wù)的注冊和發(fā)現(xiàn)。也是一個網(wǎng)關(guān)，請求應(yīng)該通過Zuul來進行路由。

Zuul網(wǎng)關(guān)不是必要的。是推薦使用的。

使用Zuul，一般在微服務(wù)數(shù)量較多（多于10個）的時候推薦使用，對服務(wù)的管理有嚴格要求的時候推薦使用，當(dāng)微服務(wù)權(quán)限要求嚴格的時候推薦使用。

一、Zuul網(wǎng)關(guān)的作用

網(wǎng)關(guān)有以下幾個作用：

• 統(tǒng)一入口：未全部為服務(wù)提供一個唯一的入口，網(wǎng)關(guān)起到外部和內(nèi)部隔離的作用，保障了后臺服務(wù)的安全性。
• 鑒權(quán)校驗：識別每個請求的權(quán)限，拒絕不符合要求的請求。
• 動態(tài)路由：動態(tài)的將請求路由到不同的后端集群中。
• 減少客戶端與服務(wù)端的耦合：服務(wù)可以獨立發(fā)展，通過網(wǎng)關(guān)層來做映射。

二、Zuul網(wǎng)關(guān)的應(yīng)用

1、網(wǎng)關(guān)訪問方式

通過zuul訪問服務(wù)的，URL地址默認格式為：http://zuulHostIp:port/要訪問的服務(wù)名稱/服務(wù)中的URL

服務(wù)名稱：properties配置文件中的spring.application.name。

服務(wù)的URL：就是對應(yīng)的服務(wù)對外提供的URL路徑監(jiān)聽。

2、網(wǎng)關(guān)依賴注入

<dependency>
????<groupId>org.springframework.cloudgroupId>
????<artifactId>spring-cloud-starter-eurekaartifactId>
dependency>
<dependency>
????<groupId>org.springframework.cloudgroupId>
????<artifactId>spring-cloud-starter-zuulartifactId>
dependency>

<dependency>
???<groupId>org.springframework.retrygroupId>
???<artifactId>spring-retryartifactId>
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ù)默認排除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ù)進行前綴分類。
#?并將請求路由到服務(wù)eureka-application-service中。
zuul.routes.eureka-application-service.path=/appservice/**

5 Zuul網(wǎng)關(guān)配置總結(jié)

網(wǎng)關(guān)配置方式有多種，默認、URL、服務(wù)名稱、排除|忽略、前綴。

網(wǎng)關(guān)配置沒有優(yōu)劣好壞，應(yīng)該在不同的情況下選擇合適的配置方案。擴展：大公司為什么都有API網(wǎng)關(guān)？聊聊API網(wǎng)關(guān)的作用

zuul網(wǎng)關(guān)其底層使用ribbon來實現(xiàn)請求的路由，并內(nèi)置Hystrix，可選擇性提供網(wǎng)關(guān)fallback邏輯。使用zuul的時候，并不推薦使用Feign作為application client端的開發(fā)實現(xiàn)。畢竟Feign技術(shù)是對ribbon的再封裝，使用Feign本身會提高通訊消耗，降低通訊效率，只在服務(wù)相互調(diào)用的時候使用Feign來簡化代碼開發(fā)就夠了。而且商業(yè)開發(fā)中，使用Ribbon+RestTemplate來開發(fā)的比例更高。

三、Zuul網(wǎng)關(guān)過濾器

Zuul中提供了過濾器定義，可以用來過濾代理請求，提供額外功能邏輯。如：權(quán)限驗證，日志記錄等。

Zuul提供的過濾器是一個父類。父類是ZuulFilter。通過父類中定義的抽象方法filterType，來決定當(dāng)前的Filter種類是什么。有前置過濾、路由后過濾、后置過濾、異常過濾。

• 前置過濾：是請求進入Zuul之后，立刻執(zhí)行的過濾邏輯。
• 路由后過濾：是請求進入Zuul之后，并Zuul實現(xiàn)了請求路由后執(zhí)行的過濾邏輯，路由后過濾，是在遠程服務(wù)調(diào)用之前過濾的邏輯。
• 后置過濾：遠程服務(wù)調(diào)用結(jié)束后執(zhí)行的過濾邏輯。
• 異常過濾：是任意一個過濾器發(fā)生異常或遠程服務(wù)調(diào)用無結(jié)果反饋的時候執(zhí)行的過濾邏輯。無結(jié)果反饋，就是遠程服務(wù)調(diào)用超時。

3.1 過濾器實現(xiàn)方式

繼承父類ZuulFilter。在父類中提供了4個抽象方法，分別是：filterType, filterOrder, shouldFilter, run。其功能分別是：

filterType：方法返回字符串?dāng)?shù)據(jù)，代表當(dāng)前過濾器的類型。可選值有-pre, route, post, error。

• pre - 前置過濾器，在請求被路由前執(zhí)行，通常用于處理身份認證，日志記錄等；
• route - 在路由執(zhí)行后，服務(wù)調(diào)用前被調(diào)用；
• error - 任意一個filter發(fā)生異常的時候執(zhí)行或遠程服務(wù)調(diào)用沒有反饋的時候執(zhí)行（超時），通常用于處理異常；
• post - 在route或error執(zhí)行后被調(diào)用，一般用于收集服務(wù)信息，統(tǒng)計服務(wù)性能指標等，也可以對response結(jié)果做特殊處理。

filterOrder：返回int數(shù)據(jù)，用于為同filterType的多個過濾器定制執(zhí)行順序，返回值越小，執(zhí)行順序越優(yōu)先。

shouldFilter：返回boolean數(shù)據(jù)，代表當(dāng)前filter是否生效。

run：具體的過濾執(zhí)行邏輯。如pre類型的過濾器，可以通過對請求的驗證來決定是否將請求路由到服務(wù)上；如post類型的過濾器，可以對服務(wù)響應(yīng)結(jié)果做加工處理（如為每個響應(yīng)增加footer數(shù)據(jù)）。

3.2 過濾器的生命周期

3.3 代碼示例

/**
?* Zuul過濾器，必須繼承ZuulFilter父類。
?*?當(dāng)前類型的對象必須交由Spring容器管理。使用@Component注解描述。
?*?繼承父類后，必須實現(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是否生效。
?????*?默認值為false。
?????*?返回true代表開啟filter。
?????*/
????@Override
????public?boolean?shouldFilter()?{
????????return?true;
????}

????/**
?????* run方法就是過濾器的具體邏輯。
?????* return 可以返回任意的對象，當(dāng)前實現(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)，給維護人員記錄提供定位協(xié)助、統(tǒng)計性能
????????return?null;
????}

????/**
?????*?過濾器的類型。可選值有：
?????*?pre?-?前置過濾
?????*?route?-?路由后過濾
?????*?error?-?異常過濾
?????*?post?-?遠程服務(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)工程中，默認是提供了Hystrix Dashboard服務(wù)監(jiān)控數(shù)據(jù)的(hystrix.stream)，但是不會提供監(jiān)控面板的界面展示。可以說，在spring cloud中，zuul和Hystrix是無縫結(jié)合的。

4.1 Zuul中的服務(wù)降級處理

在Edgware版本之前，Zuul提供了接口ZuulFallbackProvider用于實現(xiàn)fallback處理。從Edgware版本開始，Zuul提供了ZuulFallbackProvider的子接口FallbackProvider來提供fallback處理。

Zuul的fallback容錯處理邏輯，只針對timeout異常處理，當(dāng)請求被Zuul路由后，只要服務(wù)有返回（包括異常），都不會觸發(fā)Zuul的fallback容錯邏輯。

因為對于Zuul網(wǎng)關(guān)來說，做請求路由分發(fā)的時候，結(jié)果由遠程服務(wù)運算的。那么遠程服務(wù)反饋了異常信息，Zuul網(wǎng)關(guān)不會處理異常，因為無法確定這個錯誤是否是應(yīng)用真實想要反饋給客戶端的。

4.2 代碼示例

/**
?*?如果需要在Zuul網(wǎng)關(guān)服務(wù)中增加容錯處理fallback，需要實現(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)
?*????如果使用新版本中定義的接口來做容錯處理，容錯處理邏輯，只運行子接口中定義的新方法。也就是有參方法。
?*????是為遠程服務(wù)發(fā)生異常的時候，通過異常的類型來運行不同的容錯邏輯。
?*/
@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>?result?=?new?ArrayList<>();
????????Map?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>?result?=?new?ArrayList<>();
????????????Map?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提供的枚舉類型對象實現(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)的限流保護

Zuul網(wǎng)關(guān)組件也提供了限流保護。當(dāng)請求并發(fā)達到閥值，自動觸發(fā)限流保護，返回錯誤結(jié)果。只要提供error錯誤處理機制即可。

Zuul的限流保護需要額外依賴spring-cloud-zuul-ratelimit組件。

<dependency>
????<groupId>com.marcosbarbero.cloudgroupId>
????<artifactId>spring-cloud-zuul-ratelimitartifactId>
????<version>1.3.4.RELEASEversion>
dependency>

5.1 全局限流配置

使用全局限流配置，zuul會對代理的所有服務(wù)提供限流保護。

#?開啟限流保護
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進行限流，不影響其他IP
zuul.ratelimit.default-policy.type=origin

5.2 局部限流配置

使用局部限流配置，zuul僅針對配置的服務(wù)提供限流保護。

#?開啟限流保護
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來實現(xiàn)請求路由。結(jié)構(gòu)如下：

zuul中的Hystrix內(nèi)部使用線程池隔離機制提供請求路由實現(xiàn)，其默認的超時時長為1000毫秒。ribbon底層默認超時時長為5000毫秒。如果Hystrix超時，直接返回超時異常。如果ribbon超時，同時Hystrix未超時，ribbon會自動進行服務(wù)集群輪詢重試，直到Hystrix超時為止。如果Hystrix超時時長小于ribbon超時時長，ribbon不會進行服務(wù)集群輪詢重試。

那么在zuul中可配置的超時時長就有兩個位置：Hystrix和ribbon。具體配置如下：

#?開啟zuul網(wǎng)關(guān)重試
zuul.retryable=true
#?hystrix超時時間設(shè)置
#?線程池隔離，默認超時時間1000ms
hystrix.command.default.execution.isolation.thread.timeoutInMilliseconds=8000

# ribbon超時時間設(shè)置：建議設(shè)置比Hystrix小
#?請求連接的超時時間:?默認5000ms
ribbon.ConnectTimeout=5000
#?請求處理的超時時間:?默認5000ms
ribbon.ReadTimeout=5000
#?重試次數(shù)：MaxAutoRetries表示訪問服務(wù)集群下原節(jié)點（同路徑訪問）；MaxAutoRetriesNextServer表示訪問服務(wù)集群下其余節(jié)點（換臺服務(wù)器）
ribbon.MaxAutoRetries=1
ribbon.MaxAutoRetriesNextServer=1
#?開啟重試
ribbon.OkToRetryOnAllOperations=true

Spring-cloud中的zuul網(wǎng)關(guān)重試機制是使用spring-retry實現(xiàn)的。工程必須依賴下述資源：

<dependency>
??<groupId>org.springframework.retrygroupId>
??<artifactId>spring-retryartifactId>
dependency>