SpringCloud Gateway加載斷言predicates與過濾器filters的源碼分析
我們今天的主角是Gateway網關，一聽名字就知道它基本的任務就是去分發路由。根據不同的指定名稱去請求各個服務，下面是Gateway官方的解釋：
https://spring.io/projects/spring-cloud-gateway，其他的博主就不多說瞭，大傢多去官網看看，隻有官方的才是最正確的，回歸主題，我們的過濾器與斷言如何加載進來的，並且是如何進行對請求進行過濾的。
大傢如果對SpringBoot自動加載的熟悉的話，一定知道要看一個代碼的源碼，要找到META-INF下的spring.factories，具體為啥的博主就不多說瞭，網上也有很多講解自動加載的源碼分析，今天就講解Gateway，所有項目三板斧：加依賴、寫註解、弄配置
依賴：
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-gateway</artifactId>
</dependency>
註解：啟動類上需要添加@EnableDiscoveryClient，啟動服務發現
配置：
spring:
cloud:
gateway:
routes:
- id: after-route #id必須要唯一
uri: lb://product-center
predicates:
- After=2030-12-16T15:53:22.999+08:00[Asia/Shanghai]
filters:
- PrefixPath=/product-api
大傢看到這個配置的時候，為什麼我們寫After斷言與PrefixPath過濾器，gateway就會自動識別呢，那我們有沒有那一個地方可以看到所有的自帶的屬性呢？當然有，而且我們本篇就主要講解為什麼gateway會自動識別，並且我們要自己實現並且添加自定義屬性。開始源碼解析第一步，找到自動加載的類一探究竟；
看到這裡的時候，第一步就成功瞭，剩下的就是找到org.springframework.cloud.gateway.config.GatewayAutoConfiguration這個關鍵類，我們主要看看裡面的兩個類
@Bean
public RouteLocator routeDefinitionRouteLocator(GatewayProperties properties,
List<GatewayFilterFactory> GatewayFilters,
List<RoutePredicateFactory> predicates,
RouteDefinitionLocator routeDefinitionLocator) {
return new RouteDefinitionRouteLocator(routeDefinitionLocator, predicates, GatewayFilters, properties);
}
@Bean
@Primary
//TODO: property to disable composite?
public RouteLocator cachedCompositeRouteLocator(List<RouteLocator> routeLocators) {
return new CachingRouteLocator(new CompositeRouteLocator(Flux.fromIterable(routeLocators)));
}
這倆個類配置，大傢可能非常熟悉，大傢上手一個新知識點的時候，肯定會找一些快速入門的文章看看，博主還是習慣直接找官方的quick start來看，大傢可以看看這些快速上手項目：https://spring.io/guides/gs/gateway/
所以博主直接就找到瞭RouteLocator這個類配置，果不其然，我們找到瞭斷言與過濾器的註入，雖然實在方法體內作為參數傳入，但是會被spring解析到，直接去工廠裡拿到，具體怎麼拿呢？我們再來看看：
public BeanWrapper instantiateUsingFactoryMethod(
String beanName, RootBeanDefinition mbd, @Nullable Object[] explicitArgs) {
.....
for (Method candidate : candidates) {
Class<?>[] paramTypes = candidate.getParameterTypes();
if (paramTypes.length >= minNrOfArgs) {
ArgumentsHolder argsHolder;
if (explicitArgs != null) {
// Explicit arguments given -> arguments length must match exactly.
if (paramTypes.length != explicitArgs.length) {
continue;
}
argsHolder = new ArgumentsHolder(explicitArgs);
}
else {
// Resolved constructor arguments: type conversion and/or autowiring necessary.
try {
String[] paramNames = null;
ParameterNameDiscoverer pnd = this.beanFactory.getParameterNameDiscoverer();
if (pnd != null) {
paramNames = pnd.getParameterNames(candidate);
}
//主要就是會進入到這裡去解析每一個參數類型
argsHolder = createArgumentArray(beanName, mbd, resolvedValues, bw,
paramTypes, paramNames, candidate, autowiring, candidates.length == 1);
}
catch (UnsatisfiedDependencyException ex) {
if (logger.isTraceEnabled()) {
logger.trace("Ignoring factory method [" + candidate + "] of bean '" + beanName + "': " + ex);
}
// Swallow and try next overloaded factory method.
if (causes == null) {
causes = new LinkedList<>();
}
causes.add(ex);
continue;
}
}
int typeDiffWeight = (mbd.isLenientConstructorResolution() ?
argsHolder.getTypeDifferenceWeight(paramTypes) : argsHolder.getAssignabilityWeight(paramTypes));
// Choose this factory method if it represents the closest match.
if (typeDiffWeight < minTypeDiffWeight) {
factoryMethodToUse = candidate;
argsHolderToUse = argsHolder;
argsToUse = argsHolder.arguments;
minTypeDiffWeight = typeDiffWeight;
ambiguousFactoryMethods = null;
}
// Find out about ambiguity: In case of the same type difference weight
// for methods with the same number of parameters, collect such candidates
// and eventually raise an ambiguity exception.
// However, only perform that check in non-lenient constructor resolution mode,
// and explicitly ignore overridden methods (with the same parameter signature).
else if (factoryMethodToUse != null && typeDiffWeight == minTypeDiffWeight &&
!mbd.isLenientConstructorResolution() &&
paramTypes.length == factoryMethodToUse.getParameterCount() &&
!Arrays.equals(paramTypes, factoryMethodToUse.getParameterTypes())) {
if (ambiguousFactoryMethods == null) {
ambiguousFactoryMethods = new LinkedHashSet<>();
ambiguousFactoryMethods.add(factoryMethodToUse);
}
ambiguousFactoryMethods.add(candidate);
}
}
}
.....
return bw;
}
每一個參數都需要解析，但是看這裡不像沒關系，繼續往下走：就會看到
private ArgumentsHolder createArgumentArray(
String beanName, RootBeanDefinition mbd, @Nullable ConstructorArgumentValues resolvedValues,
BeanWrapper bw, Class<?>[] paramTypes, @Nullable String[] paramNames, Executable executable,
boolean autowiring, boolean fallback) throws UnsatisfiedDependencyException {
....
//這下就是瞭，每個參數都被進行解析
for (int paramIndex = 0; paramIndex < paramTypes.length; paramIndex++) {
....
try {
//我們的參數就是在這裡被進行解析的--resolveAutowiredArgument
Object autowiredArgument = resolveAutowiredArgument(
methodParam, beanName, autowiredBeanNames, converter, fallback);
args.rawArguments[paramIndex] = autowiredArgument;
args.arguments[paramIndex] = autowiredArgument;
args.preparedArguments[paramIndex] = new AutowiredArgumentMarker();
args.resolveNecessary = true;
}
catch (BeansException ex) {
throw new UnsatisfiedDependencyException(
mbd.getResourceDescription(), beanName, new InjectionPoint(methodParam), ex);
}
}
}
//其他不重要的，直接忽略掉
...
return args;
}
開始解析的時看到瞭，我們需要把斷言和過濾器列表都加在進來，那spring是如何加載的呢？是根據方法體內傳入的類型找到所有實現瞭斷言和過濾器工廠接口的類並且進行獲取實例，我們仔細這些工廠的實現類，就會找到我們的使用的一些屬性，比如我們例子中的PrefixPath過濾器和Path斷言；
protected Map<String, Object> findAutowireCandidates(
@Nullable String beanName, Class<?> requiredType, DependencyDescriptor descriptor) {
//主要的就是這個，beanNamesForTypeIncludingAncestors方法，該方法就是從bean工廠中獲取所有當前類的實現實例名稱，
String[] candidateNames = BeanFactoryUtils.beanNamesForTypeIncludingAncestors(
this, requiredType, true, descriptor.isEager());
Map<String, Object> result = new LinkedHashMap<>(candidateNames.length);
...
//遍歷名稱，進行實例化
for (String candidate : candidateNames) {
if (!isSelfReference(beanName, candidate) && isAutowireCandidate(candidate, descriptor)) {
addCandidateEntry(result, candidate, descriptor, requiredType);
}
}
.....
return result;
}
這下我們知道瞭，系統配置的斷言和過濾器是如何被加載 的瞭，那我們還有一個問題，如果我自定義一個，如何被系統識別呢？並且怎麼進行配置呢？不難發現我們之前看源碼時，他是被spring通過找工廠實現類找到並且加載進來的，那我們自己實現工廠接口並且使用@Component註解，讓spring加載進來不就的瞭嗎？但是你會發現系統自定義的屬性斷言或者過濾器都有工廠名字的後綴，這是為什麼呢？影響我們自定義 的類被加載到gateway中且生效嗎？事實是會影響，那為什麼影響呢？我們還是看源碼。因為我們之前的類加載還沒有看完，我們最開始的時候就找到瞭兩個@bean 的自動加載，那這兩個類實例化的時候都做瞭哪些工作，我們還沒有細看；
public RouteDefinitionRouteLocator(RouteDefinitionLocator routeDefinitionLocator,
List<RoutePredicateFactory> predicates,
List<GatewayFilterFactory> gatewayFilterFactories,
GatewayProperties gatewayProperties) {
this.routeDefinitionLocator = routeDefinitionLocator;
initFactories(predicates);
gatewayFilterFactories.forEach(factory -> this.gatewayFilterFactories.put(factory.name(), factory));
this.gatewayProperties = gatewayProperties;
}
initFactories(predicates)：這段代碼主要是進行解析斷言工廠實現類；並且放入一個Map中，
gatewayFilterFactories.forEach(factory -> this.gatewayFilterFactories.put(factory.name(), factory))：跟斷言的代碼幾乎一樣，因為沒有其他多餘的邏輯，所以沒有封裝到方法中，直接使用java8 的流特性，寫完瞭遍歷的過程。大傢要註意一段代碼就是factory.name()，這裡使用瞭一個方法；
default String name() {
return NameUtils.normalizeRoutePredicateName(getClass());
}
主要就是把當前類包含工廠名字的部分去掉瞭，然後用剩下的字符串當key值，所以我們可以使用工廠名字做後墜，也可以不用，但是剩下的字符則是你要寫進配置的關鍵字，不過博主基本都是按照系統自帶屬性一樣，用的是工廠接口的名字做的後綴。
好瞭，今天就講解這麼多，下次在講解gateway接到請求後，是如何進行一步一步過濾的，何時進行斷言校驗的。一次不講這麼多，消化瞭就好。
到此這篇關於SpringCloud Gateway加載斷言predicates與過濾器filters的源碼分析的文章就介紹到這瞭,更多相關SpringCloud Gateway斷言內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet！
推薦閱讀：
- SpringCloud Gateway 路由配置定位原理分析
- Spring Cloud Gateway動態路由Apollo實現詳解
- Spring源碼解析之推斷構造方法
- SpringCloud超詳細講解微服務網關Gateway
- Spring IOC中的Bean對象用法