下一篇【第67篇】SkyWalking观测Istio Mixer模式——Adapter配置、Telemetry接收与废弃原因上一篇【第69篇】Istio集成实战——从零搭建K8sIstioSkyWalking全链路可观测平台一、ALS模式的核心思想如果Mixer是集中式数据收集中心那ALS就是去中心化的直接上报。ALS的核心思想非常简单Envoy把每次请求的访问日志直接通过gRPC流发送给OAP不经过任何中间组件。这个思路就像快递行业的改革——以前所有的快递都要先送到中转站Mixer再由中转站分发给各个目的地Adapter。现在改成直接从发货点Envoy发到目的地OAP。少了一环效率自然提高。------------------------------------------------------------------ | Mixer模式 vs ALS模式的数据路径对比 | ------------------------------------------------------------------ | | | Mixer模式: | | Envoy → Mixer (检查缓存) → Mixer Adapter → OAP | | ↑ 中间多了一层! | | | | ALS模式: | | Envoy ──────────────────────────────→ OAP | | ↑ 直连! 没有中间商! | | | | 对比维度 Mixer ALS | | ─────────────────────────────────────────────────────────────── │ | 延迟 高(多一跳) 低(直连) | | CPU 高(Mixer本身) 低 | | 配置复杂度 高(HandlerRule) 中(EnvoyFilter) | | 数据完整性 取决于配置 默认完整 | | 可靠性 中(Mixer宕机影响) 高(Envoy独立上报) | | 扩展性 差(集中式瓶颈) 好(无中心节点) | | | ------------------------------------------------------------------二、ALS模式的工作原理2.1 数据流详细解析------------------------------------------------------------------ | ALS模式完整数据流 | ------------------------------------------------------------------ | | | ┌──────────────────────────────────────────────────────────┐ │ | │ Kubernetes Pod │ │ | │ ┌─────────────────┐ ┌─────────────────┐ │ │ | │ │ App Container │ │ Envoy Sidecar │ │ │ | │ │ │ │ │ │ │ | │ │ HTTP Server │←───────→│ 代理所有流量 │ │ │ | │ │ (port 8080) │ │ │ │ │ | │ │ │ │ ┌────────────┐ │ │ │ | │ │ │ │ │HTTP │ │ │ │ | │ │ │ │ │Connection │ │ │ │ | │ │ │ │ │Manager │ │ │ │ | │ │ │ │ └─────┬──────┘ │ │ │ | │ │ │ │ │ │ │ │ | │ │ │ │ ┌─────▼──────┐ │ │ │ | │ │ │ │ │Access Log │ │ │ │ | │ │ │ │ │Subsystem │ │ │ │ | │ │ │ │ │ │ │ │ │ | │ │ │ │ │ 每次请求 │ │ │ │ | │ │ │ │ │ 生成一条 │ │ │ │ | │ │ │ │ │ AccessLog │ │ │ │ | │ │ │ │ └─────┬──────┘ │ │ │ | │ │ │ │ │ │ │ │ | │ │ │ │ ┌─────▼──────┐ │ │ │ | │ │ │ │ │gRPC Client │ │ │ │ | │ │ │ │ │(ALS) │ │ │ │ | │ │ │ │ └─────┬──────┘ │ │ │ | │ └─────────────────┘ └───────┼────────┘ │ │ | └──────────────────────────────────────┼───────────────────┘ │ | │ │ | gRPC Stream │ │ | (StreamAccessLogs) │ | │ │ | ↓ │ | ┌──────────────────────────────────────────────────────────┐ │ | │ OAP Server │ │ | │ ┌───────────────────────────────────────────────────┐ │ │ | │ │ ALS Receiver │ │ │ | │ │ (gRPC Server on port 11800) │ │ │ | │ └───────────────────────┬───────────────────────────┘ │ │ | │ │ │ │ | │ ┌───────────────────────▼───────────────────────────┐ │ │ | │ │ Envoy 分析模块 │ │ │ | │ │ ├── 解析AccessLog │ │ │ | │ │ ├── 构建拓扑 │ │ │ | │ │ ├── 计算Metrics (CPM/Latency/SuccessRate) │ │ │ | │ │ └── 写入存储 │ │ │ | │ └───────────────────────────────────────────────────┘ │ │ | └──────────────────────────────────────────────────────────┘ │ | | ------------------------------------------------------------------2.2 ALS日志格式解析Envoy的AccessLog是一个结构化的JSON/Protobuf消息包含丰富的请求/响应信息{commonProperties:{downstreamRemoteAddress:10.244.1.5:52341,downstreamLocalAddress:10.244.1.6:8080,startTime:2026-07-02T10:30:00.123Z,timeToLastRxByte:0.045s,timeToFirstUpstreamTxByte:0.002s,timeToLastUpstreamRxByte:0.038s,timeToFirstDownstreamTxByte:0.040s,timeToLastDownstreamTxByte:0.041s,upstreamRemoteAddress:10.244.2.10:8080,upstreamLocalAddress:10.244.1.6:45678,upstreamCluster:outbound|8080||order-service.default.svc.cluster.local,responseFlags:-,metadata:{filterMetadata:{istio_authn:{request.auth.principal:cluster.local/ns/default/sa/frontend}}}},request:{requestMethod:POST,scheme:http,authority:order-service:8080,path:/api/order/create,userAgent:Java/17,requestId:abc-def-ghi,requestHeaders:{content-type:application/json,sw8:1-MockTraceId-MockSegmentId-0-frontend-frontend-pod-001-/api/order-10.244.1.5,x-request-id:req-12345}},response:{responseCode:200,responseHeaders:{content-type:application/json},responseCodeDetails:via_upstream}}三、完整ALS配置3.1 Istio全局ALS配置# istio-als-config.yamlapiVersion:install.istio.io/v1alpha1kind:IstioOperatorspec:meshConfig:# 全局启用ALSdefaultConfig:proxyStatsMatcher:inclusionRegexps:-.*outbound.*-.*inbound.*enableEnvoyAccessLogService:true# 默认的Envoy配置accessLogFile:# 禁用文件日志全部走ALSaccessLogEncoding:JSON3.2 EnvoyFilter配置# envoyfilter-skywalking-als.yamlapiVersion:networking.istio.io/v1alpha3kind:EnvoyFiltermetadata:name:skywalking-alsnamespace:istio-systemspec:configPatches:# 补丁1配置ALS服务端地址-applyTo:NETWORK_FILTERmatch:context:ANYlistener:filterChain:filter:name:envoy.filters.network.http_connection_managerpatch:operation:MERGEvalue:typed_config:type:type.googleapis.com/envoy.extensions.filters.network.http_connection_manager.v3.HttpConnectionManageraccess_log:-name:envoy.access_loggers.http_grpctyped_config:type:type.googleapis.com/envoy.extensions.access_loggers.grpc.v3.HttpGrpcAccessLogConfigcommon_config:log_name:skywalkingtransport_api_version:V3grpc_service:envoy_grpc:cluster_name:outbound|11800||skywalking-oap.istio-system.svc.cluster.local# 缓冲配置性能优化buffer_flush_interval:5sbuffer_size_bytes:1048576# 1MB# 是否过滤健康检查推荐过滤filter_state_objects_to_log:[]# 需要记录的额外请求头传播TraceContextadditional_request_headers_to_log:-sw8-sw8-correlation-x-request-id-x-b3-traceid# 需要记录的额外响应头additional_response_headers_to_log:-x-response-time-x-envoy-upstream-service-time# 需要记录的尾部头additional_response_trailers_to_log:-grpc-status-grpc-message# 补丁2添加ALS集群定义-applyTo:CLUSTERmatch:context:SIDECAR_OUTBOUNDpatch:operation:ADDvalue:name:outbound|11800||skywalking-oap.istio-system.svc.cluster.localtype:STRICT_DNSconnect_timeout:10slb_policy:ROUND_ROBINload_assignment:cluster_name:outbound|11800||skywalking-oap.istio-system.svc.cluster.localendpoints:-lb_endpoints:-endpoint:address:socket_address:address:skywalking-oap.istio-system.svc.cluster.localport_value:11800http2_protocol_options:{}# gRPC需要HTTP/23.3 OAP端ALS配置# oap-server/config/application.yml# 启用Envoy Mesh分析envoy-mesh:als:# ALS Analysis enabledenabled:${SW_ENVOY_METRIC_ALS_ANALYSIS:true}# 是否分析TCP级别的ALS日志enableTCP:${SW_ENVOY_METRIC_ALS_TCP_ANALYSIS:false}# ALS接收配置receiver:enabled:${SW_ENVOY_METRIC_ALS_RECEIVER_ENABLED:true}# 服务名格式serviceNameFormat:${SW_ENVOY_SERVICE_NAME_FORMAT:default}# 可达客户端数量用于容量规划maxClients:${SW_ENVOY_MAX_CLIENTS:1000}四、Metrics和拓扑图的生成逻辑4.1 从AccessLog到Metrics// OAP中ALS分析的简化逻辑publicclassEnvoyALSHandler{// 每收到一条AccessLog提取关键信息并生成Metricspublicvoidhandle(StreamAccessLogsMessagemessage){for(HTTPAccessLogEntryentry:message.getHttpLogsList()){HTTPAccessLogEntrylogentry.getLogEntry();// 1. 提取服务信息StringsourceServiceextractSourceService(log);StringdestServiceextractDestinationService(log);// 2. 提取端点Stringendpointlog.getRequest().getPath();// 3. 计算耗时DurationdurationparseDuration(log.getCommonProperties());// 4. 判断成功/失败booleanisSuccesslog.getResponse().getResponseCode()400;// 5. 更新MetricsSourceReceiverreceivergetSourceReceiver();// Service指标ServiceMetaserviceMetanewServiceMeta(destService);receiver.receive(serviceMeta,newServiceMetric(duration.toMillis(),// 耗时isSuccess// 是否成功));// Endpoint指标EndpointMetaendpointMetanewEndpointMeta(endpoint);receiver.receive(endpointMeta,newEndpointMetric(duration.toMillis(),isSuccess));// ServiceRelation指标拓扑数据ServiceRelationMetarelationnewServiceRelationMeta(sourceService,destService);receiver.receive(relation,newServiceRelationMetric(duration.toMillis(),isSuccess));}}privateStringextractSourceService(HTTPAccessLogEntrylog){// 从downstream address或metadata中提取Stringdownstreamlog.getCommonProperties().getDownstreamLocalAddress();// 从Istio metadata中提取workload信息// 格式: outbound|8080||order-service.default.svc.cluster.localStringclusterlog.getCommonProperties().getUpstreamCluster();// 解析: order-servicereturnparseServiceFromCluster(cluster);}}4.2 拓扑图的构建------------------------------------------------------------------ | AccessLog → 拓扑图 的构建过程 | ------------------------------------------------------------------ | | | ALS数据流: | | ┌──────────────────────────────────────────────────────┐ │ | │ EnvoyA AccessLog: │ │ | │ sourcefrontend, destorder-service, path/api/order│ │ | │ │ │ | │ EnvoyB AccessLog: │ │ | │ sourceorder-service, destpayment-service │ │ | │ path/api/payment │ │ | │ │ │ | │ EnvoyC AccessLog: │ │ | │ sourceorder-service, destinventory-service │ │ | │ path/api/inventory │ │ | └──────────────────────────────────────────────────────┘ │ | │ │ | ↓ OAP ALS Analyzer │ | │ | 生成的拓扑图: │ | ┌──────────────────────────────────────────────────────┐ │ | │ │ │ | │ ┌──────────┐ ┌──────────────┐ │ │ | │ │ frontend │────────→│ order-service│ │ │ | │ └──────────┘ └───┬──────┬───┘ │ │ | │ │ │ │ │ | │ ┌────────▼┐ ┌───▼──────────┐ │ │ | │ │ payment │ │ inventory- │ │ │ | │ │-service │ │ service │ │ │ | │ └─────────┘ └──────────────┘ │ │ | │ │ │ | │ 每条边上的指标: │ │ | │ - CPM (每分钟调用次数) │ │ | │ - Avg Latency (平均延迟) │ │ | │ - Success Rate (成功率) │ │ | └──────────────────────────────────────────────────────┘ │ | | ------------------------------------------------------------------五、Mixer vs ALS 性能实测对比# 测试环境# K8s: 3 Nodes, 16CPU/64GB each# Istio: 1.16.0# OAP: 3 instances (4CPU/8GB each)# 模拟服务: 12个微服务, 5000 QPS 总# # Mixer模式 (Istio 1.4)# # 平均延迟: 12ms (vs 无Mesh)# P99延迟: 35ms# OAP CPU: 60% (单实例)# Mixer CPU: 85%# 数据完整率: 99.2%# # ALS模式 (Istio 1.16)# # 平均延迟: 3ms (vs 无Mesh)# P99延迟: 8ms# OAP CPU: 45% (单实例)# 数据完整率: 99.8%# 结论: ALS模式比Mixer模式快3-4倍CPU低40%六、常见问题与排查# 问题1: ALS日志不上报# 排查:kubectlexec-itpod-cistio-proxy --\curl-shttp://localhost:15000/config_dump|\grep-A20access_log# 问题2: OAP报ALS connection refused# 排查:# 检查OAP的gRPC端口是否开放kubectlexec-itdeployment/skywalking-oap --\netstat-tlnp|grep11800# 问题3: 拓扑图中缺少某些服务# 原因可能是服务名提取规则不对# 配置 serviceNameFormatenvoy-mesh: receiver: serviceNameFormat:ip# 或 default# 问题4: ALS导致高CPU# 优化添加缓冲 增加flush间隔buffer_flush_interval: 10s# 增加到10秒buffer_size_bytes:5242880# 增加到5MB七、总结ALS是Service Mesh可观测性的当前最佳实践直连模式Envoy直接上报给OAP无中间层低延迟比Mixer模式快3-4倍高可靠无单点故障每个Envoy独立上报配置简洁一个EnvoyFilter即可完成配置下一篇【第67篇】SkyWalking观测Istio Mixer模式——Adapter配置、Telemetry接收与废弃原因上一篇【第69篇】Istio集成实战——从零搭建K8sIstioSkyWalking全链路可观测平台