精尽Spring Boot源码分析 - Condition 接口的扩展

lifullmoon

该系列文章是笔者在学习 Spring Boot 过程中总结下来的，里面涉及到相关源码，可能对读者不太友好，请结合我的源码注释 Spring Boot 源码分析 GitHub 地址 进行阅读

Spring Boot 版本：2.2.x

最好对 Spring 源码有一定的了解，可以先查看我的 《死磕 Spring 之 IoC 篇 - 文章导读》 系列文章

如果该篇内容对您有帮助，麻烦点击一下“推荐”，也可以关注博主，感激不尽~

该系列其他文章请查看：《精尽 Spring Boot 源码分析 - 文章导读》

概述

在上一篇《剖析 @SpringBootApplication 注解》文章分析了 Spring Boot 的自动配置功能，在通过 @EnableAutoConfiguration 注解驱动整个自动配置模块的过程中，并不是所有的自动配置类都需要被注入，不同的自动配置类需要满足一定条件后，才应该进行自动配置。

那么 Spring Boot 怎么知道满足一定条件呢？Spring Boot 对 Spring 的 Condition 接口进行了扩展，然后结合自定义的注解，则可以判断自动配置类是否符合条件。

例如 @ConditionalOnClass 可以指定必须存在哪些 Class 对象才注入这个 Bean。

那么接下来，我们一起来看看 Spring 的 Condition 接口以及 Spring Boot 对其的扩展

Condition 演进史

Profile 的出场

在 Spring 3.1 的版本，为了满足不同环境注册不同的 Bean ，引入了 @Profile 注解。例如：

@Configuration
public class DataSourceConfiguration {

    @Bean
    @Profile("DEV")
    public DataSource devDataSource() {
        // ... 单机 MySQL
    }

    @Bean
    @Profile("PROD")
    public DataSource prodDataSource() {
        // ... 集群 MySQL
    }
}
  • 在测试环境下，我们注册单机 MySQL 的 DataSource Bean
  • 在生产环境下，我们注册集群 MySQL 的 DataSource Bean

Spring 3.1.x 的 @Profile 注解如下：

@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.TYPE)
public @interface Profile {

	/**
	 * The set of profiles for which this component should be registered.
	 */
	String[] value();
}

可以看到，最开始 @Profile 注解并没有结合 @Conditional 注解一起使用，而是在后续版本才引入的

Condition 的出现

在 Spring 4.0 的版本，出现了 Condition 功能，体现在 org.springframework.context.annotation.Condition 接口，如下：

@FunctionalInterface
public interface Condition {

	/**
	 * Determine if the condition matches.
	 * @param context the condition context
	 * @param metadata the metadata of the {@link org.springframework.core.type.AnnotationMetadata class}
	 * or {@link org.springframework.core.type.MethodMetadata method} being checked
	 * @return {@code true} if the condition matches and the component can be registered,
	 * or {@code false} to veto the annotated component's registration
	 */
	boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata);
}

函数式接口，只有一个 matches(..) 方法，判断是否匹配，从入参中可以知道，它是和注解配合一起实现 Condition 功能的，也就是 @Conditional 注解，如下：

@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
public @interface Conditional {

	/**
	 * All {@link Condition} classes that must {@linkplain Condition#matches match}
	 * in order for the component to be registered.
	 */
	Class<? extends Condition>[] value();
}

随之 @Profile 注解也进行了修改，和 @Conditional 注解配合使用

Spring 5.1.x 的 @Profile 注解如下：

@Target({ElementType.TYPE, ElementType.METHOD})
@Retention(RetentionPolicy.RUNTIME)
@Documented
@Conditional(ProfileCondition.class)
public @interface Profile {

	/**
	 * The set of profiles for which the annotated component should be registered.
	 */
	String[] value();
}

这里指定的的 Condition 实现类是 ProfileCondition，如下：

class ProfileCondition implements Condition {

	@Override
	public boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
		MultiValueMap<String, Object> attrs = metadata.getAllAnnotationAttributes(Profile.class.getName());
		if (attrs != null) {
			for (Object value : attrs.get("value")) {
				if (context.getEnvironment().acceptsProfiles(Profiles.of((String[]) value))) {
					return true;
				}
			}
			return false;
		}
		return true;
	}
}

逻辑很简答，从当前 Spring 应用上下文的 Environment 中判断 @Profile 指定的环境是否被激活，被激活了表示匹配成功，则注入对应的 Bean，否则，不进行操作

但是 Spring 本身提供的 Condition 实现类不多，只有一个 ProfileCondition 对象

SpringBootCondition 的进击

Spring Boot 为了满足更加丰富的 Condition 场景，对 Spring 的 Condition 接口进行了扩展，提供更多的实现类，如下：

上面仅列出了部分 SpringBootCondition 的子类，同时这些子类与对应的注解配置一起使用

  • @ConditionalOnClass：必须都存在指定的 Class 对象们
  • @ConditionalOnMissingClass：指定的 Class 对象们必须都不存在
  • @ConditionalOnBean：必须都存在指定的 Bean 们
  • @ConditionalOnMissingBean：指定的 Bean 们必须都不存在
  • @ConditionalOnSingleCandidate：必须存在指定的 Bean
  • @ConditionalOnProperty：指定的属性是否有指定的值
  • @ConditionalOnWebApplication：当前的 WEB 应用类型是否在指定的范围内（ANY、SERVLET、REACTIVE）
  • @ConditionalOnNotWebApplication：不是 WEB 应用类型

上面列出了 Spring Boot 中常见的几种 @ConditionXxx 注解，他们都配合 @Conditional 注解与对应的 Condition 实现类一起使用，提供了非常丰富的 Condition 场景

Condition 在哪生效？

Spring 提供了 Condition 接口以及 @Conditional 注解，那么在 Spring 中哪里体现，或者说是哪里进行判断的呢？

其实我在 《死磕Spring之IoC篇 - @Bean 等注解的实现原理》 这篇文章中有提到过，我们稍微回顾一下，有两种情况：

  • 通过 @Component 注解（及派生注解）标注的 Bean
  • @Configuration 标注的配置类中的 @Bean 标注的方法 Bean

普通 Bean

第一种情况是在 Spring 扫描指定路径下的 .class 文件解析成对应的 BeanDefinition（Bean 的前身）时，会根据 @Conditional 注解判断是否符合条件，如下：

// ClassPathBeanDefinitionScanner.java
public int scan(String... basePackages) {
    // <1> 获取扫描前的 BeanDefinition 数量
    int beanCountAtScanStart = this.registry.getBeanDefinitionCount();

    // <2> 进行扫描，将过滤出来的所有的 .class 文件生成对应的 BeanDefinition 并注册
    doScan(basePackages);

    // Register annotation config processors, if necessary.
    // <3> 如果 `includeAnnotationConfig` 为 `true`（默认），则注册几个关于注解的 PostProcessor 处理器（关键）
    // 在其他地方也会注册，内部会进行判断，已注册的处理器不会再注册
    if (this.includeAnnotationConfig) {
        AnnotationConfigUtils.registerAnnotationConfigProcessors(this.registry);
    }

    // <4> 返回本次扫描注册的 BeanDefinition 数量
    return (this.registry.getBeanDefinitionCount() - beanCountAtScanStart);
}
// ClassPathScanningCandidateComponentProvider.java
private boolean isConditionMatch(MetadataReader metadataReader) {
    if (this.conditionEvaluator == null) {
        this.conditionEvaluator =
                new ConditionEvaluator(getRegistry(), this.environment, this.resourcePatternResolver);
    }
    return !this.conditionEvaluator.shouldSkip(metadataReader.getAnnotationMetadata());
}

上面只是简单的提一下，可以看到会通过 ConditionEvaluator 计算器进行计算，判断是否满足条件

配置类

第二种情况是 Spring 会对 配置类进行处理，扫描到带有 @Bean 注解的方法，尝试解析成 BeanDefinition（Bean 的前身）时，会根据 @Conditional 注解判断是否符合条件，如下：

// ConfigurationClassBeanDefinitionReader.java
private void loadBeanDefinitionsForConfigurationClass(
        ConfigurationClass configClass, TrackedConditionEvaluator trackedConditionEvaluator) {

    // <1> 如果不符合 @Conditional 注解的条件，则跳过
    if (trackedConditionEvaluator.shouldSkip(configClass)) {
        String beanName = configClass.getBeanName();
        if (StringUtils.hasLength(beanName) && this.registry.containsBeanDefinition(beanName)) {
            this.registry.removeBeanDefinition(beanName);
        }
        this.importRegistry.removeImportingClass(configClass.getMetadata().getClassName());
        return;
    }

    // <2> 如果当前 ConfigurationClass 是通过 @Import 注解被导入的
    if (configClass.isImported()) {
        // <2.1> 根据该 ConfigurationClass 对象生成一个 BeanDefinition 并注册
        registerBeanDefinitionForImportedConfigurationClass(configClass);
    }
    // <3> 遍历当前 ConfigurationClass 中所有的 @Bean 注解标注的方法
    for (BeanMethod beanMethod : configClass.getBeanMethods()) {
        // <3.1> 根据该 BeanMethod 对象生成一个 BeanDefinition 并注册（注意这里有无 static 修饰会有不同的配置）
        loadBeanDefinitionsForBeanMethod(beanMethod);
    }

    // <4> 对 @ImportResource 注解配置的资源进行处理，对里面的配置进行解析并注册 BeanDefinition
    loadBeanDefinitionsFromImportedResources(configClass.getImportedResources());
    // <5> 通过 @Import 注解导入的 ImportBeanDefinitionRegistrar 实现类往 BeanDefinitionRegistry 注册 BeanDefinition
    // Mybatis 集成 Spring 就是基于这个实现的，可查看 Mybatis-Spring 项目中的 MapperScannerRegistrar 这个类
    // https://github.com/liu844869663/mybatis-spring/blob/master/src/main/java/org/mybatis/spring/annotation/MapperScannerRegistrar.java
    loadBeanDefinitionsFromRegistrars(configClass.getImportBeanDefinitionRegistrars());
}

上面只是简单的提一下，可以看到会通过 TrackedConditionEvaluator 计算器进行计算，判断是否满足条件

这里提一下，对于 @Bean 标注的方法，会得到 CGLIB 的提升，也就是返回的是一个代理对象，设置一个拦截器专门对 @Bean 方法进行拦截处理，通过依赖查找的方式从 IoC 容器中获取 Bean 对象，如果是单例 Bean，那么每次都是返回同一个对象，所以当主动调用这个方法时获取到的都是同一个对象。

SpringBootCondition

org.springframework.boot.autoconfigure.condition.SpringBootCondition 抽象类，实现了 Condition 接口，Spring Boot 扩展 Condition 的抽象基类，主要用于打印相应的日志，并记录每次的匹配结果，如下：

/**
 * Base of all {@link Condition} implementations used with Spring Boot. Provides sensible
 * logging to help the user diagnose what classes are loaded.
 *
 * @author Phillip Webb
 * @author Greg Turnquist
 * @since 1.0.0
 */
public abstract class SpringBootCondition implements Condition {

	private final Log logger = LogFactory.getLog(getClass());

	@Override
	public final boolean matches(ConditionContext context, AnnotatedTypeMetadata metadata) {
		// <1> 从注解元信息中获取所标注的`类名`（或者`类名#方法名`）
		String classOrMethodName = getClassOrMethodName(metadata);
		try {
			// <2> 获取匹配结果（包含匹配消息），抽象方法，交由子类实现
			ConditionOutcome outcome = getMatchOutcome(context, metadata);
			// <3> 打印匹配日志
			logOutcome(classOrMethodName, outcome);
			// <4> 向 ConditionEvaluationReport 中记录本次的匹配结果
			recordEvaluation(context, classOrMethodName, outcome);
			// <5> 返回匹配结果
			return outcome.isMatch();
		}
		catch (NoClassDefFoundError ex) {
			// 抛出异常
		} catch (RuntimeException ex) {
			// 抛出异常
		}
	}
}

实现的 Condition 接口方法处理过程如下：

  1. 从注解元信息中获取所标注的类名（或者类名#方法名）

    private static String getClassOrMethodName(AnnotatedTypeMetadata metadata) {
    if (metadata instanceof ClassMetadata) {
        ClassMetadata classMetadata = (ClassMetadata) metadata;
        return classMetadata.getClassName();
    }
    MethodMetadata methodMetadata = (MethodMetadata) metadata;
    return methodMetadata.getDeclaringClassName() + "#" + methodMetadata.getMethodName();
}

  2. 调用 getMatchOutcome(..) 方法，获取匹配结果（包含匹配消息），抽象方法，交由子类实现

  3. 打印匹配日志

    protected final void logOutcome(String classOrMethodName, ConditionOutcome outcome) {
    if (this.logger.isTraceEnabled()) {
        this.logger.trace(getLogMessage(classOrMethodName, outcome));
    }
}

  4. 向 ConditionEvaluationReport 中记录本次的匹配结果

    private void recordEvaluation(ConditionContext context, String classOrMethodName, ConditionOutcome outcome) {
    if (context.getBeanFactory() != null) {
        ConditionEvaluationReport.get(context.getBeanFactory()).recordConditionEvaluation(classOrMethodName, this, outcome);
    }
}

  5. 返回匹配结果

SpringBootCondition 的实现类

OnClassCondition

org.springframework.boot.autoconfigure.condition.OnClassCondition，继承 SpringBootCondition 抽象类，如下：

@Order(Ordered.HIGHEST_PRECEDENCE)
class OnClassCondition extends FilteringSpringBootCondition {
    /**
	 * 该方法来自 {@link SpringBootCondition} 判断某个 Bean 是否符合注入条件（`@ConditionalOnClass` 和 `ConditionalOnMissingClass`）
	 */
	@Override
	public ConditionOutcome getMatchOutcome(ConditionContext context, AnnotatedTypeMetadata metadata) {
		ClassLoader classLoader = context.getClassLoader();
		ConditionMessage matchMessage = ConditionMessage.empty();
		// <1> 获取这个类上面的 `@ConditionalOnClass` 注解的值
		// 也就是哪些 Class 对象必须存在
		List<String> onClasses = getCandidates(metadata, ConditionalOnClass.class);
		if (onClasses != null) {
			// <1.1> 找到这些 Class 对象中哪些是不存在的
			List<String> missing = filter(onClasses, ClassNameFilter.MISSING, classLoader);
			// <1.2> 如果存在不存在的，那么不符合条件，返回不匹配
			if (!missing.isEmpty()) {
				return ConditionOutcome.noMatch(ConditionMessage.forCondition(ConditionalOnClass.class)
						.didNotFind("required class", "required classes").items(Style.QUOTE, missing));
			}
			// <1.3> 添加 `@ConditionalOnClass` 满足条件的匹配信息
			matchMessage = matchMessage.andCondition(ConditionalOnClass.class)
					.found("required class", "required classes")
					.items(Style.QUOTE, filter(onClasses, ClassNameFilter.PRESENT, classLoader));
		}
		// <2> 获取这个类上面的 `@ConditionalOnMissingClass` 注解的值
		// 也就是这些 Class 对象必须都不存在
		List<String> onMissingClasses = getCandidates(metadata, ConditionalOnMissingClass.class);
		if (onMissingClasses != null) {
			// <2.1> 找到这些 Class 对象中哪些是存在的
			List<String> present = filter(onMissingClasses, ClassNameFilter.PRESENT, classLoader);
			// <2.2> 如果有一个存在，那么不符合条件，返回不匹配
			if (!present.isEmpty()) {
				return ConditionOutcome.noMatch(ConditionMessage.forCondition(ConditionalOnMissingClass.class)
						.found("unwanted class", "unwanted classes").items(Style.QUOTE, present));
			}
			// <2.3> 添加 `@ConditionalOnMissingClass` 满足条件的匹配信息
			matchMessage = matchMessage.andCondition(ConditionalOnMissingClass.class)
					.didNotFind("unwanted class", "unwanted classes")
					.items(Style.QUOTE, filter(onMissingClasses, ClassNameFilter.MISSING, classLoader));
		}
		// <3> 返回符合条件的结果
		return ConditionOutcome.match(matchMessage);
	}
}

判断是否匹配的过程如下：

  1. 获取这个类上面的 @ConditionalOnClass 注解的值，也就是哪些 Class 对象必须存在

    1. 找到这些 Class 对象中哪些是不存在的

      protected final List<String> filter(Collection<String> classNames, ClassNameFilter classNameFilter,
        ClassLoader classLoader) {
    // 如果为空，则返回空结果
    if (CollectionUtils.isEmpty(classNames)) {
        return Collections.emptyList();
    }
    List<String> matches = new ArrayList<>(classNames.size());
    // 使用 `classNameFilter` 对 `classNames` 进行过滤
    for (String candidate : classNames) {
        if (classNameFilter.matches(candidate, classLoader)) {
            matches.add(candidate);
        }
    }
    // 返回匹配成功的 `className` 们
    return matches;
}

    2. 如果存在不存在的，那么不符合条件，返回不匹配

    3. 添加 @ConditionalOnClass 满足条件的匹配信息

  2. 获取这个类上面的 @ConditionalOnMissingClass 注解的值，也就是这些 Class 对象必须都不存在

    1. 找到这些 Class 对象中哪些是存在的，和上面的 1.1 差不多，只不过这里传的是 ClassNameFilter.PRESENT 过滤器
    2. 如果有一个存在，那么不符合条件，返回不匹配
    3. 添加 @ConditionalOnMissingClass 满足条件的匹配信息

  3. 返回符合条件的结果

上面使用到的 ClassNameFilter 如下：

protected enum ClassNameFilter {

    /** 指定类存在 */
    PRESENT {
        @Override
        public boolean matches(String className, ClassLoader classLoader) {
            return isPresent(className, classLoader);
        }
    },

    /** 指定类不存在 */
    MISSING {
        @Override
        public boolean matches(String className, ClassLoader classLoader) {
            return !isPresent(className, classLoader);
        }
    };

    abstract boolean matches(String className, ClassLoader classLoader);

    static boolean isPresent(String className, ClassLoader classLoader) {
        if (classLoader == null) {
            classLoader = ClassUtils.getDefaultClassLoader();
        }
        try {
            // 加载指定类，加载成功表示存在这个类
            resolve(className, classLoader);
            return true;
        }
        catch (Throwable ex) {
            // 加载失败表示不存在这个类
            return false;
        }
    }
}

逻辑很简单，就是判断 Class 对象是否存在或者不存在

其它实现类

关于 SpringBootCondition 其他的实现类逻辑都差不多，感兴趣的可以去看看

回顾自动配置

在上一篇《剖析 @SpringBootApplication 注解》 文章分析通过 @EnableAutoConfiguration 注解驱动整个自动配置模块的过程中，会通过指定的 AutoConfigurationImportFilter 对所有的自动配置类进行过滤，满足条件才进行自动配置

可以回顾一下上一篇文章的 2. getAutoConfigurationEntry 方法 小节和 3. filter 方法 小节

protected AutoConfigurationEntry getAutoConfigurationEntry(AutoConfigurationMetadata autoConfigurationMetadata,
        AnnotationMetadata annotationMetadata) {
    // <1> 如果通过 `spring.boot.enableautoconfiguration` 配置关闭了自动配置功能
    if (!isEnabled(annotationMetadata)) {
        // 则返回一个“空”的对象
        return EMPTY_ENTRY;
    }
    // <2> 获取 `@EnableAutoConfiguration` 注解的配置信息
    AnnotationAttributes attributes = getAttributes(annotationMetadata);
    // <3> 从所有的 `META-INF/spring.factories` 文件中找到 `@EnableAutoConfiguration` 注解对应的类（需要自动配置的类）
    List<String> configurations = getCandidateConfigurations(annotationMetadata, attributes);
    // <4> 对所有的自动配置类进行去重
    configurations = removeDuplicates(configurations);
    // <5> 获取需要排除的自动配置类
    // 可通过 `@EnableAutoConfiguration` 注解的 `exclude` 和 `excludeName` 配置
    // 也可以通过 `spring.autoconfigure.exclude` 配置
    Set<String> exclusions = getExclusions(annotationMetadata, attributes);
    // <6> 处理 `exclusions` 中特殊的类名称，保证能够排除它
    checkExcludedClasses(configurations, exclusions);
    // <7> 从 `configurations` 中将 `exclusions` 需要排除的自动配置类移除
    configurations.removeAll(exclusions);
    /**
     * <8> 从 `META-INF/spring.factories` 找到所有的 {@link AutoConfigurationImportFilter} 对 `configurations` 进行过滤处理
     * 例如 Spring Boot 中配置了 {@link org.springframework.boot.autoconfigure.condition.OnClassCondition}
     * 在这里提前过滤掉一些不满足条件的自动配置类，在 Spring 注入 Bean 的时候也会判断哦~
     */
    configurations = filter(configurations, autoConfigurationMetadata);
    fireAutoConfigurationImportEvents(configurations, exclusions);
    // <10> 将所有的自动配置类封装成一个 AutoConfigurationEntry 对象，并返回
    return new AutoConfigurationEntry(configurations, exclusions);
}

我们看到第 8 步，调用 filter(..) 方法， 目的就是过滤掉一些不符合 Condition 条件的自动配置类

private List<String> filter(List<String> configurations, AutoConfigurationMetadata autoConfigurationMetadata) {
    long startTime = System.nanoTime();
    // <1> 将自动配置类保存至 `candidates` 数组中
    String[] candidates = StringUtils.toStringArray(configurations);
    boolean[] skip = new boolean[candidates.length];
    boolean skipped = false;
    /*
     * <2> 从 `META-INF/spring.factories` 找到所有的 AutoConfigurationImportFilter 对 `candidates` 进行过滤处理
     * 有 OnClassCondition、OnBeanCondition、OnWebApplicationCondition
     */
    for (AutoConfigurationImportFilter filter : getAutoConfigurationImportFilters()) {
        // <2.1> Aware 回调
        invokeAwareMethods(filter);
        // <2.2> 对 `candidates` 进行匹配处理，获取所有的匹配结果
        boolean[] match = filter.match(candidates, autoConfigurationMetadata);
        // <2.3> 遍历匹配结果，将不匹配的自动配置类至空
        for (int i = 0; i < match.length; i++) {
            if (!match[i]) {
                skip[i] = true;
                candidates[i] = null;
                skipped = true;
            }
        }
    }
    // <3> 如果没有不匹配的结果则全部返回
    if (!skipped) {
        return configurations;
    }
    // <4> 获取到所有匹配的自动配置类，并返回
    List<String> result = new ArrayList<>(candidates.length);
    for (int i = 0; i < candidates.length; i++) {
        if (!skip[i]) {
            result.add(candidates[i]);
        }
    }
    return new ArrayList<>(result);
}

可以看到第 2 步，会从 META-INF/spring.factories 中找到对应的 AutoConfigurationImportFilter 实现类对所有的自动配置类进行过滤

# Auto Configuration Import Filters
org.springframework.boot.autoconfigure.AutoConfigurationImportFilter=\
org.springframework.boot.autoconfigure.condition.OnBeanCondition,\
org.springframework.boot.autoconfigure.condition.OnClassCondition,\
org.springframework.boot.autoconfigure.condition.OnWebApplicationCondition

这里，我们一定要注意到入参中的 AutoConfigurationMetadata 对象，它里面保存了 META-INF/spring-autoconfigure-metadata.properties 文件中 Spring Boot 的自动配置类的注解元信息（Sprng Boot 编译时生成的），如何来的请回顾上一篇文章

AutoConfigurationImportFilter

org.springframework.boot.autoconfigure.AutoConfigurationImportFilter 接口，用于过滤掉无需自动引入的自动配置类

/**
 * Filter that can be registered in {@code spring.factories} to limit the
 * auto-configuration classes considered. This interface is designed to allow fast removal
 * of auto-configuration classes before their bytecode is even read.
 *
 * @author Phillip Webb
 * @since 1.5.0
 */
@FunctionalInterface
public interface AutoConfigurationImportFilter {

	boolean[] match(String[] autoConfigurationClasses, AutoConfigurationMetadata autoConfigurationMetadata);
}

可以看到它的注释，因为自动配置类会很多，如果无需使用，而创建对应的 Bean（字节码）到 JVM 内存中，将是一种浪费

可以看到它的最终实现类，都是构建在 SpringBootCondition 之上。

相关文章：

猜你喜欢
相关资源
相似解决方案
热门标签
Java Python linux javascript Mysql C# Docker 算法 前端 SpringBoot Redis Vue spring 设计模式 .net core .net kubernetes c++ 数据库 数据结构 大数据 js 机器学习 微服务 Android Go 程序员 面试 JVM ASP.net core 云原生 人工智能 后端 PHP git CSS golang k8s Nginx Django mybatis 深度学习 多线程 React 架构 devops 爬虫 云计算 Spring Boot LeetCode