文章目录一、开篇第26课留下的“盲区”二、分布式追踪理论基础2.1 Dapper论文的核心思想2.2 三大核心概念Trace、Segment、Span2.3 上下文传播跨服务追踪的核心三、SkyWalking架构深度剖析3.1 四层架构Probe → OAP → Storage → UI3.2 核心数据模型3.3 Java Agent的字节码增强原理四、SkyWalking部署实战4.1 Docker Quick Start部署4.2 验证部署五、Java Agent探针配置5.1 下载Agent5.2 核心配置项5.3 配置覆盖优先级5.4 Spring Boot应用的启动配置5.5 Gateway与OpenFeign的链路透传5.6 日志中注入TraceID六、调用链路分析与拓扑图实战6.1 验证链路数据6.2 拓扑图解读6.3 链路详情分析6.4 性能瓶颈排查实战6.5 日志与链路的联动七、生产采样策略与性能优化7.1 采样率配置7.2 OAP Server性能调优7.3 Agent性能优化7.4 SkyWalking与Micrometer Tracing的协同八、踩坑指南坑一Agent版本与OAP版本不匹配坑二Gateway自定义过滤器覆盖了sw8头坑三异步线程中链路断裂坑四采样率为0导致无数据坑五Elasticsearch存储空间快速增长坑六JDK 21下Agent兼容性问题九、课后作业十、下节预告《最新版 SpringCloud 2025 从入门到实战》系列课程导航适配版本Apache SkyWalking 10.4.0OAP UI Java Agent、Spring Boot 4.0.8、Spring Cloud 2025.1.3Oakwood、JDK 21课程定位监控追踪阶段进阶篇从分布式追踪理论到SkyWalking架构从探针配置到链路分析构建全链路可观测性能力一、开篇第26课留下的“盲区”第26课我们完成了PrometheusGrafana的指标监控体系。通过http_server_requests_seconds指标我们能看到service-order的P95延迟从50ms飙升到了3秒。但指标只告诉了你“慢了”没有告诉你“为什么慢”。是service-user的数据库查询慢了还是service-product的Feign调用超时了还是service-order自己的业务逻辑阻塞了Prometheus的指标是按服务聚合的——它知道每个服务各自的状态但不知道一个请求在服务之间的流转路径。链路追踪Distributed Tracing正是为解决这个问题而设计的。它为每个请求生成全局唯一的TraceId记录请求经过的每一个服务、每一次数据库查询、每一次RPC调用以及每一段的精确耗时。当请求变慢时通过链路追踪可以精确定位到是哪个服务、哪个方法、哪条SQL拖慢了整个请求。SkyWalking是目前国内微服务生态中应用最广泛的开源APMApplication Performance Management工具。与Zipkin、Jaeger等纯链路追踪工具不同SkyWalking在同一个平台内覆盖Tracing、Metrics、Logging、Profiling、Event五类遥测数据并提供零代码侵入的Java Agent探针非常适合Spring Cloud微服务架构的快速接入。本课将从分布式追踪的理论基础Dapper论文讲起深入SkyWalking的四层架构和字节码增强原理完成OAPUI部署和Java Agent探针配置实战微服务调用链路分析和拓扑图生成最后给出生产环境的采样策略和性能优化建议。二、分布式追踪理论基础2.1 Dapper论文的核心思想2010年Google发表了《Dapper, a Large-Scale Distributed Systems Tracing Infrastructure》论文奠定了分布式追踪的理论基础。今天所有的链路追踪系统——无论是SkyWalking、Zipkin还是Jaeger——其核心设计理念都可以追溯到这篇论文。Dapper论文开篇描述了一个典型的场景Google的一个搜索请求可能涉及数百个微服务、数千台机器。当用户说“搜索好慢”时你该从哪查起没有追踪系统你可能需要查几十台机器的日志。Dapper的目标非常明确性能分析和故障定位。论文提出了两个基本要求广泛的覆盖面——监控组件应作为基础组件提供对应用开发者尽可能透明低开销——监控系统本身对业务服务的性能影响必须降至最低。2.2 三大核心概念Trace、Segment、SpanDapper将一次请求划分为三个层次这一模型已成为所有链路追踪系统的基础Trace追踪表示一整条完整的调用链包含跨进程、跨线程的所有操作。全局唯一标识为TraceID贯穿请求的全链路。通过TraceID可以串联起跨服务、跨进程的所有操作还原完整的调用路径。Segment分段表示单个进程如一个JVM实例或线程内的所有操作集合包含若干个Span。Segment是SkyWalking的特有概念它比Zipkin/Jaeger的纯Span模型多了一层“进程级”的聚合。Span跨度表示一个具体的操作单元是Trace的最小执行单元。Span分为三种类型类型含义典型场景Entry Span入口Span是一个Segment的起点HTTP/RPC服务端入口、MQ消费者入口Local Span本地方法调用Service层方法、工具类方法Exit Span出口Span是对外部的调用HTTP/RPC客户端调用、数据库访问、MQ生产者每个Span包含以下核心属性属性含义SpanID单个Span的唯一标识单Trace内唯一ParentSpanID父Span的ID用于构建树形调用层级操作名标识Span的操作类型如GET /api/user起止时间戳记录操作的开始/结束时间计算耗时状态码标识操作的执行结果成功/失败/异常属性/标签键值对形式的元数据如HTTP URL、状态码、SQL语句2.3 上下文传播跨服务追踪的核心上下文传播是实现跨服务链路串联的核心技术难点。它的核心任务是将Trace上下文TraceID、SpanID、采样标记等在跨进程、跨服务、跨线程的调用中进行传递确保全链路的Span能被正确串联。在HTTP场景中上下文通过请求头传递。SkyWalking Java Agent会自动在Feign调用的请求头中注入sw8头下游服务的Agent解析该头并恢复Trace上下文从而将两个服务的Span关联到同一个Trace中。对于Spring Cloud Gateway流量经过SkyWalking Agent时会自动生成包含TraceID的请求头。在异步场景如MQ、线程池中上下文通过ThreadLocal快照传递。SkyWalking的Trace注解和ContextManager支持手动传递上下文也可以通过apm-toolkit-trace工具包提供的TraceContext在异步线程中恢复上下文。三、SkyWalking架构深度剖析3.1 四层架构Probe → OAP → Storage → UISkyWalking采用逻辑四层架构每一层职责清晰、可独立扩展┌──────────────────────────────────────────────────────────────┐ │ Probe探针层 │ │ Java Agent / Python Agent / Go Agent / Node.js Agent │ │ Service Mesh Receiver / eBPF / OpenTelemetry / Zipkin │ │ 职责采集数据通过gRPC/OTLP上报到OAP │ └──────────────────────────────┬───────────────────────────────┘ │ gRPC (11800) / HTTP (12800) ▼ ┌──────────────────────────────────────────────────────────────┐ │ OAPObservability Analysis Platform │ │ 接收 Trace/Metrics/Logs/Events │ │ OAL指标分析/ MALMeter分析/ LAL日志分析DSL流水线 │ │ 聚合 · 流式处理 · 告警 │ │ 职责数据接收、聚合计算、清洗分析、告警触发 │ └──────────────────────────────┬───────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────┐ │ Storage存储层 │ │ Elasticsearch / OpenSearch / BanyanDB / MySQL / H2 │ │ 职责持久化存储链路数据、指标数据、日志数据 │ └──────────────────────────────┬───────────────────────────────┘ │ ▼ ┌──────────────────────────────────────────────────────────────┐ │ UI可视化层 │ │ Booster UI10.x / Horizon UI11.x │ │ 拓扑 · Trace · 指标 · 日志 · Profiling │ │ 职责Web控制台查看拓扑图、链路详情、性能指标 │ └──────────────────────────────────────────────────────────────┘Probe探针层SkyWalking的核心优势在于零代码侵入。Java Agent通过-javaagent参数挂载不需要改一行业务代码自动拦截Spring MVC、OpenFeign、Dubbo、MySQL、Redis、MQ等中间件操作采集链路、耗时、异常和JVM指标异步上报数据。OAP平台后端是架构重心。它接收Trace/Metrics/Logs/Events数据经OAL指标分析、MALMeter分析、LAL日志分析等DSL流水线生成实体与指标。10.4版本起MAL/LAL走V2引擎指标聚合与持久化worker池合并为BatchQueue调度。Storage存储层是插件化的。生产环境常见Elasticsearch/OpenSearch或BanyanDBSkyWalking自研时序追踪存储。UI可视化层在10.x版本中使用Booster UI11.x版本中已正式切换为Horizon UI。3.2 核心数据模型SkyWalking用Service → Service Instance → Endpoint → Process四层结构描述观测对象层级含义示例Service一组提供相同行为的工作负载service-user服务Service InstanceService下的单个实例一个JVM进程host1service-user:8081EndpointHTTP URI或gRPC方法签名等入口路径GET /api/user/{id}Process进程级信息进程ID、OS信息跨K8s、Mesh、OS等多Layer时可通过Service Hierarchy关联同一逻辑服务在不同层级的视图。3.3 Java Agent的字节码增强原理SkyWalking Java Agent采用字节码增强Bytecode Enhancement技术实现无侵入埋点。其核心机制是第一层JVM Instrumentation API。Java Agent通过premain方法在应用启动时注册ClassFileTransformer。当JVM加载每个类时Transformer会拦截类字节码根据SkyWalking的插件规则判断是否需要增强。第二层插件化拦截。SkyWalking内置了数百个插件覆盖Spring MVC、OpenFeign、MySQL、Redis、RabbitMQ、Kafka等主流框架。每个插件定义了需要拦截的类和方法以及增强后的逻辑——在方法执行前创建Span在方法执行后记录耗时和结果。第三层上下文传播。增强后的代码在Entry Span创建时从请求头中提取Trace上下文在Exit Span创建时向请求头中注入Trace上下文实现跨服务的链路串联。性能开销SkyWalking Agent对应用的性能影响通常小于3%支持通过采样率进一步降低开销。四、SkyWalking部署实战4.1 Docker Quick Start部署SkyWalking提供了官方一键部署脚本交互式选择Elasticsearch或BanyanDB作为存储# Linux / macOS / WSLbash(curl-sSLhttps://skywalking.apache.org/quickstart-docker.sh)脚本会启动三个容器容器端口职责skywalking-oap11800gRPC、12800HTTPOAP平台后端skywalking-ui8080Web控制台elasticsearch9200数据存储手动部署方式推荐生产环境# 1. 启动Elasticsearchdockerrun-d--nameelasticsearch\-p9200:9200\-ediscovery.typesingle-node\-eES_JAVA_OPTS-Xms2g -Xmx2g\elasticsearch:8.15.0# 2. 启动OAP Server指定ES存储dockerrun-d--nameoap\-p11800:11800-p12800:12800\-eSW_STORAGEelasticsearch\-eSW_STORAGE_ES_CLUSTER_NODESelasticsearch:9200\apache/skywalking-oap-server:10.4.0# 3. 启动UIdockerrun-d--nameui\-p8080:8080\-eSW_OAP_ADDRESShttp://oap:12800\apache/skywalking-ui:10.4.0端口说明OAP默认gRPC接收端口为11800HTTP为12800UI默认端口为8080。4.2 验证部署访问http://localhost:8080应看到SkyWalking UI界面。首次访问时服务列表为空——需要应用挂载Agent并上报数据后才会显示。五、Java Agent探针配置5.1 下载Agent从SkyWalking官网下载Java Agent包版本必须与OAP Server保持一致wgethttps://archive.apache.org/dist/skywalking/java-agent/9.4.0/apache-skywalking-java-agent-9.4.0.tgztar-zxvfapache-skywalking-java-agent-9.4.0.tgz解压后的目录结构skywalking-agent/ ├── config/ │ └── agent.config # 主配置文件 ├── plugins/ # 默认启用的插件 ├── optional-plugins/ # 可选插件需手动移入plugins/ └── skywalking-agent.jar # Agent 主jar包5.2 核心配置项编辑config/agent.config关键配置如下# 服务名称在UI中显示 agent.service_name${SW_AGENT_NAME:Your_ApplicationName} # OAP服务器地址gRPC端口 collector.backend_service${SW_AGENT_COLLECTOR_BACKEND_SERVICES:127.0.0.1:11800} # 采样率每3秒采集的请求数-1表示全量采集默认-1 agent.sample_n_per_3_secs${SW_AGENT_SAMPLE:-1} # 数据隔离命名空间 agent.namespace${SW_AGENT_NAMESPACE:} # 实例标识默认自动生成 agent.instance_name${SW_AGENT_INSTANCE_NAME:}5.3 配置覆盖优先级SkyWalking支持多种配置方式优先级从高到低依次为优先级配置方式示例1最高探针配置jar后加参数-javaagent:agent.jaragent.service_nameorder-service2系统配置-D参数-Dskywalking.agent.service_nameorder-service3系统环境变量SW_AGENT_NAMEorder-service4最低配置文件中的值agent.config中的Your_ApplicationName最佳实践推荐通过环境变量配置参数便于不同环境切换exportSW_AGENT_NAMEservice-userexportSW_AGENT_COLLECTOR_BACKEND_SERVICESoap:11800java-javaagent:/agent/skywalking-agent.jar-jarservice-user.jar5.4 Spring Boot应用的启动配置在microservice-platform的每个服务中通过JVM参数挂载Agent# service-user 启动命令java-javaagent:/opt/skywalking-agent/skywalking-agent.jar\-Dskywalking.agent.service_nameservice-user\-Dskywalking.collector.backend_service192.168.1.100:11800\-jarservice-user-1.0.0.jarMaven插件方式适合开发环境plugingroupIdorg.springframework.boot/groupIdartifactIdspring-boot-maven-plugin/artifactIdconfigurationjvmArguments-javaagent:/opt/skywalking-agent/skywalking-agent.jar -Dskywalking.agent.service_name${project.artifactId} -Dskywalking.collector.backend_service127.0.0.1:11800/jvmArguments/configuration/plugin5.5 Gateway与OpenFeign的链路透传SkyWalking Agent原生支持Spring Cloud Gateway和OpenFeign。Gateway的流量经过Agent时会自动生成包含TraceID的请求头并在调用链中标记熔断器触发事件。OpenFeign的调用会被自动增强在请求头中注入sw8头下游服务解析后恢复Trace上下文。需要在Gateway模块额外添加的依赖确保Gateway的链路透传正确dependencygroupIdorg.apache.skywalking/groupIdartifactIdapm-toolkit-trace/artifactIdversion9.4.0/version/dependency踩坑提示如果Gateway使用了自定义的GlobalFilter修改了请求头可能会覆盖SkyWalking注入的sw8头导致链路断裂。解决方案在自定义过滤器中将sw8头添加到白名单中不做修改。5.6 日志中注入TraceID在logback-spring.xml中配置TraceID输出pattern%d{yyyy-MM-dd HH:mm:ss} [%X{tid}] [%thread] %-5level %logger{36} - %msg%n/patternSkyWalking Agent会自动将TraceID注入到MDC的tid键中。配置后日志中将显示类似2026-09-13 10:30:15 [a1b2c3d4e5f6.1234567890.123456.01] [http-nio-8081-exec-1] INFO c.e.m.u.controller.UserController - 查询用户: id1通过TraceID可以在ELK中串联起该请求在所有服务中的日志。六、调用链路分析与拓扑图实战6.1 验证链路数据启动所有服务挂载Agent后访问SkyWalking UIhttp://localhost:8080服务列表左侧菜单中应显示service-user、service-order、service-product、gateway-server四个服务拓扑图导航至Topology页面应显示服务间的调用关系。外部请求 → Gateway → service-order → service-user / service-product链路追踪导航至Trace页面应能看到最近的请求链路6.2 拓扑图解读SkyWalking自动采集服务间的调用数据生成实时拓扑图展示服务节点微服务、数据库、消息队列、调用方向箭头表示请求流向和调用指标响应时间、错误率。拓扑图的关键作用发现隐藏依赖某版本发布后拓扑图可能显示order-service对perf-service的调用延迟突然升高定位故障传播链路当服务雪崩时拓扑图能一眼看出故障从哪个服务开始、传播到了哪些服务验证架构变更效果例如将同步调用改为异步后拓扑图中的实线箭头变为虚线箭头依赖矩阵拓扑图下方可以切换到依赖矩阵视图以表格形式量化服务间依赖强度调用方被调用方调用次数/分钟平均延迟order-serviceuser-service12045msorder-serviceproduct-service24012msorder-servicemysql3608ms6.3 链路详情分析点击拓扑图中的某条调用边或进入Trace页面查看单条链路的详情。SkyWalking的链路详情页面以火焰图和调用树两种视图展示调用树视图Trace: a1b2c3d4e5f6 (总耗时: 523ms) ├── [Gateway] GET /api/order/1 (523ms) │ ├── [service-order] OrderController.getOrder (515ms) │ │ ├── [service-order] OrderService.query (510ms) │ │ │ ├── [service-user] UserClient.getUserById (320ms) ← 慢占比61% │ │ │ │ └── [service-user] UserController.getUserById (310ms) │ │ │ │ └── [MySQL] SELECT * FROM user WHERE id1 (295ms) ← 慢SQL │ │ │ ├── [service-product] ProductClient.getProductById (150ms) │ │ │ │ └── [service-product] ProductController.getProductById (145ms) │ │ │ └── [service-order] OrderService.assemble (35ms) │ │ └── [service-order] OrderController.response (5ms) │ └── [Gateway] Response (523ms)从调用树中可以精确定位瓶颈总耗时523ms其中service-user调用耗时320ms占比61%service-user的耗时主要来自MySQL查询295ms定位到具体问题service-user的数据库查询缺少索引导致全表扫描关键指标自身耗时Self TimeSpan的总耗时减去子Span的耗时。如果某个Span的Self Time很高说明瓶颈在该Span自身的代码逻辑中异常标记发生异常的Span会以红色高亮显示点击可查看异常堆栈SQL记录数据库查询的SQL语句会被记录便于分析慢SQL6.4 性能瓶颈排查实战场景一Feign调用超时。在调用树中UserClient.getUserById的耗时异常高如3秒。展开该Span可以看到SkyWalking记录的HTTP请求详情——请求URL、状态码、响应时间。对比第15课配置的Feign超时时间read-timeout确认是否为下游服务响应慢导致的超时。场景二数据库慢查询。展开MySQLSpan可以看到执行的SQL语句和耗时。SkyWalking自动记录SQL语句需要开启plugin.jdbc.trace_sql_parameterstrue配置。场景三Gateway转发慢。在调用树中Gateway的Span耗时高但下游服务的Span耗时正常。这说明瓶颈在Gateway自身的处理逻辑如鉴权过滤器、限流过滤器中。6.5 日志与链路的联动SkyWalking支持将TraceID注入到日志中通过日志中的TraceID可以在ELK中检索到该请求在所有服务中的完整日志。当某个接口超时告警时运维人员可以直接通过TraceID跳转到关联日志查看当时数据库连接池的状态或异常堆栈。七、生产采样策略与性能优化7.1 采样率配置SkyWalking的采样率通过agent.sample_n_per_3_secs配置含义是每3秒采集的请求数配置值含义适用场景-1全量采集开发/测试环境0不采集关闭Agent100每3秒采集100个请求生产环境中等流量10每3秒采集10个请求生产环境高流量生产建议核心服务支付、订单使用较高采样率100-500非核心服务日志上报、推荐使用较低采样率10-50。全量采集在生产环境可能导致OAP和ES的存储压力过大。7.2 OAP Server性能调优OAP Server的JVM参数需要根据数据量调整# OAP Server JVM 参数SW_JAVA_OPTS-Xms4g -Xmx4g -XX:MetaspaceSize256m存储层优化Elasticsearch集群建议至少3节点每个节点8核16G配置ES的index.refresh_interval为30s而非默认的1s减少写入压力定期清理过期索引OAP默认保留7天数据可通过SW_CORE_DATA_KEEPER_EXECUTE_PERIOD调整7.3 Agent性能优化如果发现Agent对应用性能影响较大超过5%可以通过以下方式优化降低采样率从-1调整为100或更低禁用不必要的插件将plugins/目录下不需要的插件移出如kafka-plugin.jar、rocketmq-plugin.jar关闭SQL参数记录设置plugin.jdbc.trace_sql_parametersfalse调整上报批大小增加agent.buffer.channel_size和agent.buffer.buffer_size减少网络请求次数7.4 SkyWalking与Micrometer Tracing的协同SkyWalking的Agent与Spring Boot Actuator的Micrometer Tracing可以共存但需要注意SkyWalking Agent负责链路追踪Trace/Span通过字节码增强实现Micrometer Tracing负责生成日志中的TraceID/SpanID通过Spring Boot的自动配置实现两者的TraceID是独立的——SkyWalking的TraceID存储在sw8头中Micrometer的TraceID存储在traceparent头中。如果需要统一可以通过SkyWalking的apm-toolkit-trace工具包将SkyWalking的TraceID注入到MDC中。八、踩坑指南坑一Agent版本与OAP版本不匹配现象应用启动时报The OAP version is not compatible或UI中看不到数据。原因Java Agent与OAP Server的版本不一致。SkyWalking对版本兼容性要求严格。解决确保Agent和OAP的主版本号一致。例如OAP使用10.4.0Agent也应使用9.4.0Java Agent的版本号与OAP版本号不完全对应需要查看官方兼容性矩阵。坑二Gateway自定义过滤器覆盖了sw8头现象Gateway的链路正常但下游服务的链路断裂——下游服务的TraceID与Gateway的TraceID不同。原因Gateway的自定义GlobalFilter在修改请求头时覆盖了SkyWalking注入的sw8头。解决在自定义过滤器中对sw8头做白名单处理——读取但不对其进行修改。或者使用ServerHttpRequest.mutate()时保留原有的sw8头。坑三异步线程中链路断裂现象Async方法或线程池中的任务其Span的TraceID与父线程不同导致链路断裂。原因SkyWalking的Trace上下文存储在ThreadLocal中异步线程无法访问父线程的ThreadLocal。解决使用apm-toolkit-trace工具包中的TraceContext手动传递上下文AsyncpublicvoidasyncMethod(){// 在异步方法中手动恢复上下文// 或者使用 Trace 注解}或者使用ContextManager在异步任务提交前捕获上下文在任务执行时恢复。坑四采样率为0导致无数据现象应用挂载了Agent但UI中完全看不到数据。原因agent.sample_n_per_3_secs被设置为0不采集。解决检查agent.config中的agent.sample_n_per_3_secs确保不是0。生产环境建议设置为100或更高。坑五Elasticsearch存储空间快速增长现象ES磁盘使用量快速增长几天内占满磁盘。原因默认保留7天数据且采样率为全量-1。在高流量场景下7天的链路数据可能达到数百GB。解决降低采样率缩短数据保留时间通过SW_CORE_DATA_KEEPER_EXECUTE_PERIOD配置定期清理过期索引。坑六JDK 21下Agent兼容性问题现象JDK 21环境下Agent启动报错提示字节码增强失败。原因SkyWalking Java Agent的字节码增强在JDK 21下可能遇到UnsupportedOperationException因为JDK 21对Instrumentation API的某些方法有限制。解决确保使用SkyWalking Java Agent 9.4.0或更高版本这些版本已经适配了JDK 21。同时在启动参数中添加--add-opens java.base/java.langALL-UNNAMED。九、课后作业作业一使用Docker部署SkyWalkingOAP UI Elasticsearch验证UI可正常访问。记录OAP的gRPC端口和HTTP端口。作业二为service-user、service-order、service-product、gateway-server四个服务挂载SkyWalking Java Agent。通过环境变量配置SW_AGENT_NAME和SW_AGENT_COLLECTOR_BACKEND_SERVICES。验证UI中四个服务均正常显示。作业三发起一次完整的下单请求通过Gateway → service-order → service-user service-product在SkyWalking UI中查看完整的调用链路。记录每个Span的耗时找出耗时最高的三个Span。作业四在service-user的getUserById方法中添加Thread.sleep(2000)重新发起请求通过链路详情验证能否精确定位到service-user的MySQL查询为瓶颈。作业五进阶配置plugin.jdbc.trace_sql_parameterstrue重新发起请求验证链路详情中是否记录了完整的SQL语句和参数。分析SQL执行计划确认是否存在索引缺失问题。十、下节预告第28课将进入统一日志收集、ELK搭建 线上问题排查体系。内容包括日志规范与分级、Logback配置、ELKElasticsearch Logstash Kibana搭建、日志检索、链路ID追踪和线上报错快速定位。本课完成了链路追踪Tracing的完整链路第28课将进入日志Logging领域——指标告诉你“系统状态如何”链路告诉你“请求经过了哪些服务”日志告诉你“系统在某个时刻发生了什么”。三者结合构成完整的可观测性体系。通过SkyWalking的TraceID与ELK日志的联动可以实现“一键从链路跳转到日志”的高效排查体验。《最新版 SpringCloud 2025 从入门到实战》系列课程导航去订阅第一部分微服务前置基础 新版环境搭建第1-5课第二部分注册中心核心Nacos 最新版第6-9课第三部分配置中心核心Nacos配置中心第10-12课第四部分服务通信核心OpenFeign LoadBalancer第13-16课第五部分网关核心SpringCloud Gateway 新版第17-20课第六部分熔断、限流、降级Sentinel 新版第21-24课第七部分微服务监控、链路追踪、日志体系第25-28课第八部分微服务高阶特性 分布式核心能力第29-31课第九部分企业级完整项目实战 架构复盘第32-35课