Bootstrap

微服务网关Zuul和Gateway的区别

版权声明：本文为博主原创文章，遵循 CC 4.0 by-sa 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/xc1158840657/article/details/90712084

微服务系列（一）聊聊服务网关
前几年随着分布式架构的演变，微服务开始兴起，自然也产生了一系列支持微服务的框架，例如本文要聊到的Spring Cloud。

Spring 相信做Java的小伙伴们已经耳熟能详了，也正是应该这个Spring生态获得广大的关注，在Spring之上开发的新兴框架如Spring Boot、Spring Cloud也很快让大家熟知。

下面主要针对Spring Cloud聊聊它所实现的服务网关，并针对市面上常用的Nginx做一些分析和比较。

由于笔者比较熟悉和擅长的语言是Java，所以仅针对Java框架来做一些源码层面的分析。

服务网关的角色
常见微服务架构

可以看到，网关层是最外层，浏览器与服务器交互时经过的第一个服务节点，它主要起屏蔽下游业务服务的作用，对于浏览器而言，只需要跟网关交互就相当于在与下游多个业务服务节点交互，让浏览器觉得他在和一台服务器交互。

这样的好处显而易见，不管是下游业务服务、支撑服务、基础服务，都对于浏览器屏蔽，与服务器的交互变的非常简单，浏览器无需关心各个节点的依赖关系、如何协同工作，浏览器只会了解到本次请求是否成功；开发者可以灵活的增加业务服务模块；可以在网关层做一些最上层的公用的操作，如过滤恶意请求、设置ip黑白名单、做身份认证、限流、负载均衡等。

换个角度考虑一下，如果去掉网关层，浏览器交互的最外层服务是业务服务层，由于需要解决单点登陆问题，必须在每个业务服务节点上多扮演一个auth client的角色，从开发的角度上看，明显增加了复杂度，试问本可以只需要在一个网关服务上构建auth client，为何要选择在多个（并且可能还会增加）的业务服务上构建auth client呢？

另外，从开发上讲可能还需要解决跨域请求的问题，前后端分离架构中后端api的展示也会是一个问题，也不便于管理；对于同一服务多节点的负载均衡也不好实现，难道需要浏览器每次访问前都去访问一次注册中心？

通过分析发现，微服务架构中，对于再小的业务量的项目，服务网关都是必不可少的。

Spring Cloud Netflix Zuul和Spring Cloud Gateway
Zuul在早期微服务架构中用的非常广泛，如今Spring Cloud推出了Spring Cloud Gateway，那么作为开发者，应该考虑以下问题：该如何选择？他们之间的差异有哪些？各有什么优势呢？

下面从源码入手，探索Zuul的工作原理，尝试理解他的设计理念。

为了图方便，就不去github上download源码了，直接在pom引入依赖，开干…进入com.netflix.zuul.http.ZuulServlet

 

  1.  
    public class ZuulServlet extends HttpServlet {
     
  3.  
    private ZuulRunner zuulRunner;
     
  5.  
    public void init(ServletConfig config) throws ServletException {
     
  6.  
    ...
     
  7.  
    }
     
  8.  
    public void service(javax.servlet.ServletRequest servletRequest, javax.servlet.ServletResponse servletResponse) throws ServletException, IOException {
     
  9.  
    ...
     
  10.  
    }
     
  11.  
    }
     
 

它继承了HttpServlet，熟悉吗？不熟悉的话，可以打开你熟悉的DispatchServlet，看看它继承了谁？
 

也就是说，它本质上用了java.servlet API，实现了一个有网关功能的servlet。
 

那么继续观察一下它的com.netflix.zuul.http.ZuulServlet#service方法：
 --------------------- 
 版权声明：本文为CSDN博主「XCXCXCXCX__」的原创文章，遵循CC 4.0 by-sa版权协议，转载请附上原文出处链接及本声明。
 原文链接：https://blog.csdn.net/xc1158840657/article/details/90712084
 

 

  1.  
    try {
     
  2.  
    init((HttpServletRequest) servletRequest, (HttpServletResponse) servletResponse);
     
  4.  
    // Marks this request as having passed through the "Zuul engine", as opposed to servlets
     
  5.  
    // explicitly bound in web.xml, for which requests will not have the same data attached
     
  6.  
    RequestContext context = RequestContext.getCurrentContext();
     
  7.  
    context.setZuulEngineRan();
     
  9.  
    try {
     
  10.  
    preRoute();
     
  11.  
    } catch (ZuulException e) {
     
  12.  
    error(e);
     
  13.  
    postRoute();
     
  14.  
    return;
     
  15.  
    }
     
  16.  
    try {
     
  17.  
    route();
     
  18.  
    } catch (ZuulException e) {
     
  19.  
    error(e);
     
  20.  
    postRoute();
     
  21.  
    return;
     
  22.  
    }
     
  23.  
    try {
     
  24.  
    postRoute();
     
  25.  
    } catch (ZuulException e) {
     
  26.  
    error(e);
     
  27.  
    return;
     
  28.  
    }
     
  30.  
    } catch (Throwable e) {
     
  31.  
    error(new ZuulException(e, 500, "UNHANDLED_EXCEPTION_" + e.getClass().getName()));
     
  32.  
    } finally {
     
  33.  
    RequestContext.getCurrentContext().unset();
     
  34.  
    }
     
 

可以看到，它做了以下几件事：
 

  1. 前置路由
  2. 路由
  3. 后置路由
  4. 异常处理
 

不管是preRoute()、route()、postRoute()、error()，它们最终调用了com.netflix.zuul.FilterProcessor#runFilters
 

 

  1.  
    public Object runFilters(String sType) throws Throwable {
     
  2.  
    if (RequestContext.getCurrentContext().debugRouting()) {
     
  3.  
    Debug.addRoutingDebug("Invoking {" + sType + "} type filters");
     
  4.  
    }
     
  5.  
    boolean bResult = false;
     
  6.  
    List<ZuulFilter> list = FilterLoader.getInstance().getFiltersByType(sType);
     
  7.  
    if (list != null) {
     
  8.  
    for (int i = 0; i < list.size(); i++) {
     
  9.  
    //ZuulFilter list
     
  10.  
    //轮流执行ZuulFilter的逻辑，result=false或执行完所有ZuulFilter时调用链结束
     
  11.  
    ZuulFilter zuulFilter = list.get(i);
     
  12.  
    Object result = processZuulFilter(zuulFilter);
     
  13.  
    if (result != null && result instanceof Boolean) {
     
  14.  
    bResult |= ((Boolean) result);
     
  15.  
    }
     
  16.  
    }
     
  17.  
    }
     
  18.  
    return bResult;
     
  19.  
    }
     
 

这里FilterLoader的源码就不深入分析了，它主要的功能是：
 

从FilterRegistry（相当于内存中的filter）加载Zuulfilter list
 编译groovy文件（笔者的Zuul版本1.3.0，目前仅支持groovy文件）并加载Zuulfilter
 对于FilterRegistry，则是用于内存中保存filter，可以动态变化的，注册新的filter以及移除filter等，可提供给jmx、endpoint做远程控制。
 

继续看看com.netflix.zuul.FilterProcessor#processZuulFilter
 

 

  1.  
    public Object processZuulFilter(ZuulFilter filter) throws ZuulException {
     
  3.  
    RequestContext ctx = RequestContext.getCurrentContext();
     
  4.  
    boolean bDebug = ctx.debugRouting();
     
  5.  
    final String metricPrefix = "zuul.filter-";
     
  6.  
    long execTime = 0;
     
  7.  
    String filterName = "";
     
  8.  
    try {
     
  9.  
    long ltime = System.currentTimeMillis();
     
  10.  
    filterName = filter.getClass().getSimpleName();
     
  12.  
    RequestContext copy = null;
     
  13.  
    Object o = null;
     
  14.  
    Throwable t = null;
     
  16.  
    if (bDebug) {
     
  17.  
    Debug.addRoutingDebug("Filter " + filter.filterType() + " " + filter.filterOrder() + " " + filterName);
     
  18.  
    copy = ctx.copy();
     
  19.  
    }
     
  20.  
    //执行ZuulFilter的runFilter逻辑
     
  21.  
    ZuulFilterResult result = filter.runFilter();
     
  22.  
    ExecutionStatus s = result.getStatus();
     
  23.  
    //执行耗时统计（可以发现Zuul还没有完善这个功能，只是形成了框架）
     
  24.  
    execTime = System.currentTimeMillis() - ltime;
     
  25.  
    //处理执行结果，无论成功与否，都记录了debug日志
     
  26.  
    switch (s) {
     
  27.  
    case FAILED:
     
  28.  
    t = result.getException();
     
  29.  
    ctx.addFilterExecutionSummary(filterName, ExecutionStatus.FAILED.name(), execTime);
     
  30.  
    break;
     
  31.  
    case SUCCESS:
     
  32.  
    o = result.getResult();
     
  33.  
    ctx.addFilterExecutionSummary(filterName, ExecutionStatus.SUCCESS.name(), execTime);
     
  34.  
    if (bDebug) {
     
  35.  
    Debug.addRoutingDebug("Filter {" + filterName + " TYPE:" + filter.filterType() + " ORDER:" + filter.filterOrder() + "} Execution time = " + execTime + "ms");
     
  36.  
    Debug.compareContextState(filterName, copy);
     
  37.  
    }
     
  38.  
    break;
     
  39.  
    default:
     
  40.  
    break;
     
  41.  
    }
     
  43.  
    if (t != null) throw t;
     
  44.  
    //目前作为空壳存在，可见是为了方便扩展
     
  45.  
    usageNotifier.notify(filter, s);
     
  46.  
    return o;
     
  48.  
    } catch (Throwable e) {
     
  49.  
    if (bDebug) {
     
  50.  
    Debug.addRoutingDebug("Running Filter failed " + filterName + " type:" + filter.filterType() + " order:" + filter.filterOrder() + " " + e.getMessage());
     
  51.  
    }
     
  52.  
    usageNotifier.notify(filter, ExecutionStatus.FAILED);
     
  53.  
    if (e instanceof ZuulException) {
     
  54.  
    throw (ZuulException) e;
     
  55.  
    } else {
     
  56.  
    ZuulException ex = new ZuulException(e, "Filter threw Exception", 500, filter.filterType() + ":" + filterName);
     
  57.  
    ctx.addFilterExecutionSummary(filterName, ExecutionStatus.FAILED.name(), execTime);
     
  58.  
    throw ex;
     
  59.  
    }
     
  60.  
    }
     
  61.  
    }
     
 

这样一来，Zuul基本原理走完了，可以看出来非常的简单，实际上整个调用链是由ZuulFilter来组成，对于用户而言，只需要关心如果构建自定义的ZuulFilter以及它们之间的顺序。
 

Zuul提供了com.netflix.zuul.filters.StaticResponseFilter和com.netflix.zuul.filters.SurgicalDebugFilter两种抽象类，StaticResponseFilter会将请求直接处理并返回，即不会经过路由链路；SurgicalDebugFilter则会将请求路由到zuul.debug.vip 或 zuul.debug.host所指定的debug Eureka “VIP” or host。
 

另外，还有一个类也需要关注，com.netflix.zuul.filters.ZuulServletFilter，通过源码方向追踪后发现usages均是Test类，可见它应该是一个待开发的功能，去允许用户在路由前做过滤处理。
 

看完了源码，了解了工作原理后，整理一下Zuul的特点：
 

很明显，由于底层是servlet，Zuul处理的是http请求
 Zuul的抽象写的非常简单易懂，易于扩展，易于debug
 提供了两种特殊的抽象类，用户使用起来，比较灵活
 zuul-core包不依赖Spring，依赖的包很少
 没有提供异步支持
 流控等均由hystrix支持
 那么继续开始分析Spring Cloud Gateway源码…
 

Spring Cloud Gateway的代码相比zuul会比较难懂，特别是对于不熟悉流式编程的小伙伴来说。
 

我可以给个建议，如果实在是看不懂、从头到尾很懵的话，请结合spring mvc的源码对照来理解！
 

先来看看这个类org.springframework.cloud.gateway.config.GatewayAutoConfiguration
 

 

  1.  
    @Configuration
     
  2.  
    @ConditionalOnProperty(name = "spring.cloud.gateway.enabled", matchIfMissing = true)
     
  3.  
    @EnableConfigurationProperties
     
  4.  
    @AutoConfigureBefore(HttpHandlerAutoConfiguration.class)
     
  5.  
    @AutoConfigureAfter({GatewayLoadBalancerClientAutoConfiguration.class, GatewayClassPathWarningAutoConfiguration.class})
     
  6.  
    @ConditionalOnClass(DispatcherHandler.class)
     
  7.  
    public class GatewayAutoConfiguration {
     
  9.  
    ...
     
  11.  
    //由于内容比较多，就不全部贴出来了
     
  12.  
    @Bean
     
  13.  
    @ConditionalOnBean(DispatcherHandler.class)
     
  14.  
    public ForwardRoutingFilter forwardRoutingFilter(DispatcherHandler dispatcherHandler) {
     
  15.  
    return new ForwardRoutingFilter(dispatcherHandler);
     
  16.  
    }
     
  18.  
    ...
     
  20.  
    }
     
 

继续点进去org.springframework.web.reactive.DispatcherHandler，先不用看它的源码，reactive???它是webflux的核心组件!!!
 

由于webflux的基本原理和webmvc大同小异，就不仔细分析其源码了，但需要了解的一点是，webflux大量运用流式编程，代码非常简短，也很契合的支持请求异步处理。
 

那么继续追踪org.springframework.cloud.gateway.filter.ForwardRoutingFilter，找到一个重要的接口org.springframework.cloud.gateway.filter.GlobalFilter。
 

注释：
 

Contract for interception-style, chained processing of Web requests that may be used to implement cross-cutting, application-agnostic requirements such as security, timeouts, and others.
 

译：
 

用于拦截式Web连接处理的合同，可用于实现跨领域，与应用程序无关的要求，如安全性，超时等。
 

这里先放着，后边会用到它。
 

发现了底层由org.springframework.web.reactive.DispatcherHandler来支持后，那么猜想可能会基于DispatcherHandler怎么做扩展呢？
 

继承DispatcherHandler重新实现分发逻辑（类似Zuul）
 扩展DispatcherHandler的组件HandlerMapping
 找到一个重要的类org.springframework.cloud.gateway.handler.RoutePredicateHandlerMapping，猜想(2)验证
 

org.springframework.cloud.gateway.handler.RoutePredicateHandlerMapping#getHandlerInternal
 

 

  1.  
    protected Mono<?> getHandlerInternal(ServerWebExcha nge exchange) {
     
  2.  
    exchange.getAttributes().put(GATEWAY_HANDLER_MAPPER_ATTR, getClass().getSimpleName());
     
  4.  
    return lookupRoute(exchange)//根据exchange找匹配的route
     
  5.  
    // .log("route-predicate-handler-mapping", Level.FINER) //name this
     
  6.  
    .flatMap((Function<Route, Mono<?>>) r -> {//替换请求attributes值
     
  7.  
    exchange.getAttributes().remove(GATEWAY_PREDICATE_ROUTE_ATTR);
     
  8.  
    if (logger.isDebugEnabled()) {
     
  9.  
    logger.debug("Mapping [" + getExchangeDesc(exchange) + "] to " + r);
     
  10.  
    }
     
  12.  
    exchange.getAttributes().put(GATEWAY_ROUTE_ATTR, r);
     
  13.  
    return Mono.just(webHandler);//执行filter的handle方法
     
  14.  
    }).switchIfEmpty(Mono.empty().then(Mono.fromRunnable(() -> {
     
  15.  
    exchange.getAttributes().remove(GATEWAY_PREDICATE_ROUTE_ATTR);
     
  16.  
    if (logger.isTraceEnabled()) {
     
  17.  
    logger.trace("No RouteDefinition found for [" + getExchangeDesc(exchange) + "]");
     
  18.  
    }
     
  19.  
    })));//异常处理
     
  20.  
    }
     
 

org.springframework.cloud.gateway.handler.RoutePredicateHandlerMapping#lookupRoute
 

 

  1.  
    protected Mono<Route> lookupRoute(ServerWebExchange exchange) {
     
  2.  
    return this.routeLocator.getRoutes()
     
  3.  
    .filterWhen(route -> {//找到匹配的route，一个route包含一个filter链
     
  4.  
    // add the current route we are testing
     
  5.  
    exchange.getAttributes().put(GATEWAY_PREDICATE_ROUTE_ATTR, route.getId());
     
  6.  
    return route.getPredicate().apply(exchange);
     
  7.  
    })
     
  8.  
    // .defaultIfEmpty() put a static Route not found
     
  9.  
    // or .switchIfEmpty()
     
  10.  
    // .switchIfEmpty(Mono.<Route>empty().log("noroute"))
     
  11.  
    .next()
     
  12.  
    //TODO: error handling
     
  13.  
    .map(route -> {
     
  14.  
    if (logger.isDebugEnabled()) {
     
  15.  
    logger.debug("Route matched: " + route.getId());
     
  16.  
    }
     
  17.  
    validateRoute(route, exchange);
     
  18.  
    return route;
     
  19.  
    });
     
  21.  
    /* TODO: trace logging
     
  22.  
    if (logger.isTraceEnabled()) {
     
  23.  
    logger.trace("RouteDefinition did not match: " + routeDefinition.getId());
     
  24.  
    }*/
     
  25.  
    }
     
 

org.springframework.cloud.gateway.route.RouteDefinitionRouteLocator#getRoutes
 

 

  1.  
    @Override
     
  2.  
    public Flux<Route> getRoutes() {
     
  3.  
    return this.routeDefinitionLocator.getRouteDefinitions()
     
  4.  
    .map(this::convertToRoute)
     
  5.  
    //TODO: error handling
     
  6.  
    .map(route -> {
     
  7.  
    if (logger.isDebugEnabled()) {
     
  8.  
    logger.debug("RouteDefinition matched: " + route.getId());
     
  9.  
    }
     
  10.  
    return route;
     
  11.  
    });
     
  14.  
    /* TODO: trace logging
     
  15.  
    if (logger.isTraceEnabled()) {
     
  16.  
    logger.trace("RouteDefinition did not match: " + routeDefinition.getId());
     
  17.  
    }*/
     
  18.  
    }
     
 

这里又发现了一个类org.springframework.cloud.gateway.route.RouteDefinitionLocator
 

 

  1.  
    public interface RouteDefinitionLocator {
     
  3.  
    Flux<RouteDefinition> getRouteDefinitions();
     
  4.  
    }
     
 

从名称和方法可以看出RouteDefinitionLocator用于存放route信息，而真正可以执行route逻辑的则是Route，Route中包含filter链。
 

其扩展了以下几种：
 

DiscoveryClientRouteDefinitionLocator
 CachingRouteDefinitionLocator
 CompositeRouteDefinitionLocator
 InMemoryRouteDefinitionRepository
 PropertiesRouteDefinitionLocator
 可以发现，这样做的好处是方便扩展功能，例如DiscoveryClientRouteDefinitionLocator可以实现从不同的注册中心上获取服务信息、CachingRouteDefinitionLocator则可以在本地JVM中用map缓存服务信息、或是用InMemoryRouteDefinitionRepository直接在内存中管理服务信息。
 

那么对于filter，它们均实现了前文所说的org.springframework.cloud.gateway.filter.GlobalFilter接口，Spring Cloud Gateway也提供了丰富的实现，如：
 

AdaptCachedBodyGlobalFilter
 ForwardPathFilter
 ForwardRoutingFilter
 LoadBalancerClientFilter
 NettyRoutingFilter
 NettyWriteResponseFilter
 RouteToRequestUrlFilter
 WebClientHttpRoutingFilter
 WebClientWriteResponseFilter
 WebsocketRoutingFilter
 可以看到，Spring Cloud Gateway对filter的支持更加丰富，包括NettyRoutingFilter&NettyWriteResponseFilter提供HttpClient代理请求的功能、WebClientHttpRoutingFilter&WebClientWriteResponseFilter提供WebClient代理请求的功能、LoadBalancerClientFilter提供负载均衡的支持（其内又有LoadBalancerClient的抽象，支持ribbon，也方便扩展）、ForwardPathFilter重建转发路径、ForwardRoutingFilter进行路由转发等。
 

另外，还有一些值得关注的功能有：
 

RateLimiter
 GatewayControllerEndpoint
 RouteRefreshListener
 RateLimiter是一个接口，用户可以自行实现想要的限流策略及实现方式，Spring Cloud Gateway（2.0.0.RELESE）提供了RedisRateLimiter的实现，具体使用方式参考官网
 

GatewayControllerEndpoint提供了http控制RouteDefinition的endpoint，实现远程管理的效果
 

RouteRefreshListener是用于监听心跳事件、应用刷新事件、bean刷新、服务实例变化而发布route刷新事件，并及时刷新RouteBeanDefinition信息，与之类似的还有监听org.springframework.cloud.gateway.event.WeightDefinedEvent的org.springframework.cloud.gateway.filter.WeightCalculatorWebFilter，可及时更新权重
 

到这里就算过了一遍Spring Cloud Gateway的工作原理和设计模型，更加细节上的功能还有待使用者“开发”，整理一下它的特点：
 

底层依然是servlet，但使用了webflux，多嵌套了一层框架
 理解filter、handler、locator就能灵活使用它，但其大量使用的流式编程容易让人懵逼
 提供了非常丰富的filter实现和灵活的RoutePredicateFactory（route匹配规则）
 依赖spring-boot-starter-webflux和spring-cloud-starter
 提供了异步支持
 提供函数式编程api，使用起来方便快捷
 提供了抽象流控，并默认实现了RedisRateLimiter
 提供了抽象负载均衡
 支持HttpClient、WebClient代理请求
 ps.槽点就是作为Spring家族，注释竟然这么少！
 

对比Spring Cloud Netflix Zuul和Spring Cloud Gateway
 

前面整理了两者的特点，现在对比来分析，得出以下结论：
 

两者均是web网关，处理的是http请求
 gateway对比zuul多依赖了spring-webflux，在spring的支持下，功能更强大，内部实现了限流、负载均衡等，扩展性也更强，但同时也限制了仅适合于Spring Cloud套件，而zuul则可以扩展至其他微服务框架中，其内部没有实现限流、负载均衡等
 gateway很好的支持异步，而zuul仅支持同步，那么理论上gateway则更适合于提高系统吞吐量（但不一定能有更好的性能），最终性能还需要通过严密的压测来决定
 从框架设计的角度看，gateway具有更好的扩展性，并且其已经发布了2.0.0的RELESE版本，稳定性也是非常好的
 编码上看，zuul更加简洁易懂，注释规范清晰，而gateway作为Spring家族的一份子，竟然几乎不注释…
 总的来说，在微服务架构，如果使用了Spring Cloud生态的基础组件，则Spring Cloud Gateway相比而言更加具备优势，单从流式编程+支持异步上就足以让开发者选择它了。
 

而对于小型微服务架构或是复杂架构（不仅包括微服务应用还有其他非Spring Cloud服务节点），zuul也是一个不错的选择，当然，这种场景下一般会选择nginx，因为nginx从各个方面都会表现的更好…
 

Nginx在微服务中的地位
 最后简单聊一下nginx，在过去几年微服务架构还没有流行的日子里，nginx已经得到了广大开发者的认可，其性能高、扩展性强、可以灵活利用lua脚本构建插件的特点让人没有抵抗力。
 

有一个能满足我所有需求还很方便我扩展的东西，还免费，凭啥不用？？
 

但是，如今很多微服务架构的项目中不会选择nginx，我认为原因有以下几点：
 

微服务框架一般来说是配套的，集成起来更容易
 如今微服务架构中，仅有很少的公司会面对无法解决的性能瓶颈，而他们也不会因此使用nginx，而是选择开发一套适合自己的微服务框架
 spring boot对于一些模板引擎如FreeMarker、themleaf的支持是非常好的，很多应用还没有达到动、静态文件分离的地步，对nginx的需求程度并不大。
 无论如何，nginx作为一个好用的组件，最终使不使用它都是由业务来驱动的，只要它能为我们方便的解决问题，那用它又有何不可呢？
 

小结
 通过总结发现，在微服务架构中网关上的选择，最好的方式是使用现在比较成熟的Spring Cloud套件，其提供了Spring Cloud Gateway网关，或是结合公司情况来开发一套适合自己的微服务套件，至少从网关上可以看出来其内部实现并不难，同时也比较期待开源项目Nacos、Spring Cloud Alibaba 建设情况，期待它能构建一个高活跃社区的、稳定的、适合中国特色（大流量、高并发）的微服务基础架构。

                
      


    


    

      




    

      
悦读

      
道可道，非常道；名可名，非常名。
无名，天地之始，有名，万物之母。
故常无欲，以观其妙，常有欲，以观其徼。
此两者，同出而异名，同谓之玄，玄之又玄，众妙之门。

    


    
    
    
    
    
    
    
    

    
    




  
    最新收录
  
  

    
    
    
      
Vue+Node的校内闲置物品回收管理系统毕业设计-附源码140933

    
    
    
      
力扣笔记 ——【数组 快慢指针】27. 移除元素

    
    
    
      
Linux60个小时速成

    
    
    
      
HubSpot CRM是什么？如何添加、使用呢？

    
    
    
      
计算机一级英文缩写,下列英文缩写和中文名字的对照中，错误的是

    
    
    
      
数学建模 ---斯皮尔曼相关系数

    
    
    
      
【二叉树】二叉树排序树的判断、插入

    
    
    
      
不属于python标准库_Python标准库概览

    
    
    
      
【U-Net验证】逐元素乘积将特征投射到极高维隐式特征空间的能力

    
    
    
      
Java项目实战--基于SpringBoot3.0开发仿12306高并发售票系统--(一)前置知识

    
    

  




    
   
  







  









  












;