当前位置： 首页 > news >正文

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

news 来源：原创 2025/5/29 4:52:04

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

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

• 性能瓶颈模糊：当响应延迟增加时，如何快速判断是数据库、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 TD
  A[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-service
  zipkin:
    base-url: http://localhost:9411  # Zipkin服务器地址
  sleuth:
    sampler:
      probability: 1.0  # 设置追踪采样率，1.0表示追踪所有请求。采样率100%(开发环境)

payment-service 配置

server:
  port: 8081
spring:
  application:
    name: payment-service
  zipkin:
    base-url: http://localhost:9411
  sleuth:
    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-prod
  sleuth:
    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: APIHighLatency
  expr: >-
    histogram_quantile(0.95, 
      rate(zipkin_latency_seconds_bucket{
        service="payment-service",
        http_method="POST"
      }[5m])
    ) > 1  # 阈值1秒
  for: 10m  # 持续10分钟触发
  labels:
    severity: S1
  annotations:
    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: PaymentErrorSpike
  expr: >-
    increase(zipkin_errors_total{
      service="payment-service",
      status=~"5.."
    }[1m]) > 10
  labels:
    severity: S2
  annotations:
    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 --> G
        F --> 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: Zipkin
    type: zipkin
    url: http://zipkin:9411
  - name: Prometheus
    type: prometheus
    url: 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. 自动化治理

监控告警触发扩容方案

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

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

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

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

1.方案的核心优势

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

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

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

# 示例：基于订单量的扩容规则
- alert: HighOrderRate
  expr: rate(order_create_total[1m]) > 1000
  for: 1m
  annotations:
    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 TD
    A[实时监控] -->|指标正常| B[HPA自动调节]
    A -->|指标超阈值| C[告警触发紧急扩容]
    C --> D[同时通知运维人员]

具体实施步骤：

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

k8s HPA yaml 配置文件示例：

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: payment-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: payment
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 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.json
    if 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-service
  triggers:
  - type: prometheus
    metadata:
      serverAddress: http://prometheus:9090
      metricName: http_requests_total
      query: sum(rate(http_requests_total{app="order"}[1m]))
      threshold: '1000'

5.4 可观测平台的实现

方案 1：开源工具链整合

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

Grafana 作用：

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

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

Grafana关键配置：

# Grafana 配置示例
grafana:
  datasources:
    - name: Prometheus
      type: prometheus
      url: http://prometheus:9090
    - name: Zipkin
      type: zipkin
      url: 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：提供可视化分析能力（拓扑图、火焰图）

• 生产实践

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

从零搭建追踪环境。

相关文章：

  • 2025-03-19 学习记录--C/C++-C 库函数 - qsort() 实现快速排序
  • [Linux] make自动化构建
  • 【多线程-第四天-SDWebImage介绍 Objective-C语言】
  • Ubuntu24.10编译Android12源码并运行于模拟器中
  • k8s中的组件
  • AI训练如何获取海量数据，论平台的重要性
  • 部署|Llama-Facory微调模型部署
  • element-plus中Dropdown下拉菜单组件的使用
  • word插入Mathtype公式居中和自动更新
  • PairRE: Knowledge Graph Embeddings via Paired Relation Vectors（论文笔记）
  • 八股学习-JUC java并发编程
  • svn-1.7.22安装
  • ESP8266通过AT指令配置双向透传
  • C++常用多线程模式
  • 【病毒分析】伪造微软官网+勒索加密+支付威胁，CTF中勒索病毒解密题目真实还原！
  • 机器学习面试重点第二部分(动画版)
  • 服务创造未来 东隆科技携多款产品亮相慕尼黑
  • Idea中使用Git插件_合并当前分支到master分支_冲突解决_很简单---Git工作笔记005
  • Debezium + Kafka-connect 实现Postgres实时同步Hologres
  • Spring Boot配置与注解的使用
  • 网站如何做快照/网络营销软件站
  • 网站如何做首面关键词/首页关键词怎么排名靠前
  • 国家建筑信息管理平台/seo免费培训
  • 海口网站建设方案/百度平台我的订单查询在哪里
  • 新疆建设委员会网站/什么是新媒体营销
  • wordpress自动翻译双语主页/搜索引擎推广和优化方案