构建基于Azure Consul Connect的微前端PWA端到端可观测性体系

可观测性

文章字数: 3.6k

阅读时长: 15 分

当一个由微前端构建的PWA应用，其后端微服务部署在Azure Kubernetes Service (AKS)并由Consul Connect管理时，一次用户点击的性能瓶颈排查会迅速演变成一场跨越多个技术孤岛的侦探工作。前端团队看到了一个缓慢的API调用，但无法确定是网络延迟、API网关问题，还是后端服务间通信的阻塞。后端团队在自己的服务日志里可能看不到任何异常，因为问题可能出在Consul管理的Sidecar代理或更深层次的依赖服务上。平台团队则在Azure Monitor的指标和Consul的遥测数据中寻找线索，但这一切都是离散的，缺乏因果关联。

问题的本质是追踪上下文的丢失。一个完整的用户请求链路被前端、API网关、服务网格、后端应用等多个层面割裂，形成了一个个可观测性的盲区。

方案A: 离散式监控组合

这是最常见的初始方案，每个技术栈采用其领域内成熟的工具。

前端 (PWA / Micro-frontends): 使用商业化的RUM (Real User Monitoring) 工具，如Sentry或Datadog RUM。它们能很好地捕获前端JS错误、页面加载性能（Core Web Vitals）和独立的API请求耗时。
后端 (AKS上的微服务): 启用Azure Application Insights的自动探针或SDK。它可以提供单个服务内部的性能剖析、依赖项跟踪和异常捕获。
服务网格 (Consul Connect): 依赖Consul内置的遥测功能，将Envoy代理的Prometheus指标（如请求延迟、成功率）接入Azure Monitor managed service for Prometheus。

优势:

快速集成: 各个组件的接入相对独立，团队可以并行工作。
领域深度: 每个工具都在其特定领域提供了丰富的功能。

劣势:

上下文完全断裂: RUM工具生成的transaction_id与Application Insights的trace_id毫无关联。当用户报告“订单提交按钮点击后加载了10秒”，我们无法将这个前端事件直接关联到后端具体的某一次数据库慢查询。
排障效率低下: 工程师需要在至少三个不同的UI界面之间手动切换，试图通过时间戳和请求特征来“猜测”它们之间的联系，这在复杂的生产环境中几乎是不可能的。
服务网格成为黑盒: Consul Connect中的Envoy代理处理了所有服务间的流量。如果延迟发生在代理本身（例如，路由解析、TLS握手），无论是前端RUM还是后端APM都无法直接观测到。

方案B: 基于OpenTelemetry的统一可观测性体系

该方案的核心是采用一个中立的、标准化的规范（OpenTelemetry）来统一整个请求链路的数据采集，并将所有遥测数据（Traces, Metrics, Logs）发送到一个集中的处理后端。

数据标准: 所有组件都遵循W3C Trace Context规范，确保traceparent和tracestate头在从浏览器到数据库的整个路径中无损传递。
采集层:
- 前端: 使用OpenTelemetry JS SDK手动或自动地对微前端进行插桩。
- 后端: 使用对应语言的OpenTelemetry SDK（如Go, .NET, Java）对微服务进行插桩。
- 服务网格: 配置Consul Connect的Envoy代理，使其成为追踪链路的一部分，并将其追踪数据导出到OpenTelemetry Collector。
处理层: 在AKS中部署OpenTelemetry Collector作为DaemonSet或Deployment。它负责接收来自所有源的遥测数据，进行处理（如批处理、采样、添加元数据），然后导出到一个或多个后端。
存储与可视化后端: 使用Azure Monitor作为统一的存储和分析平台。Collector将traces和metrics导出到Azure Monitor。

优势:

端到端全链路视图: 从用户在PWA上的点击开始，到所有后端微服务的调用，再到数据库操作，所有操作都关联在同一个trace ID下，形成一个完整的火焰图。
厂商中立: 底层代码插桩与后端平台解耦。未来如果需要切换或增加另一个可观测性平台（如Grafana Tempo），只需修改Collector的配置，无需改动任何业务代码。
消除盲点: 服务网格不再是黑盒。Envoy代理生成的span会精确地显示流量在网格层所花费的时间，清晰地区分了网络传输耗时、代理处理耗时和应用处理耗时。

劣势:

初期投入较高: 需要对前后端代码进行插桩改造，并需要投入精力设计和维护OpenTelemetry Collector的配置。
技术栈要求: 团队需要对OpenTelemetry的规范和组件有深入的理解。

决策:
对于一个期望长期稳定运行且快速迭代的复杂系统，方案A带来的沟通成本和MTTR（平均修复时间）的增加是不可接受的。我们选择方案B。初期投入的阵痛，换来的是长期的、可持续的、高效的系统洞察力。在真实项目中，快速定位并解决问题的能力是核心竞争力之一。

核心实现概览

以下是构建此体系的关键代码和配置。我们将以一个React微前端、一个Go后端服务和一个部署在AKS上的OpenTelemetry Collector为例。

架构图

graph TD
    subgraph Browser - PWA
        MFE1[Micro-frontend 1]
        MFE2[Micro-frontend 2]
    end

    subgraph Azure Cloud
        subgraph AKS Cluster
            OTEL_COLLECTOR[OpenTelemetry Collector]
            subgraph Namespace: services
                SERVICE_A_POD[Pod: Service A]
                SERVICE_A_POD -- gRPC --> SERVICE_B_POD
                SERVICE_A[Service A App] --> SIDECAR_A[Consul Envoy Sidecar]
                SIDECAR_A -- mTLS --> SIDECAR_B
                SIDECAR_B[Consul Envoy Sidecar] --> SERVICE_B[Service B App]
            end
        end
        AZURE_MONITOR[Azure Monitor]
        API_GW[API Gateway]
    end

    MFE1 -- HTTPS/TraceContext --> API_GW
    API_GW -- HTTPS/TraceContext --> SIDECAR_A
    SERVICE_A_POD -.-> OTEL_COLLECTOR
    SERVICE_B_POD[Pod: Service B] -.-> OTEL_COLLECTOR
    OTEL_COLLECTOR -- OTLP --> AZURE_MONITOR

    style MFE1 fill:#cde4ff
    style MFE2 fill:#cde4ff
    style OTEL_COLLECTOR fill:#f9f,stroke:#333,stroke-width:2px
    style AZURE_MONITOR fill:#9d9,stroke:#333,stroke-width:2px

1. OpenTelemetry Collector 在AKS上的部署

这是整个体系的中枢。我们将它配置为接收OTLP协议的数据，并通过Azure Monitor Exporter发送出去。

otel-collector-config.yaml

apiVersion: v1
kind: ConfigMap
metadata:
  name: otel-collector-conf
  labels:
    app: opentelemetry
    component: otel-collector-conf
data:
  otel-collector-config: |
    receivers:
      otlp:
        protocols:
          grpc:
            endpoint: 0.0.0.0:4317
          http:
            endpoint: 0.0.0.0:4318
            cors:
              allowed_origins:
                - "http://*"
                - "https://*"
              
    processors:
      batch:
        # 批处理可以降低网络IO，提高吞吐量
        send_batch_size: 1024
        timeout: 10s
      memory_limiter:
        # 防止Collector自身内存溢出，是生产环境的必要配置
        check_interval: 1s
        limit_percentage: 75
        spike_limit_percentage: 15

    exporters:
      logging:
        # 用于调试，在生产环境中可以降低日志级别或移除
        loglevel: debug 
      azuremonitor:
        # 核心：将数据导出到Azure Monitor
        # 连接字符串应该通过环境变量或Secret注入，而不是硬编码
        connection_string: "${AZURE_MONITOR_CONNECTION_STRING}"

    service:
      pipelines:
        traces:
          receivers: [otlp]
          processors: [memory_limiter, batch]
          exporters: [logging, azuremonitor]
        metrics:
          receivers: [otlp]
          processors: [memory_limiter, batch]
          exporters: [logging, azuremonitor]

otel-collector-deployment.yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: otel-collector
spec:
  replicas: 2
  selector:
    matchLabels:
      app: opentelemetry
      component: otel-collector
  template:
    metadata:
      labels:
        app: opentelemetry
        component: otel-collector
    spec:
      containers:
      - name: otel-collector
        image: otel/opentelemetry-collector-contrib:latest
        command:
          - "/otelcontribcol"
          - "--config=/conf/otel-collector-config.yaml"
        env:
          - name: AZURE_MONITOR_CONNECTION_STRING
            valueFrom:
              secretKeyRef:
                name: azure-monitor-secrets
                key: connection-string
        ports:
        - name: otlp-grpc
          containerPort: 4317
          protocol: TCP
        - name: otlp-http
          containerPort: 4318
          protocol: TCP
        volumeMounts:
        - name: otel-collector-config-vol
          mountPath: /conf
      volumes:
        - name: otel-collector-config-vol
          configMap:
            name: otel-collector-conf

2. PWA 微前端插桩 (React)

在一个微前端架构中，通常会有一个共享的 “platform” 或 “shell” 应用来初始化通用的服务，比如可观测性。

observability.js (在应用启动时加载)

import { OTLPTraceExporter } from '@opentelemetry/exporter-trace-otlp-http';
import { WebTracerProvider, BatchSpanProcessor } from '@opentelemetry/sdk-trace-web';
import { ZoneContextManager } from '@opentelemetry/context-zone';
import { Resource } from '@opentelemetry/resources';
import { SemanticResourceAttributes } from '@opentelemetry/semantic-conventions';
import { registerInstrumentations } from '@opentelemetry/instrumentation';
import { getWebAutoInstrumentations } from '@opentelemetry/auto-instrumentations-web';

// 这里的URL指向我们在AKS中部署的Collector Service的入口
// 在生产环境中，这通常是一个Ingress地址
const COLLECTOR_URL = process.env.REACT_APP_OTEL_COLLECTOR_URL || 'http://localhost:4318/v1/traces';

const exporter = new OTLPTraceExporter({
  url: COLLECTOR_URL,
});

const provider = new WebTracerProvider({
  resource: new Resource({
    [SemanticResourceAttributes.SERVICE_NAME]: 'pwa-microfrontend-shell',
    [SemanticResourceAttributes.SERVICE_VERSION]: '1.0.2',
  }),
});

provider.addSpanProcessor(new BatchSpanProcessor(exporter));

// 使用ZoneContextManager来确保异步操作的上下文传递
provider.register({
  contextManager: new ZoneContextManager(),
});

// 注册自动插桩
// 这会自动为Fetch, XHR, 用户交互事件等创建Spans
registerInstrumentations({
  instrumentations: [
    getWebAutoInstrumentations({
      // 配置可以精细化控制
      '@opentelemetry/instrumentation-fetch': {
        propagateTraceHeaderCorsUrls: [
          new RegExp(process.env.REACT_APP_API_BASE_URL),
        ],
        clearTimingResources: true,
      },
      '@opentelemetry/instrumentation-user-interaction': {
        enabled: true,
        // 只为我们关心的事件创建Span
        eventNames: ['click', 'submit'] 
      }
    }),
  ],
});

export const tracer = provider.getTracer('pwa-microfrontend-tracer');

在具体的微前端组件中，我们可以创建自定义Span来包裹关键业务逻辑。

AddToCartButton.jsx

import React from 'react';
import { tracer } from '../observability';
import { SpanStatusCode } from '@opentelemetry/api';

function AddToCartButton({ productId }) {
  const handleClick = async () => {
    // 创建一个自定义Span，父Span会自动关联到点击事件的Span
    const span = tracer.startSpan('add-to-cart-logic');
    
    try {
      // 模拟一些客户端业务逻辑
      span.addEvent('Validating product details');
      if (!productId) {
        throw new Error('Product ID is missing');
      }
      
      const response = await fetch(`/api/cart`, {
        method: 'POST',
        headers: { 'Content-Type': 'application/json' },
        body: JSON.stringify({ productId }),
      });

      // 自动插桩的fetch会创建子Span
      
      if (!response.ok) {
        throw new Error(`API call failed with status ${response.status}`);
      }
      
      span.setStatus({ code: SpanStatusCode.OK });
      span.setAttribute('product.id', productId);

    } catch (error) {
      span.setStatus({
        code: SpanStatusCode.ERROR,
        message: error.message,
      });
      // 记录异常，这会显示在追踪详情中
      span.recordException(error);
    } finally {
      // 必须确保span被结束
      span.end();
    }
  };

  return <button onClick={handleClick}>Add to Cart</button>;
}

3. 后端微服务插桩 (Go with Gin)

后端服务需要配置SDK，并创建一个中间件来解析传入的 traceparent 头。

tracing/tracer.go

package tracing

import (
	"context"
	"log"

	"go.opentelemetry.io/otel"
	"go.opentelemetry.io/otel/exporters/otlp/otlptrace/otlptracegrpc"
	"go.opentelemetry.io/otel/propagation"
	"go.opentelemetry.io/otel/sdk/resource"
	sdktrace "go.opentelemetry.io/otel/sdk/trace"
	semconv "go.opentelemetry.io/otel/semconv/v1.17.0"
)

// InitTracerProvider 初始化并注册全局的TracerProvider
// 在生产项目中，endpoint、serviceName等都应该来自配置
func InitTracerProvider(ctx context.Context, serviceName, collectorEndpoint string) (func(context.Context) error, error) {
	res, err := resource.New(ctx,
		resource.WithAttributes(
			semconv.ServiceName(serviceName),
		),
	)
	if err != nil {
		return nil, err
	}

	// 配置OTLP gRPC exporter
	exporter, err := otlptracegrpc.New(ctx,
		otlptracegrpc.WithInsecure(), // 在K8s内部，我们通常使用Insecure
		otlptracegrpc.WithEndpoint(collectorEndpoint),
	)
	if err != nil {
		return nil, err
	}

	// 使用BatchSpanProcessor以获得更好的性能
	bsp := sdktrace.NewBatchSpanProcessor(exporter)

	tp := sdktrace.NewTracerProvider(
		sdktrace.WithSampler(sdktrace.AlwaysSample()), // 生产环境应考虑基于概率或尾部的采样
		sdktrace.WithResource(res),
		sdktrace.WithSpanProcessor(bsp),
	)

	otel.SetTracerProvider(tp)

	// 设置全局的propagator，以便正确解析和注入W3C Trace Context
	otel.SetTextMapPropagator(propagation.NewCompositeTextMapPropagator(propagation.TraceContext{}, propagation.Baggage{}))

	log.Println("Tracer provider initialized.")

	return tp.Shutdown, nil
}

main.go

package main

import (
	"context"
	"log"
	"net/http"
	"os"
	"os/signal"
	"syscall"
	"time"
	
	"my-service/tracing" // 导入上面的包

	"github.com/gin-gonic/gin"
	"go.opentelemetry.io/contrib/instrumentation/github.com/gin-gonic/gin/otelgin"
	"go.opentelemetry.io/otel"
)

func main() {
	ctx := context.Background()

	// 初始化Tracer
	// Collector的地址通常通过环境变量传入
	collectorAddr := os.Getenv("OTEL_EXPORTER_OTLP_ENDPOINT")
	if collectorAddr == "" {
		collectorAddr = "localhost:4317"
	}
	shutdown, err := tracing.InitTracerProvider(ctx, "cart-service", collectorAddr)
	if err != nil {
		log.Fatal(err)
	}
	defer func() {
		if err := shutdown(ctx); err != nil {
			log.Printf("Failed to shutdown tracer provider: %v", err)
		}
	}()

	router := gin.Default()

	// 使用OpenTelemetry Gin中间件
	// 这会自动为每个请求创建span，并从请求头中提取父span上下文
	router.Use(otelgin.Middleware("cart-service"))

	router.POST("/api/cart", func(c *gin.Context) {
		// 中间件已经创建了根span，我们在这里创建子span
		tracer := otel.Tracer("cart-handler")
		_, span := tracer.Start(c.Request.Context(), "database-operation")
		defer span.End()

		// 模拟数据库调用
		time.Sleep(150 * time.Millisecond)
		span.AddEvent("User data saved successfully")
		
		c.JSON(http.StatusOK, gin.H{"status": "item added"})
	})
	
	// 优雅关机... (省略)
	log.Println("Server exiting")
}

4. Consul Connect 与 OpenTelemetry 集成

这是将服务网格融入追踪链路的关键一步。我们需要告诉Consul，让它配置其管理的Envoy代理使用OpenTelemetry追踪驱动。

这可以通过Consul的service-defaults配置项来实现。

consul-tracing-config.hcl

Kind = "service-defaults"
Name = "*" # 应用到所有服务
Protocol = "http"

# 配置网格追踪
MeshGateway {
  Mode = "local"
}

# 核心配置部分
Expose {
  Checks = true
}

TransparentProxy {
  OutboundListenerPort = 15001
}

# 启用Envoy的追踪功能
Tracing {
  # 指定追踪提供商
  Provider {
    Name = "opentelemetry"
  }
  # 将追踪数据发送到我们在AKS中部署的OTel Collector
  # otel-collector.observability.svc.cluster.local 是Collector的K8s Service DNS
  OpenTelemetry {
    CollectorAddress = "otel-collector.observability.svc.cluster.local:4317"
    TlsEnabled = false # 集群内部，我们禁用TLS以简化配置
  }
}

将此配置应用到Consul: consul config write consul-tracing-config.hcl

应用后，当service-a通过Consul Connect调用service-b时，service-a的出口Envoy代理和service-b的入口Envoy代理都会生成自己的span，并正确地将它们链接到由service-a应用代码发起的父span上。在火焰图中，我们将清晰地看到两个新的span，分别标记为 egress 和 ingress，精确地度量了流量在服务网格中花费的时间。

架构的扩展性与局限性

此架构的扩展性体现在其标准化和解耦的特性上。当新的微前端或微服务加入时，只需遵循相同的模式进行插桩，即可无缝地融入现有的可观测性体系。OpenTelemetry Collector的处理器（Processor）和导出器（Exporter）插件机制提供了强大的灵活性，例如，我们可以轻易地增加一个jaeger exporter，实现追踪数据的双写，而无需对任何应用代码进行改动。对于成本控制，可以在Collector层面引入tailsampling处理器，仅当追踪链路中包含错误或耗时超过阈值时才完整保留，从而在保证关键洞察力的前提下大幅降低数据量。

然而，该方案并非没有局限。首先，当前实现高度依赖开发人员在代码中进行手动或半自动插桩。虽然有许多库提供了自动插桩功能，但对于复杂的业务逻辑，精准的自定义span依然不可或缺，这对开发实践提出了一定的要求。其次，数据采集的性能开销是真实存在的，尤其是在高吞吐量的服务中，不恰当的配置（如100%采样）可能会对服务性能产生可感知的冲击。

最后，虽然我们打通了从前端到后端的链路，但一个完整的可观测性体系还应包含更底层的网络和基础设施指标。下一步的优化路径可能是利用eBPF技术，通过零侵入的方式捕获内核级别的网络遥测数据，并将其与OpenTelemetry的追踪数据进行关联，从而获得一个真正覆盖从用户代码到内核调度的全栈视图。

可观测性 OpenTelemetry Consul Connect Azure PWA Micro-frontends

使用 Packer 和 Vector 构建 Elixir 分布式 Saga 的不可变可观测执行单元

2023-10-27 DevOps

Vector Packer 分布式事务 Elixir Sass/SCSS

基于 Kotlin 与 Docker Swarm 构建多租户 SAML 到 JWT 联邦认证网关

2023-10-27 后端架构

Kotlin Docker Swarm Database SAML JWT