（十一）Spring Cloud Alibaba 2023.x：构建分布式全链路日志追踪体系

RemainderTime2026-03-19 8:50

目录

前言：日志配置的"大学问"

在本地开发时，日志往往被误认为只是简单的控制台输出。然而，当项目进入独立部署的生产环境，面对突发的故障和海量日志时，一套成熟的日志体系就是系统的"眼睛"和"指南针"。

能否设计出兼顾性能与排障效率的日志系统，是衡量一个开发者工程化成熟度的重要标志。本篇文章将带你从零构建一套生产级的全链路追踪体系，助你掌握微服务治理的核心实战。

环境与准备

为了方便读者参考，本项目基于最新的 Spring Cloud Alibaba 生态构建，核心版本如下：

  • JDK: 17
  • Spring Boot: 3.3.5
  • Spring Cloud: 2023.0.1
  • Spring Cloud Alibaba: 2023.0.1.0

🏗️项目结构说明

本项目是一个开箱即用的微服务脚手架，主要模块职责如下：

  • cloud-gateway : API 网关，负责流量入口、鉴权与 TraceId 生成。
  • cloud-common : 公共模块，包含 日志拦截器、MDC 配置与 Feign 透传。
  • cloud-user / cloud-producer / cloud-consumer: 具体的业务微服务。

源码参考 ：本项目已开源，欢迎 Star 支持！

👉 GitHub 地址：spring-cloud-alibaba-base-demo

架构选型：实现两套日志配置

在正式撸代码之前，我们需要先思考一个落地问题：既然微服务架构强调统一管理，我们能不能只写一个 logback-spring.xml 扔进公共模块（Common），让网关和业务服务都引用它？

答案是：不建议，甚至由于架构差异，这会成为系统埋下的"性能地雷"。

在本方案中，我们将分别在 cloud-gateway 和 cloud-common 中配置两套独立的 logback-spring.xml。这种看似"啰嗦"的做法，源于我在实战中对分布式系统吞吐量与排障成本的权衡：

  • 网关（Gateway）的诉求------高性能与极简：网关是流量总入口，每秒处理的请求可能是业务服务的几十倍。它更关注底层网络的稳定性。如果让网关像业务模块那样疯狂打印 SQL、Feign 回调，磁盘 I/O 瞬间就会成为全系统的瓶颈。
  • 业务服务（Common）的诉求------详尽与轨迹 ：业务模块关注的是"谁在什么时间调用了什么接口，执行了哪条 SQL"。它需要详细的文件滚动策略，甚至需要对特定的业务包进行 DEBUG 监控。

实践

一、网关入口------生成生命之源 TraceId

链路追踪的核心在于"唯一标识"。我们在网关生成 TraceId，并由其开启整条链路。

代码位置：cloud-gateway 模块

类：com.xf.gateway.filter.AuthFilter

代码为简化版本只展示traceId生成逻辑，其他代码省略。

java 复制代码 
@Slf4j
@Component
public class AuthFilter implements GlobalFilter, Ordered {
    private static final String TRACE_ID_HEADER = "traceId";

    @Override
    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {
        long startTime = System.currentTimeMillis();
        
        // 1. 生成全局唯一 TraceId (UUID 去除横杠)
        String traceId = UUID.randomUUID().toString().replace("-", "");

        // 2. 将 TraceId 放入响应头，方便前端开发者在浏览器控制台直接看到 ID
        exchange.getResponse().getHeaders().set(TRACE_ID_HEADER, traceId);

        // 3. 将 TraceId 透传给下游微服务
        ServerHttpRequestDecorator decorator = new ServerHttpRequestDecorator(exchange.getRequest()) {
            @Override
            public HttpHeaders getHeaders() {
                HttpHeaders headers = new HttpHeaders();
                headers.putAll(super.getHeaders());
                headers.set(TRACE_ID_HEADER, traceId);
                return headers;
            }
        };

        return chain.filter(exchange.mutate().request(decorator).build())
            .doFinally(signalType -> {
                // 网关访问日志：记录 IP、路径、状态码、耗时和最重要的 TraceId
                log.info("[Access] IP: {}, Path: {}, Status: {}, Time: {}ms, TraceId: {}",
                    exchange.getRequest().getRemoteAddress().getAddress().getHostAddress(),
                    exchange.getRequest().getURI().getPath(),
                    exchange.getResponse().getStatusCode(),
                    System.currentTimeMillis() - startTime,
                    traceId);
                // 清理当前线程 MDC
                MDC.remove("traceId");
            });
    }
}

补充知识：什么是 MDC？

在讲后续代码前，必须先了解一个核心概念：MDC (Mapped Diagnostic Context)。

!IMPORTANT

MDC 是什么？

MDC 是日志框架（Logback/Log4j）提供的一个基于线程绑定的变量映射表。你可以把它理解为一个 ThreadLocal<Map<String, String>>。

为什么用它？

如果我们手动在每个 log.info 里拼写 traceId，代码会变得极其难看。有了 MDC，我们只需要在请求刚进来时 put("traceId", "xxx") 一次，后续该线程执行的所有代码产生的日志，Logback 都会自动把该值填入格式化占位符 %X{traceId} 中。

二、业务链路------接收、存储与透传

当请求流转到业务服务（如 User 服务）时，我们需要接力这个 TraceId。

代码位置：cloud-common 模块 (业务服务通用)

接收并存入 MDC ，位置：com.xf.cloudcommon.filter.RequestHeaderFilter

java 复制代码 
@Configuration
@Slf4j
public class RequestHeaderFilter implements Filter {

    @Override
    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain) throws IOException, ServletException {
        HttpServletRequest req = (HttpServletRequest) request;
        
        // 从 Header 中取出网关生成的 traceId
        String traceId = req.getHeader("traceId");
        
        if (StringUtils.hasText(traceId)) {
            // 核心：存入 MDC
            MDC.put("traceId", traceId);
        }

        try {
            chain.doFilter(request, response);
        } finally {
            // 必须清理！防止线程复用（线程池）导致下一次请求复用旧的 traceId
            MDC.remove("traceId");
        }
    }
}

跨服务 Feign 传播

如果你在业务代码中调用了其他微服务，TraceId 需要继续传递。
类：com.xf.cloudcommon.config.FeignConfig

java 复制代码 
@Configuration
public class FeignConfig implements RequestInterceptor {

    @Override
    public void apply(RequestTemplate template) {
        // 从当前线程的 MDC 中取出 traceId，塞入 Feign 的请求头
        String traceId = MDC.get("traceId");
        if (traceId != null) {
            template.header("traceId", traceId);
        }
    }
}

三、落地两套 logback-spring.xml 配置文件

有了 YAML 的级别控制后，我们开始编写核心的 logback-spring.xml。由于架构差异，我们需要准备两份。

公共模块配置 (cloud-common)

创建一个 logback-spring.xml 文件，并放在 cloud-common 模块的 src/main/resources 目录下。

这份配置将通过 Maven 依赖传递给所有业务模块。它的核心任务是：详尽记录业务行为与 SQL。

xml 复制代码 
<?xml version="1.0" encoding="UTF-8"?>
<configuration scan="true" scanPeriod="60 seconds">
    <springProperty scope="context" name="APP_NAME" source="spring.application.name" defaultValue="service"/>
    <springProperty scope="context" name="LOG_PATH" source="logging.file.path" defaultValue="./logs/${APP_NAME}"/>

    <!-- 格式化：包含核心的 [traceId:%X{traceId}] -->
    <property name="LOG_PATTERN" value="%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level [traceId:%X{traceId}] %logger{50} - %msg%n" />

    <!-- 控制台输出 -->
    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <encoder><pattern>${LOG_PATTERN}</pattern></encoder>
    </appender>

    <!-- 滚动文件输出 -->
    <appender name="INFO_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${LOG_PATH}/info.log</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
            <fileNamePattern>${LOG_PATH}/history/info.%d{yyyy-MM-dd}.%i.log.gz</fileNamePattern>
            <maxFileSize>500MB</maxFileSize>
            <maxHistory>60</maxHistory>
        </rollingPolicy>
        <encoder><pattern>${LOG_PATTERN}</pattern></encoder>
    </appender>

    <!-- SQL 专项审计：只拦截并记录 DEBUG 级别的 SQL 日志 -->
    <appender name="SQL_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${LOG_PATH}/sql.log</file>
        <filter class="ch.qos.logback.classic.filter.LevelFilter">
            <level>DEBUG</level>
            <onMatch>ACCEPT</onMatch>
            <onMismatch>DENY</onMismatch>
        </filter>
        <rollingPolicy class="ch.qos.logback.core.rolling.TimeBasedRollingPolicy">
            <fileNamePattern>${LOG_PATH}/history/sql.%d{yyyy-MM-dd}.log</fileNamePattern>
            <maxHistory>7</maxHistory>
        </rollingPolicy>
        <encoder><pattern>${LOG_PATTERN}</pattern></encoder>
    </appender>

    <!-- 异步输出器：大幅提升并发写入效率 -->
    <appender name="ASYNC_INFO" class="ch.qos.logback.classic.AsyncAppender">
        <queueSize>1024</queueSize>
        <appender-ref ref="INFO_FILE" />
    </appender>

    <logger name="com.xf" level="DEBUG" additivity="true">
        <appender-ref ref="SQL_FILE" />
    </logger>

    <root level="INFO">
        <appender-ref ref="STDOUT" />
        <appender-ref ref="ASYNC_INFO" />
    </root>
</configuration>

网关模块配置 (cloud-gateway)

创建一个 logback-spring.xml 文件，并放在 cloud-gateway 模块的 src/main/resources 目录下。

网关作为全量流量入口，这里的日志重心在于：降噪与极高性能 。同时，由于网关异常往往意味着系统性的崩溃（如连接池满、熔断），因此独立存储错误日志（error.log） 对于故障预警至关重要。

xml 复制代码 
<?xml version="1.0" encoding="UTF-8"?>
<configuration scan="true" scanPeriod="60 seconds">
    <springProperty scope="context" name="APP_NAME" source="spring.application.name" defaultValue="gateway"/>
    <springProperty scope="context" name="LOG_PATH" source="logging.file.path" defaultValue="logs/${APP_NAME}"/>

    <property name="LOG_PATTERN" value="%d{yyyy-MM-dd HH:mm:ss.SSS} [%thread] %-5level [traceId:%X{traceId}] %logger{50} - %msg%n" />

    <!-- 1. 控制台输出 -->
    <appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
        <encoder><pattern>${LOG_PATTERN}</pattern></encoder>
    </appender>

    <!-- 2. 全量日志 (INFO 及以上) -->
    <appender name="INFO_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${LOG_PATH}/info.log</file>
        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
            <fileNamePattern>${LOG_PATH}/history/info.%d{yyyy-MM-dd}.%i.log.gz</fileNamePattern>
            <maxFileSize>500MB</maxFileSize>
            <maxHistory>15</maxHistory>
        </rollingPolicy>
        <encoder><pattern>${LOG_PATTERN}</pattern></encoder>
    </appender>

    <!-- 3. 独立错误日志 (ERROR 专项)：方便统一采集进行钉钉/邮件报警 -->
    <appender name="ERROR_FILE" class="ch.qos.logback.core.rolling.RollingFileAppender">
        <file>${LOG_PATH}/error.log</file>
        <!-- 临界值过滤器：只记录 ERROR 级别及以上的日志 -->
        <filter class="ch.qos.logback.classic.filter.ThresholdFilter">
            <level>ERROR</level>
        </filter>
        <rollingPolicy class="ch.qos.logback.core.rolling.SizeAndTimeBasedRollingPolicy">
            <fileNamePattern>${LOG_PATH}/history/error.%d{yyyy-MM-dd}.%i.log.gz</fileNamePattern>
            <maxFileSize>1GB</maxFileSize>
            <maxHistory>30</maxHistory>
        </rollingPolicy>
        <encoder><pattern>${LOG_PATTERN}</pattern></encoder>
    </appender>

    <!-- 异步输出：网关必配 -->
    <appender name="ASYNC_INFO" class="ch.qos.logback.classic.AsyncAppender">
        <queueSize>2048</queueSize>
        <discardingThreshold>0</discardingThreshold>
        <appender-ref ref="INFO_FILE"/>
    </appender>

    <!-- 屏蔽 Netty 等底层噪音 -->
    <logger name="reactor.netty" level="WARN" />
    <logger name="org.springframework.cloud.gateway" level="INFO" />
    <logger name="com.alibaba.nacos" level="WARN" />

    <root level="INFO">
        <appender-ref ref="STDOUT" />
        <appender-ref ref="ASYNC_INFO" />
        <appender-ref ref="ERROR_FILE" />
    </root>
</configuration>

解析说明

动态占位符说明
  • ${spring.application.name}: 利用 Spring 对 Logback 的增强，自动识别当前微服务名，实现全自动的日志分级存储。
  • %X{traceId} : 全篇最关键点 。%X 是 Logback 专门为 MDC 预留的接口。它会自动从当前线程的诊断上下文中抓取键为 traceId 的值。
核心类与过滤器详解
  • AsyncAppender: 它是异步任务队列。在高并发请求下，业务线程只负责把日志"扔进队列"就立即返回，避免了昂贵的磁盘写入 IO 阻塞核心业务流程。
  • LevelFilter vs ThresholdFilter :
    • LevelFilter 用于"精确匹配"（如：只要 DEBUG）；
    • ThresholdFilter 用于"临界值过滤"（如：ERROR 及以上）。在我们的方案中，SQL 审计使用了前者，确保 sql.log 不会被大量的 INFO 日志污染。

四、YAML 配置与 Nacos 整合

在编写具体的 XML 日志策略前，我们需要在 application.yml（推荐通过 Nacos 统一管理）中定义日志的基础行为。

统一的日志基础配置

为了保证全链路日志的格式和存储路径统一，建议将以下配置作为公共配置（如 common-config.yaml）维护。

本项目中已提供在doc文件夹中

yaml 复制代码 
logging:
  # 1. 强制指定 Logback 配置文件路径，确保加载我们自定义的 XML
  config: classpath:logback-spring.xml
  file:
    # 2. 动态路径：所有微服务根据自己的 application.name 创建文件夹
    # 生产环境通常挂载到统一宿主机目录，如 /data/servers/logs/
    path: /data/servers/logs/${spring.application.name}
  level:
    root: info
    # 3. 业务包级别，设为 debug 才能在开发环境查看到详细链路和 SQL
    com.xf: debug
    # 4. 屏蔽 Spring 框架过细的启动日志，保持日志整洁
    org.springframework: warn

微服务快速集成

配置好公共配置后，我们在各个微服务的 bootstrap.yml 中直接引入即可：

yaml 复制代码 
spring:
  config:
    import: #指定加载配置的方式以及文件
      - nacos:common-config.yaml

五、进阶-性能优化与多线程避坑

在真实的生产环境中，仅仅让日志打印出来是不够的，我们还要让它"跑得久、跑得稳"。

问题：【踩坑】多线程下的 MDC 丢失

现象 ：MDC（Mapped Diagnostic Context）本质是基于 ThreadLocal 实现的。如果你在代码中使用了 @Async 异步方法或自定义线程池，你会惊讶地发现：子线程里的日志丢了 traceId！
解决方案 ：利用 Spring 提供的 TaskDecorator 接口，在任务切换线程时手动进行上下文"搬运"。

定义装饰器 MdcTaskDecorator

代码位置 ：cloud-common 模块 -> com.xf.cloudcommon.config.MdcTaskDecorator

java 复制代码 
public class MdcTaskDecorator implements TaskDecorator {
    @Override
    public Runnable decorate(Runnable runnable) {
        // 1. 抓取主线程的 MDC 上下文
        Map<String, String> contextMap = MDC.getCopyOfContextMap();
        return () -> {
            try {
                // 2. 搬运到子线程
                if (contextMap != null) MDC.setContextMap(contextMap);
                runnable.run();
            } finally {
                // 3. 必须清理，防止线程复用污染
                MDC.clear();
            }
        };
    }
}

配置线程池并注入装饰器

代码位置 ：cloud-common 模块 -> com.xf.cloudcommon.config.ThreadPoolConfig

java 复制代码 
@Configuration
@EnableAsync
public class ThreadPoolConfig {
    @Bean("taskExecutor")
    public Executor taskExecutor() {
        ThreadPoolTaskExecutor executor = new ThreadPoolTaskExecutor();
        // ... 其他常规配置
        // 核心：注入装饰器实现透传
        executor.setTaskDecorator(new MdcTaskDecorator());
        executor.initialize();
        return executor;
    }
}

性能优化：行号（%L）带来的开销

在网关这种超高并发场景下，日志格式中尽量不要包含 %L (报错行号) 和 %M (方法名)。
原理 ：日志框架为了获取这些动态信息，底层需要捕获当前线程的 堆栈轨迹（Stack Trace） 并在栈中进行昂贵的遍历。在高并发下，这笔 CPU 开销会显著降低系统的吞吐量。建议生产环境只保留 %logger 到类级别。

优雅停机：记录最后一条日志

由于我们采用了异步输出（AsyncAppender），如果不做特殊处理，在服务重启瞬间，缓冲区（Queue）里的日志可能会被直接丢弃。
建议 ：在 logback-spring.xml 中增加以下配置，让 Logback 在 JVM 关闭时能通过钩子确保缓冲区日志落盘：

xml 复制代码 
<shutdownHook class="ch.qos.logback.core.hook.DefaultShutdownHook"/>

扩展知识

架构对标：为什么 Gateway 需要额外处理？

很多开发者疑惑：既然 Netty 线程数少，性能不是应该更差吗？其实不然。我们需要深刻理解两者在处理高并发时的本质差异：

维度 业务服务 (Spring MVC) 网关 (Spring Cloud Gateway) 优势分析
底层核心 Tomcat / Jetty (基于 Servlet) Netty (基于 WebFlux) -
线程模型 阻塞式：一请求一线程。 非阻塞式：事件驱动（Event Loop）。 Netty 避免了成百上千个线程频繁调度的上下文切换开销。
线程配置 通常 200~500 个线程。 通常 = CPU 核心数 * 2。 极少数线程就能打满 CPU 性能，内存占用极低。
日志风险 慢日志仅导致单个线程不可用。 日志阻塞会直接拖垮核心 EventLoop 线程。 灾难性风险：一个 EventLoop 阻塞，数千个连接会同时卡死。
治理策略 侧重业务轨迹保留。 侧重降噪与非阻塞输出。 必须使用 AsyncAppender 保护系统的"金牌销售"（EventLoop）。

结论 ：在网关架构下，"少线程"意味着极致的并发处理能力，但它的容错率极低------绝对不能出现任何同步阻塞操作（如直接写磁盘日志）。

日志等级与优先级规则

在 Logback 或 SLF4J 中，日志等级有着严格的包含关系：

TRACE < DEBUG < INFO < WARN < ERROR

关键点：

  1. 向下包含 ：若级别设为 INFO，则 INFO、WARN、ERROR 的日志均会输出；DEBUG 和 TRACE 被丢弃。
  2. additivity (叠加属性) ：这是一个极易导致"日志双份打印"的配置。子 Logger 继承了父 Logger 的 Appender，若不设为 false，子 Logger 打印的内容会同时在 Root 预设的终端再次打印。

日志分级与 SQL 打印（重点注意）

容易被忽视的关键点

生产环境中，打印 SQL 是把双刃剑：

  • 强烈不建议配置 mybatis-plus.configuration.log-impl ：它是底层数据库驱动级别的输出，会绕过 Spring 日志体系，导致记录无法带上 TraceId。
  • 推荐配置 logging.level.<package>: debug ：通过 Logback 体系输出，不仅格式可控，还能享受 MDC 带来的 TraceId 追踪效果。

静态防御 vs 动态灵活：你应该把日志级别写在哪？

在微服务实战中，有一个常被忽略的"潜规则"：框架噪音（如 Netty/Nacos）建议死扣在 XML 里，而业务日志建议动态配置在 Nacos 里。

类别 建议位置 建议级别 理由 (防御性编程思维)
基础噪音 (Netty/Nacos) logback-spring.xml WARN 静态防御 ：防止全局 DEBUG 动态生效导致网关磁盘瞬间爆满挂掉。
业务代码 (com.xf) Nacos / YAML INFO (动态切 DEBUG) 动态追踪：线上查错最核心的抓手，需实现"即配即见"。
Spring 核心路由 Nacos / YAML INFO 按需开启：仅在怀疑路由配置出错时短时间开启，查完即关。

运维部署

Docker 部署与日志持久化

配置了精妙的日志策略，如果部署时没有做好"持久化挂载"，容器重启后所有日志都会化为乌有。

核心操作：目录映射（Volume）

无论你是使用原始 Docker 命令还是 Jenkins 自动化流水线，核心只有一句话：将容器内的日志目录映射到宿主机。

  • Docker 直接启动 ：在命令行中增加 -v 参数。

    bash 复制代码 
    docker run -d --name cloud-user \
  -v /data/servers/logs:/data/servers/logs \
  ... 镜像名

  • Jenkins 流水线集成 ：

    如果你之前看过我写的 《Jenkins 自动化部署架构实战》，现在只需要在流水线脚本（或配置界面）的第四步：远程部署配置中，在构建位置附加以下挂载命令即可：

    -v /data/servers/logs:/data/servers/logs

为什么要这么做？

  • 通过将所有服务的日志统一挂载到宿主机的 /data/servers/logs 下，不仅方便我们运维同学直接查阅，还为后续引入 ELK（Elasticsearch + Logstash + Kibana） 或 Filebeat 采集日志埋下了完美的伏笔。
  • 防止容器中大量的日志文件导致磁盘空间被填满，从而导致容器挂掉。
  • 防止容器重启时，所有日志会丢失。

效果演示

启动项目查看日志文件是否自动生成

进入linux服务器,查看陆路径：/data/servers/logs

进入网关日志文件夹

配置完成后，一次完整的全链路追踪效果如下：

  1. 网关访问 ：[Access] ... TraceId: a1b2c3d4
  2. 用户服务 ：[traceId:a1b2c3d4] [com.xf.user...] 查询用户信息成功
  3. 订单服务 ：[traceId:a1b2c3d4] [com.xf.order...] 创建订单

整条链路如同一根长线，将散落在各个微服务的散珠（日志）完美串联。

TIP

💡 排障小贴士与演进建议 ： 在当前的轻量级架构下，若请求跨越多个服务，排障时仍需根据同一个 TraceId 分别查阅各微服务的日志文件（利用 Linux 的 grep 指令可实现秒级定位）。

诚然，通过搭建 ELK (Elasticsearch, Logstash, Kibana) 可以实现日志的集中化检索与可视化。但 ELK 体系架构庞大、组件繁多，对服务器资源（内存/磁盘）有较高要求。可以视项目规模而定：对于绝大多数中小型项目，本方案提供的 TraceId 机制配合 Docker 日志挂载，已经能以极低的成本解决 95% 以上的排障痛点。与其盲目堆砌组件，不如选择最适合当下业务的性价比

总结

分布式日志治理不仅仅是技术实现，更是一种工程化的管理思维。通过对网关与业务服务物理层面的日志分离、基于 MDC 的链路标识、Nacos 的统一分发、多线程上下文的守护，以及宿主机目录的持久化挂载，我们才能真正在大规模集群中实现"运筹帷幄之中，决策千里之外"。

相关推荐
大傻^2 小时前
LangChain4j 记忆架构：ChatMemory、持久化与跨会话状态
java·人工智能·windows·架构·langchain4j
⑩-2 小时前
RabbitMQ与Kafka的区别？
分布式·kafka·rabbitmq
better_liang2 小时前
每日Java面试场景题知识点之-Spring Cloud微服务分布式事务解决方案
java·spring cloud·微服务·seata·面试题·分布式事务·tcc
Jackyzhe2 小时前
从零学习Kafka：副本机制
分布式·学习·kafka
Predestination王瀞潞2 小时前
3. JVM（Java Virtual Machine，Java 虚拟机）：从核心架构到运行机制的全方位剖析
java·jvm·架构
qingwufeiyang_5302 小时前
统一网关GateWay
linux·服务器·gateway
weixin_397578022 小时前
微服务 如何调试restful 接口
微服务
后季暖2 小时前
kafka优化
数据库·分布式·kafka
别催小唐敲代码2 小时前
前后端交互原理与架构全解
架构·状态模式·前后端
热门推荐
01GitHub 镜像站点02Qwen3.5 开源全解析：从 0.8B 到 397B，代际升级 + 全场景选型指南03OpenClaw 使用和管理 MCP 完全指南04UV安装并设置国内源05OpenClaw Control UI安全上下文访问配置06小黑课堂计算机二级WPSoffice题库软件下载安装教程（2026年3月最新版）07Claude Code + GLM4.7 避坑指南：解决 Unable to connect to Anthropic services08OpenClaw macOS 完整安装与本地模型配置教程（实战版）09本地部署 OpenClaw + DeepSeek-R1 完全指南10AI 编程三剑客：Spec-Kit、OpenSpec、Superpowers 深度对比与实战指南