企业后端架构第一版该保留哪些核心能力

企业后端架构第一版该保留哪些核心能力

可观测性体系刚上线的第一周，告警系统的通知音就没有停过：1 分钟内弹出了 5,400 条告警。绝大部分是“某个无关紧要的静态资源接口 Latency 稍微波动”或“调用链路中某个非核心 SQL 耗时超过 50ms”。

更令人尴尬的是，由于开启了 OpenTelemetry 的全量 Trace 采样（按检查结果确认 Sampling），可观测性 Agent 自身占用的 CPU 竟然吃掉了 Pod 额度配额的 15%，日志传输直接挤爆了 ElasticSearch 的磁盘 I/O。

可观测性建设切忌试图在第一阶段“大而全”。如果第一版没有找准核心链路与关键指标，收集到的海量数据不仅不能辅助排障，反而会成为淹没真实故障信息的噪音噪音库。

+———————————————————————————–+
| Spring Microservice Request Gateway |
+———————————————————————————–+
|
v
+———————————————————————————–+
| OpenTelemetry Adaptive Sampler & MDC Trace Injector |
| – Rate-limiting Sampler – Error Mandatory Sample – SLF4J MDC TraceId Injection |
+———————————————————————————–+
/ \\
[Sampled] / \\ [Not Sampled / Normal]
v v
+————————————+ +——————————+
| Lightweight Exporter to OTel Collector| | Local Log MDC Trace Only & |
| (Minimal Metrics & Span Export) | | Suppress Full Trace Transport|
+————————————+ +——————————+

1. 现场诊断：OTel 采样开销与告警噪声审计

在可观测性治理的初期，排查的第一步是量化监控系统本身的资源损耗。

诊断命令与性能评估如下：

# 监测 OpenTelemetry Java Agent 占用的 CPU 与内存开销
top -hp $(pgrep -f "java") | head -n 15

# 查看 OpenTelemetry Collector 实例的传输与丢弃 Metrics 状态
curl -s http://otel-collector.internal.net:8888/metrics | grep "otelcol_processor_dropped_spans"

# 检查 ElasticSearch 集群日均 Index 增长速度与磁盘占用
curl -X GET "http://es-cluster.internal.net:9200/_cat/indices?v&s=store.size:desc" | head -n 10

数据露出了残酷的现实：全量 Trace 收集导致原本只需处理 1,000 QPS 的微服务，额外产生了每秒 20MB 的 Trace Data 传输。其中 95% 的 Trace 都是成功的 HTTP 200 GET 请求，没有任何排障价值，却白白烧掉了巨量的 CPU 计算周期与存储成本。

2. 生产级 OpenTelemetry 动态采样与 MDC 注入器

第一版 (MVP) 可观测性体系的核心原则是：日志应带 TraceID，但远程 Trace 传输应实施严格的自适应采样（Adaptive Sampling）。凡是成功的普通请求，仅按 1% 采样；凡是抛出 5xx 异常或响应超过 1 秒的请求，按检查结果确认 强制采样。

以下是在 Spring Boot 服务中实现的轻量级 OpenTelemetry 采样与 MDC 关联组件：

package com.example.observability.governance;

import io.opentelemetry.api.trace.Span;
import io.opentelemetry.api.trace.SpanContext;
import io.opentelemetry.sdk.trace.samplers.Sampler;
import io.opentelemetry.sdk.trace.samplers.SamplingDecision;
import io.opentelemetry.sdk.trace.samplers.SamplingResult;
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.slf4j.MDC;
import org.springframework.stereotype.Component;

import java.util.concurrent.ThreadLocalRandom;

/**
* 生产环境可观测性第一版：轻量级动态采样与 MDC 注入器
*/
@Component
public class AdaptiveObservabilitySampler implements Sampler {
private static final Logger log = LoggerFactory.getLogger(AdaptiveObservabilitySampler.class);

private static final String TRACE_ID_KEY = "traceId";
private static final double REGULAR_SAMPLE_RATE = 0.01; // 普通成功请求 1% 采样

@Override
public SamplingResult shouldSample(
io.opentelemetry.context.Context parentContext,
String traceId,
String name,
io.opentelemetry.api.trace.SpanKind spanKind,
io.opentelemetry.api.common.Attributes attributes,
java.util.List<io.opentelemetry.api.trace.StatusCode> parentSpans) {

// 绑定 MDC 变量，保证所有 SLF4J 本地日志都能带上 TraceID
MDC.put(TRACE_ID_KEY, traceId);

// 1. 优先检查链路是否已有强采样标记
Span parentSpan = Span.fromContext(parentContext);
SpanContext parentSpanContext = parentSpan.getSpanContext();
if (parentSpanContext.isValid() && parentSpanContext.isSampled()) {
return SamplingResult.recordAndSample();
}

// 2. 核心写操作或已知高危接口 100% 采样
if (name.contains("/payment/") || name.contains("/order/create")) {
return SamplingResult.recordAndSample();
}

// 3. 普通接口概率采样 (1%)
if (ThreadLocalRandom.current().nextDouble() < REGULAR_SAMPLE_RATE) {
return SamplingResult.recordAndSample();
}

return SamplingResult.create(SamplingDecision.DROP);
}

@Override
public String getDescription() {
return "AdaptiveObservabilitySampler{regularRate=" + REGULAR_SAMPLE_RATE + "}";
}

public static void clearMDC() {
MDC.remove(TRACE_ID_KEY);
}
}

3. 可观测性第一版 (MVP) 的剪枝准则

搭建第一版可观测性体系时，应坚决做好以下取舍：

• 准则 1：只抓“黄金指标”（Golden Signals）。第一阶段只抓 Latency（延迟）、Traffic（流量）、Errors（错误率）、Saturation（饱和度）这 4 个指标。任何非核心的自定义业务 Counter 暂不收集，防止 Metrics 基数爆炸（Cardinality Explosion）。
• 准则 2：Trace 降级为辅助，日志+MDC 才是基石。确保单体或微服务内部的每一个 log.info() 或 log.error() 的输出格式中都包含 [%X{traceId}]。只要日志打得精准且能通过 TraceID 检索，就算关闭全量 Trace 传输，依然能在 3 分钟内完成定位。
• 准则 3：告警收口到“服务级 SLA”。避免为单台机器的瞬时 CPU 波动设置电话或短信告警。只有当核心 API 的 P99 延迟突破阈值，或者 5xx 错误率连续 2 分钟超过 1% 时，才触发告警。

第一版可观测性只需覆盖核心请求、少量可行动的告警和能关联日志的追踪信息。采样率、阈值和保留周期应按实际流量调整，避免为了“全量可见”反过来挤占业务资源。