Spring Cloud 服务监控 - Sleuth + Zipkin 全链路追踪实战

一、为何需要全链路追踪？

在微服务架构中，用户请求通常涉及多个服务的交互（如订单→支付→库存）。这使得性能瓶颈和故障排查变得更加复杂。传统的日志分析面临两大核心挑战：

• 性能瓶颈模糊：当响应延迟增加时，如何快速判断是数据库、RPC调用还是消息队列引起的问题？

• 异常传播失焦：错误在服务间传递，日志分散，如何准确追踪和还原故障链路？

全链路追踪三大阶段解决上述微服务观测断层问题，具体如下：

1、全流程追踪：从请求入口生成全局唯一标识符，自动串联跨服务调用链，消除服务间协作黑箱。

2、细粒度分析：捕获每个服务节点的关键操作（如数据库查询、API调用），记录操作耗时、状态与上下文标签。

3、智能定位：基于可视化拓扑图识别异常传播路径，利用耗时热力图快速锁定瓶颈节点。

本文基于 Spring Cloud Sleuth + Zipkin 构建全链路追踪体系，设计告警规则并优化性能，最终实现覆盖预防、定位与修复的企业级可观测能力。

二、技术原理与核心组件

2.1 分布式追踪原理

1. 核心概念
在分布式系统中，一次用户请求通常跨越多个微服务。全链路追踪引入以下概念标记请求完整周期：

全局标识符（Trace ID）

唯一标识整条请求链路，类似快递的运单号，它将多个服务的处理过程串联起来。

示例：订单ID（如7a3b8c）贯穿下单、支付、库存等环节。

操作单元记录（Span）

记录单个服务内的操作单元，类似分拣中心的处理记录。多个 Span 组成一个完整的 Trace。

Span 数据结构：

{"spanId": "1.1",//操作单元记录唯一标识。"service": "订单服务","startTime": "2023-08-20T14:23:01Z","duration": 1200,"tags": {"sql.query": "SELECT..."}
}

2. 上下文传递机制（0代码改造）
基于B3协议，支持如下三种典型场景，确保对业务代码的零代码改造：

HTTP调用：通过请求头自动透传标识符。

GET /payment HTTP/1.1  
X-B3-TraceId: 80f198ee56343ba8  
X-B3-SpanId: 05e3ac9a4f6e3b90

消息队列：通过消息属性传递上下文。

message.setHeader(“X-B3-TraceId”, traceId);
异步调用：通过线程上下文继承父Span。

CompletableFuture.runAsync(() -> {tracer.currentSpan().tag("asyncTask", "start");
}, traceableExecutor);

3. 调用链结构示例

graph TDA[Trace: 7a3b8c] --> B[Span: 1 (网关)]B --> C[Span: 1.1 (订单服务)]C --> D[Span: 1.1.1 (支付服务)]D --> E[Span: 1.1.1.1 (库存服务)]

一个Trace包含多个Span，形成树状结构。

通过以上方式，Trace ID和Span ID能够在服务之间跟踪请求流，实现跨服务的请求追踪。

2.2 追踪体系的核心组件

1.Spring Cloud Sleuth（生成数据）

Spring Cloud Sleuth 是一个分布式追踪工具，自动为每个请求生成并传递 Trace ID 和 Span ID，确保每个服务的请求都能参与到追踪中。

核心能力：

• 自动为 HTTP/RPC/MQ 等通信方式注入追踪标识，0代码改造。

• 支持异步调用上下文传递。

• 与 Spring Boot 无缝集成，配置即用。

性能损耗与优化：

• CPU开销：每个 Span 的创建与记录增加 1%~3% 的 CPU 负载。

• 优化建议：启用异步上报（如 Kafka）降低主线程开销。

2. Zipkin（数据可视化）
Zipkin是一款用于分布式追踪数据的可视化与分析工具，收集和展示来自 Sleuth 的链路数据。可视化请求在微服务中的流转过程，诊断性能瓶颈和潜在故障。

核心能力（视图功能）：

• 服务拓扑视图：动态展示服务间调用关系和依赖。

• 耗时火焰视图：直观呈现各 Span 耗时占比。

• 异常传播路径：一键回溯完整调用链。

可视化操作：
1.查看请求链路：进入 Zipkin 的 UI 界面，输入 Trace ID，查看完整的请求链路。

2.延迟分析：在 Zipkin 中查看各个服务的响应时间，找出请求处理最慢的服务。

3.服务依赖关系：通过 Zipkin 的服务依赖图，展示各服务间的调用关系，分析系统的可靠性和稳定性。

性能损耗：

• 网络开销：每条 Trace 数据约 100~200 字节，可通过采样率控制（如 10%）减少传输量。

• 存储开销：每条 Trace 占用 1~2KB 存储空间，支持 Elasticsearch 索引优化与 TTL 策略。

通过结合 Spring Cloud Sleuth 和 Zipkin，我们可以实现从请求生成到可视化展示的全链路追踪方案。

3.追踪体系性能优化实践

• 采样率控制：根据业务需求动态调整采样率（如生产环境 1%，测试环境 100%）。

• 异步上报：使用 Kafka 等消息队列解耦数据上报与业务逻辑。

• 存储优化：配置 Elasticsearch 索引分片与 TTL 策略，平衡查询性能与存储成本。

2.3 全链路解决方案全景图

通过Spring Cloud Sleuth生成链路元数据，结合Zipkin进行可视化分析，实现“埋点 → 收集 → 存储 → 展示→ 告警”的完整监控闭环。

全链路追踪体系全景图
在这里插入图片描述

配图解析：

1. 业务系统层

• 真实微服务调用场景，涵盖HTTP / MQ / RPC三种典型通信方式。

• 每个箭头标注关键动作（如“传递TraceID”），强调TraceID / Span上下文传递机制。

2. 监控体系层

体现数据从生成到展示的全流程，Sleuth 负责生成链路数据，Zipkin 负责聚合与可视化。

• 数据生成：各服务通过Sleuth自动埋点，生成Span数据。

• 数据传输：支持HTTP 同步上报或Kafka 异步传输。

• 存储分析：Zipkin Server对接Elasticsearch，实现持久化存储。

• 可视化：Zipkin UI提供拓扑图 / 延迟热力图等核心分析功能。

• 监控扩展：与Prometheus集成，实现指标告警。

三、全链路追踪技术实现案例

以下是 Sleuth + Zipkin 全链路追踪的完整示例。从零开始实现和验证 ：

3.1 环境准备

开发工具

• JDK 17+

• Maven 3.6+

• Docker（用于启动 Zipkin）

创建两个 Spring Boot 服务

• order-service（端口：8080）

• payment-service（端口：8081）

3.2 完整实现步骤

1）添加依赖（pom.xml）

添加 sleuth 依赖和zipkin 依赖。

<!-- 两个服务的公共依赖 -->
<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-starter-sleuth</artifactId>
</dependency>
<dependency><groupId>org.springframework.cloud</groupId><artifactId>spring-cloud-sleuth-zipkin</artifactId>
</dependency>
<dependency><groupId>org.springframework.boot</groupId><artifactId>spring-boot-starter-web</artifactId>
</dependency>

2）配置应用（application.yml）

order-service 配置
配置zipkin 地址和 sleuth 采样率等。

# order-service 配置
server:port: 8080
spring:application:name: order-servicezipkin:base-url: http://localhost:9411  # Zipkin服务器地址sleuth:sampler:probability: 1.0  # 设置追踪采样率，1.0表示追踪所有请求。采样率100%(开发环境)

payment-service 配置server:port: 8081
spring:application:name: payment-servicezipkin:base-url: http://localhost:9411sleuth:sampler:probability: 1.0

3）编写业务代码

OrderController.java（订单服务）

sleuth 和zipkin 对业务代码 0侵入。

@RestController
public class OrderController {private final RestTemplate restTemplate;public OrderController(RestTemplateBuilder builder) {this.restTemplate = builder.build();}@GetMapping("/order")public String createOrder() {// Sleuth会自动传递TraceID到下游服务String paymentResult = restTemplate.getForObject("http://localhost:8081/payment", String.class);return "Order created! " + paymentResult;}
}

PaymentController.java（支付服务）

@RestController
public class PaymentController {@GetMapping("/payment")public String processPayment() {// 模拟业务处理耗时try { Thread.sleep(500); } catch (InterruptedException e) {}return "Payment processed!";}
}

零代码改造：无需修改业务逻辑，Sleuth 自动完成追踪数据的生成与传递。

4）启动 Zipkin 服务

# 使用 Docker 启动 Zipkin
docker run -d -p 9411:9411 openzipkin/zipkin
访问地址：http://localhost:9411

3.3 验证追踪效果

1）触发请求

curl http://localhost:8080/order

2）查看日志输出

order-service 日志：

2025-03-01 14:20:35.678 INFO [order-service,80f198ee56343ba8,05e3ac9a4f6e3b90] 创建订单请求

payment-service 日志：

2025-03-01 14:20:36.123 INFO [payment-service,80f198ee56343ba8,9c2d7e8a4f6e3b91] 处理支付请求

解析：

INFO 内容 ：[应用名 | TraceID | SpanID]

重点：日志中的TraceID相同（80f198ee56343ba8），证明链路关联成功。

3）Zipkin 界面分析

• 访问http://localhost:9411

• 点击“Run Query”查看最新追踪记录

• 点击Trace详情查看：

时间轴：可视化展示各 Span 耗时

元数据：包含 HTTP 方法、路径等详细信息

3.4 高级功能扩展

1. 自定义 Span 标签

代码侵入：手动获取当前 Span 并添加自定义标签或事件。

@GetMapping("/payment")
public String processPayment() {// 手动添加自定义标签Span span = Tracer.currentSpan();span.tag("payment.method", "credit_card");span.event("Payment processing started");// ...业务逻辑...return "Payment success";
}

使用场景：

• 添加业务相关的标签（如支付方式、用户ID）

• 记录关键事件（如“支付处理开始”）

2. 异步消息追踪（RabbitMQ 示例）

发送端

代码侵入：手动设置消息头中的 Trace ID。

@Autowired private RabbitTemplate rabbitTemplate;public void sendMessage() {Message message = MessageBuilder.withPayload("订单支付成功").setHeader("X-B3-TraceId", currentTraceId) // 手动传递 TraceID.build();rabbitTemplate.send("exchange", "routingKey", message);
}

使用场景：

• 确保消息队列中的 Trace ID 能够正确传递到下游服务。

接收端

代码侵入：手动从消息头中提取 Trace ID 并记录日志。

@RabbitListener(queues = "queue")
public void handleMessage(@Header("X-B3-TraceId") String traceId) {log.info("接收消息，TraceID: {}", traceId);
}

使用场景：

• 在日志中记录 Trace ID，便于后续排查问题。

3. 生产环境配置建议

spring:zipkin:sender:type: kafka  # 使用异步上报service:name: order-service-prodsleuth:sampler:probability: 0.1  # 生产环境采样率 10%propagation-keys: userId,requestId  # 自定义传播字段

3.5 常见问题排查

在这里插入图片描述

3.6 总结

1.无侵入场景

• HTTP、MQ、RPC 的默认追踪功能。

• 异步调用的上下文传递。

2.代码侵入场景

• 自定义 Span 标签。

• 手动传递消息队列中的 Trace ID。

• 记录自定义日志或事件。

侵入性代码说明：增强追踪数据的丰富性和灵活性。侵入程度较低，通常只需在关键节点添加少量代码即可。

3.最佳实践建议

• 优先使用无侵入功能：

对于大多数场景，Sleuth 的默认功能已足够，无需修改业务代码。

• 按需添加侵入性代码：

在需要记录业务关键信息或特殊场景时，才添加自定义标签或手动传递 Trace ID。

• 保持代码简洁：

将追踪相关的代码封装到工具类或切面中，避免分散在业务逻辑中。

通过本示例，你已经实现了：

  • 分布式追踪基础功能：自动生成和传递 TraceID。

  • 可视化分析能力：通过 Zipkin 查看完整链路。

  • 生产级扩展方案：异步上报与自定义标签。

四、生产级监控方案：告警规则与性能调优

为保证微服务系统生产环境稳定运行，如何利用追踪数据进行监控和性能调优是终极目的。

Prometheus 是监控系统的核心组件，负责采集指标数据并评估告警规则。

Alertmanager 负责接收 Prometheus 触发的告警，并根据路由规则分发到不同的接收器。

4.1 告警规则设计：构建主动防御体系

1.告警设计原则
在这里插入图片描述

2.典型告警规则实现

告警规则配置在 Prometheus 的alert.rules文件中。

例1：高延迟告警

- alert: APIHighLatencyexpr: >-histogram_quantile(0.95, rate(zipkin_latency_seconds_bucket{service="payment-service",http_method="POST"}[5m])) > 1  # 阈值1秒for: 10m  # 持续10分钟触发labels:severity: S1annotations:summary: "支付接口P95延迟超1秒 ({{ $value }}s)"description: "实例: {{ $labels.instance }}, TraceID: {{ $labels.traceId }}"

参数解析：

• histogram_quantile(0.95)：计算95%请求的延迟分布。

• rate(…[5m])：统计5分钟内的速率变化。

• http_method=“POST”：针对特定接口过滤。

例2：错误率告警（Zipkin数据源）

- alert: PaymentErrorSpikeexpr: >-increase(zipkin_errors_total{service="payment-service",status=~"5.."}[1m]) > 10labels:severity: S2annotations:runbook: "http://wiki/支付故障处理手册"

3. 告警处理流程

告警处理流程：

participant Z as Zipkin
participant P as Prometheus
participant A as Alertmanager
participant N as 通知渠道Z->>P: 暴露/metrics端点
P->>A: 每15s拉取指标
A->>A: 持续评估规则
critical->>N: 电话/短信告警
major->>N: 企业微信通知
minor->>N: 邮件周知

流程解析如下：

1.数据采集：Zipkin 暴露/metrics端点，Prometheus 定期拉取数据。

2.规则评估：Prometheus 根据配置的告警规则评估指标数据。

3.告警触发：规则条件满足时，Prometheus 发送告警到 Alertmanager。

4.通知分发：Alertmanager 根据告警级别（如critical、major、minor）发送通知到不同渠道（如电话、企业微信、邮件）。

4.2 性能调优：数据驱动的优化实践

1.优化方法论

A[发现异常指标] --> B{定位问题边界}
B -->|服务内部| C[代码/DB/缓存分析]
B -->|服务间| D[调用链路优化]
C --> E[实施解决方案]
D --> E
E --> F[验证效果]

2.性能调优实战案例

问题现象
• 订单创建接口P99 延迟达2.3 秒

• 用户投诉高峰期下单失败率升高

排查过程如下：

在Zipkin查询界面使用条件过滤。

1. 筛选 Trace 进行分析

traceDuration > 2000 && http.path="/orders"

2. 耗时分布分析

在这里插入图片描述

3.代码级诊断

// 优化前（伪代码）
public Order createOrder(OrderRequest request) {// 每次请求都进行风控检查RiskCheckResult risk = riskService.check(request); if(risk.isHighRisk()) throw new RiskException();// 逐条锁定库存request.getItems().forEach(item -> stockService.lock(item.getSku(), item.getQty()));
}

4.优化方案

• 风控检查缓存

@Cacheable(value = "riskCache", key = "#userId + ':' + #totalAmount",ttl = 30 * 60) // 缓存30分钟
public RiskCheckResult checkRisk(Long userId, BigDecimal amount) {return riskService.check(userId, amount);
}

• 批量库存操作

// 批量锁定接口
@PostMapping("/stocks/batch-lock")
public BatchResult batchLock(@RequestBody List<LockRequest> requests) {return stockService.batchLock(requests);
}

4.3 总结

1.告警规则设计：

• 通过 Prometheus 配置高延迟、错误率等告警规则，构建主动防御体系。

• 告警信息应包含 Trace ID、服务名称等上下文，便于快速定位问题。

2.性能调优实践：

• 基于追踪数据（如 Zipkin 火焰图）定位性能瓶颈。

• 通过缓存、批量处理等优化手段提升系统性能。

注意事项

1.告警规则优化：

• 根据业务需求调整告警阈值和持续时间，避免误报或漏报。

• 定期审查告警规则，确保其与当前系统状态匹配。

2.性能调优策略：

• 优先优化高频、高耗时的操作（如数据库查询、RPC 调用）。

• 通过 A/B 测试或灰度发布验证优化效果，避免引入新问题。

3.监控数据关联：

• 通过 Trace ID 串联日志、指标与追踪数据，实现全链路分析。

• 使用 Grafana 等工具统一展示监控数据，提升排查效率。

五、构建完整可观测体系

5.1 分层架构设计方案

数据采集层A[Sleuth] -->|生成Trace| B[Zipkin]C[Prometheus] -->|采集指标| D[应用Metrics]E[Filebeat] -->|收集日志| F[ELK]数据聚合层B --> G[可观测平台]D --> GF --> G应用层G --> H[统一看板]G --> I[智能告警]G --> J[根因分析]

各层核心组件解析：
在这里插入图片描述

5.2 分层方案集成实施

如下是可观测体系分层方案集成实施要点：

1. 数据关联

通过TraceID串联日志、指标、追踪数据。# Logback配置（关联TraceID与日志）
<pattern>%d{yyyy-MM-dd HH:mm:ss} [%X{traceId},%X{spanId}] %msg%n
</pattern># Grafana配置（跨数据源查询）
datasources:- name: Zipkintype: zipkinurl: http://zipkin:9411- name: Prometheustype: prometheusurl: http://prometheus:9090

2. 智能分析

基于历史数据训练异常检测模型。

# 异常检测模型（伪代码）
def detect_anomaly(traces):baseline = load_historical_data()current = calculate_p99_latency(traces)if current > baseline * 1.5:trigger_alert("潜在性能劣化")

3. 自动化治理

监控告警触发扩容方案

sequenceDiagramPrometheus->>Alertmanager: 触发扩容告警Alertmanager->>Kubernetes: 调用Scale APIKubernetes->>Deployment: 副本数+2Deployment->>Pod: 创建新实例

Kubernetes 原生 HPA 与 监控告警触发扩容方案对比
在这里插入图片描述

注：本方案是对 Kubernetes 原生的 HPA（Horizontal Pod Autoscaler）的补充。

5.3 监控告警触发扩容方案实施建议

1.方案的核心优势

优势1：应对非线性突发流量

graph LRA[促销活动开始] -->|用户流量暴涨10倍| B[接口延迟 > 2s]B --> C[Prometheus触发告警]C --> D[立即扩容副本到10倍]D --> E[30秒内恢复延迟]

优势2：结合业务特征扩容

# 示例：基于订单量的扩容规则
- alert: HighOrderRateexpr: rate(order_create_total[1m]) > 1000for: 1mannotations:command: "kubectl scale deploy payment --replicas=20"
原生HPA无法直接感知「订单量」这类业务指标。

优势3：实现跨资源联动

# 伪代码：同时扩容节点和Pod
def scale_cluster(traces):if need_more_nodes():cloud_api.add_nodes(2)  # 扩容云主机k8s.scale(deploy, 10)   # 扩容Pod

突破HPA仅调整 Pod 副本数的限制。

2. 生产级实践建议：分层扩缩容

分层扩缩容策略：

graph TDA[实时监控] -->|指标正常| B[HPA自动调节]A -->|指标超阈值| C[告警触发紧急扩容]C --> D[同时通知运维人员]

具体实施步骤：

基础层：HPA 处理日常波动。

k8s HPA yaml 配置文件示例：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:name: payment-hpa
spec:scaleTargetRef:apiVersion: apps/v1kind: Deploymentname: paymentminReplicas: 2maxReplicas: 10metrics:- type: Resourceresource:name: cputarget:type: UtilizationaverageUtilization: 60

增强层：告警驱动扩容应对峰值

在Alertmanager 配置

# Alertmanager 配置
routes:
- receiver: 'scale-receiver'match:severity: 'scale'
receivers:
- name: 'scale-receiver'webhook_configs:- url: 'http://autoscaler-service/scale'send_resolved: false

联动脚本示例：

# 自动扩容服务（伪代码）
@app.route('/scale', methods=['POST'])
def handle_alert():alert = request.jsonif alert['status'] == 'firing':service = alert['labels']['service']current = get_current_replicas(service)new_replicas = current * 2  # 倍数扩容k8s_api.scale(service, new_replicas)log(f"紧急扩容 {service} 至 {new_replicas} 副本")

关键结论

• HPA适合处理已知模式的负载波动，而本方案用于应对突发异常场景，两者可共存。

成本与效率平衡

• 日常使用HPA节省资源。

• 突发场景用告警扩容保障 SLA。

升级方向 ：可引入KEDA（Kubernetes Event-Driven Autoscaler）实现两者的融合。代码示例如下：

# KEDA 示例：基于 Prometheus 指标扩缩
apiVersion: keda.sh/v1alpha1
kind: ScaledObject
metadata:name: order-scaler
spec:scaleTargetRef:name: order-servicetriggers:- type: prometheusmetadata:serverAddress: http://prometheus:9090metricName: http_requests_totalquery: sum(rate(http_requests_total{app="order"}[1m]))threshold: '1000'

5.4 可观测平台的实现

方案 1：开源工具链整合

graph LRS[Sleuth] --> Z[Zipkin]P[Prometheus] --> G[Grafana]E[ELK] --> K[Kibana]Z -->|插件| GG -->|TraceID关联| K

Grafana 作用：

• 可视化层：通过插件支持展示Prometheus指标 +Zipkin追踪数据。

• 关联查询：安装Zipkin数据源插件，实现Trace与指标联动。

Grafana关键配置：

# Grafana 配置示例
grafana:datasources:- name: Prometheustype: prometheusurl: http://prometheus:9090- name: Zipkintype: zipkinurl: http://zipkin:9411

2. 生产环境建议

• 初期阶段：

使用Grafana+Prometheus+Zipkin+ELK实现基础可观测性。

• 成熟阶段：

引入商业平台或自研中间件实现：

• 自动生成故障诊断报告

• 预测性扩容（基于历史指标）

• 安全事件关联分析

5.5 总结

可观测体系的核心价值在于：

• 快速定位问题：通过 TraceID 关联日志、指标与追踪数据。

• 优化系统性能：基于可视化分析识别瓶颈。

• 提升运维效率：通过智能告警与自动化治理降低人工干预。

通过分层设计与工具整合，可构建覆盖预防、定位与修复闭环的企业级可观测能力。

1.入门：本地 Demo 部署，理解Trace / Span传递机制

2.进阶：实现生产级高可用架构（异步上报 + 集群存储）

3.专家：探索OpenTelemetry 标准与Service Mesh集成

六、总结

6.1 核心重点

围绕Spring Cloud Sleuth + Zipkin的全链路追踪方案，核心内容包括：

• 技术原理与核心工具

Sleuth：自动生成并传递追踪数据

Zipkin：提供可视化分析能力（拓扑图、火焰图）

• 生产实践

告警规则设计、性能调优与可观测体系构建。

从零搭建追踪环境。

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如若转载，请注明出处：http://www.rhkb.cn/news/36661.html

如若内容造成侵权/违法违规/事实不符，请联系长河编程网进行投诉反馈email:809451989@qq.com，一经查实，立即删除！

相关文章

数据类设计_图片类设计之6_矩阵图形类设计（前端架构）

数据类设计_图片类设计之6_矩阵图形类设计（前端架构）

前言 学的东西多了,要想办法用出来.C和C是偏向底层的语言,直接与数据打交道.尝试做一些和数据方面相关的内容 引入 接续上一篇,讨论矩阵图形类设计 方法论-现在能做什么 这段属于聊天内容---有句话是这么说的&#xff1a;不要只埋头拉车&#xff0c;还要抬头看路。写代码也是…
阅读更多...
OpenCV图像拼接（1）概述

OpenCV图像拼接（1）概述

操作系统&#xff1a;ubuntu22.04 OpenCV版本&#xff1a;OpenCV4.9 IDE:Visual Studio Code 编程语言&#xff1a;C11 算法描述 此图说明了在Stitcher类中实现的拼接模块流程。使用该类&#xff0c;可以配置/移除某些步骤&#xff0c;即根据特定需求调整拼接流程。流程中的所…
阅读更多...
【开原宝藏】30天学会CSS - DAY1 第一课

【开原宝藏】30天学会CSS - DAY1 第一课

下面提供一个由浅入深、按步骤拆解的示例教程&#xff0c;让你能从零开始&#xff0c;逐步理解并实现带有旋转及悬停动画的社交图标效果。为了更简单明了&#xff0c;以下示例仅创建四个图标&#xff08;Facebook、Twitter、Google、LinkedIn&#xff09;&#xff0c;并在每一步…
阅读更多...
【pytest框架源码分析五】pytest插件的注册流程

【pytest框架源码分析五】pytest插件的注册流程

前文介绍到pytest整体是运用插件来实现其运行流程的。这里仔细介绍下具体过程。 首先进入main方法 def main(args: list[str] | os.PathLike[str] | None None,plugins: Sequence[str | _PluggyPlugin] | None None, ) -> int | ExitCode:"""Perform an i…
阅读更多...
谷歌or-tools开源库入门

谷歌or-tools开源库入门

1.命令行编译程序 这里要说明下&#xff0c;直接用qt或者VS2022打开cmake工程&#xff0c;编译没有成功。所以&#xff0c;老老实实的按照官方教程来&#xff0c;使用命令行编译。 &#xff08;1&#xff09;准备 1&#xff09;安装cmake&#xff0c;版本3.18以上&#xff0…
阅读更多...
Python实现WYY音乐下载

Python实现WYY音乐下载

一、需求背景 WYY音乐作为国内主流音乐平台，其歌曲资源丰富但下载接口存在多重加密保护。本文将通过Python结合JS逆向技术，解析其核心加密逻辑，实现免费歌曲的下载功能。 二、技术难点分析 1. 接口加密机制 通过抓包分析可知，网易云核心接口使用两次加密： 第一次：获取…
阅读更多...
拥抱健康生活，开启养生之旅

拥抱健康生活，开启养生之旅

在快节奏的现代生活中&#xff0c;健康养生愈发重要&#xff0c;它不仅能让我们保持良好状态&#xff0c;更是享受美好生活的基石。​ 饮食养生是健康的关键。我们应秉持均衡原则&#xff0c;一日三餐合理搭配。多摄入新鲜蔬果&#xff0c;它们富含维生素、矿物质与膳食纤维&a…
阅读更多...
《Waf 火绒终端防护绕过实战：系统程序副本+Certutil木马下载技术详解》

《Waf 火绒终端防护绕过实战：系统程序副本+Certutil木马下载技术详解》

目录 绕过火绒终端安全软件的详细方法 方法一&#xff1a;利用系统程序副本绕过命令监控 方法二&#xff1a;结合certutil.exe副本下载并执行上线木马 注意事项 总结 实际案例解决方案 前提条件 详细操作步骤 1. 攻击主机&#xff08;VPS&#xff09;上的准备工作 2.…
阅读更多...
机器学习概要

机器学习概要

文章目录 一、什么是机器学习 二、机器学习的种类 1. 有监督学习 2. 无监督学习 3.强化学习 三、机器学习的应用 四、机器学习的步骤 1. 数据的重要性 2. 数据和学习的种类 3. 可视化 一、什么是机器学习 机器学习指的是计算机根据给定的问题、课题或环境进行学习&a…
阅读更多...
C# Winform 实现换肤，并自定义皮肤功能

C# Winform 实现换肤，并自定义皮肤功能

具体实现原理详见 SkinHelp.cs类&#xff0c;实现了对原有控件的重绘&#xff0c;详见源码 public abstract class SkinHelp{private static SkinColor _currentSkinColor SkinColor.Default;private static BackgroundStripe _currentStripe BackgroundStripe.Default;priva…
阅读更多...
基于FPGA的3U机箱模拟量高速采样板ADI板卡，应用于轨道交通/电力储能等

基于FPGA的3U机箱模拟量高速采样板ADI板卡，应用于轨道交通/电力储能等

板卡简介&#xff1a; 本板为模拟量高速采样板&#xff08;ADI&#xff09;&#xff0c;主要用于电机转速和相电流检测&#xff0c;以实现电机闭环控制。 性能规格&#xff1a; 电源&#xff1a;DC5V&#xff0c;DC3.3V&#xff0c;DC15V&#xff0c;DC24V FPGA&#xff1a;…
阅读更多...
python爬虫概述

python爬虫概述

0x00 python爬虫概述 以豆瓣的选电影模块为例&#xff0c;当查看源代码搜索猫猫的奇幻漂流瓶是搜不到的 这时服务器的工作方式应该是这样的 客户端浏览器第一次访问其实服务器端是返回的一个框架(html代码) 当客户端浏览器第二次通过脚本等方式进行访问时服务器端才返回的数据…
阅读更多...
win10 如何用我的笔记本 接网线 远程控制 台式机

win10 如何用我的笔记本 接网线 远程控制 台式机

1.查看笔记本ip&#xff0c;台式机ip。确保在同一网段 可以ping通 1.1 ip在同一网段&#xff0c;但是ping不通 1.解决&#xff1a;把双方防火墙关闭 2.解决&#xff1a;当前网口&#xff0c;先禁用再启用 以上两台电脑就可以ping通了 2.设置双方电脑 启动远程控制 此电脑-》…
阅读更多...
给管理商场消防安全搭建消防安全培训小程序全过程

给管理商场消防安全搭建消防安全培训小程序全过程

一、需求沟通 “我是管理商场消防安全的嘛&#xff0c;做这个的作用呢&#xff0c;1是商场的所有商户员工可以看平面或者视频随时自学&#xff0c; 2是我们定期培训必修课程、考试&#xff0c;这个需要留存他们的手签字的签到表确认我们讲给他们听了&#xff08;免责很重要&am…
阅读更多...
可视化图解算法：链表中倒数（最后）k个结点

可视化图解算法：链表中倒数（最后）k个结点

1. 题目 描述 输入一个长度为 n 的链表&#xff0c;设链表中的元素的值为ai &#xff0c;返回该链表中倒数第k个节点。 如果该链表长度小于k&#xff0c;请返回一个长度为 0 的链表。 数据范围&#xff1a;0≤n≤105&#xff0c;0 ≤ai≤109&#xff0c;0 ≤k≤109 要求&am…
阅读更多...
Quartz知识点总结

Quartz知识点总结

简单说明 简单的定时任务使用Timer或者ScheduledExecutorService quartz支持复杂的定时执行功能。支持ram存储&#xff08;内存存储&#xff09;和持久化存储。quartz有分布式和集群能力 简单使用 获取任务调度器Schedule。任务调度器可以管理任务。创建任务实例。使用JobB…
阅读更多...
C语言每日一练——day_12（最后一天）

C语言每日一练——day_12（最后一天）

引言 针对初学者&#xff0c;每日练习几个题&#xff0c;快速上手C语言。第十二天。&#xff08;最后一天&#xff0c;完结散花啦&#xff09; 采用在线OJ的形式 什么是在线OJ&#xff1f; 在线判题系统&#xff08;英语&#xff1a;Online Judge&#xff0c;缩写OJ&#xff0…
阅读更多...
【宇宙回响】从Canvas到MySQL：飞机大战的全栈交响曲【附演示视频与源码】

【宇宙回响】从Canvas到MySQL：飞机大战的全栈交响曲【附演示视频与源码】

&#x1f31f; 这是星际大战系列的第三篇送福利文章&#xff0c;感谢一路以来支持和关注这个项目的每一位朋友&#xff01; &#x1f4a1; 文章力求严谨&#xff0c;但难免有疏漏之处&#xff0c;欢迎各位朋友指出&#xff0c;让我们一起在交流中进步。 &#x1f381; 项目代码…
阅读更多...
数据结构知识点1

数据结构知识点1

目录 一、时间复杂度和空间复杂度 1.1时间复杂度&#xff1a; 1.2空间复杂度&#xff1a; 二、装箱和拆箱 三、泛型 3.1泛型类的使用&#xff1a; 3.2泛型的上界&#xff1a; 3.3泛型方法&#xff1a; 一、时间复杂度和空间复杂度 1.1时间复杂度&#xff1a; 时间复杂…
阅读更多...
华为ipd流程华为流程体系管理华为数字化转型流程数字化管理解决方案介绍81页精品PPT

华为ipd流程华为流程体系管理华为数字化转型流程数字化管理解决方案介绍81页精品PPT

华为流程体系最佳实践主要包括构建完善的流程框架&#xff0c;明确各层级流程要素与职责&#xff0c;梳理涵盖研发、采购、营销、服务、资产管理等多领域的流程&#xff0c;通过梳理业务场景和核心能力搭建差异化流程框架&#xff0c;采用自上而下与自下而上相结合的建模方法&a…
阅读更多...
最新文章
推荐文章

Copyright @ 2022~2023