下一篇【第66篇】SkyWalking观测Service Mesh——挑战、混合部署与统一拓扑图上一篇【第68篇】SkyWalking观测Istio ALS模式——Envoy AccessLog直连OAP的完整配置指南一、Mixer模式的前世今生在聊技术之前先讲个故事。2017年Istio刚出生时Mixer是它最核心的组件之一。当时的设计哲学是“所有从Envoy出去的数据都要经过Mixer”。这个设计在理论上完美——集中式的数据收集、策略检查、配额管理。但在实践中它成了Istio最大的性能瓶颈。就像一个公司把所有决策都推到CEO那里审批——思路对但效率太低。每次请求都要同步等待CEO签字CEO累死公司也慢。2019年Istio 1.5版本宣布废弃Mixer。这个决定背后的教训对任何做分布式系统的人都很有启发。二、Mixer模式架构------------------------------------------------------------------ | Istio Mixer 架构全景图 | ------------------------------------------------------------------ | | | ┌─────────────────────────────────────────────────────────┐ │ | │ Service Mesh │ │ | │ │ │ | │ ┌───────────────────┐ ┌───────────────────┐ │ │ | │ │ Service A │ │ Service B │ │ │ | │ │ ┌─────┐ ┌─────┐ │ │ ┌─────┐ ┌─────┐ │ │ │ | │ │ │ App │ │Envoy│ │ │ │ App │ │Envoy│ │ │ │ | │ │ └─────┘ └──┬──┘ │ │ └─────┘ └──┬──┘ │ │ │ | │ │ │ │ │ │ │ │ │ | │ └──────────────┼────┘ └──────────────┼────┘ │ │ | │ │ │ │ │ | │ ┌───────┴──────┐ ┌─────────┴──────┐ │ │ | │ │ Check Call │ │ Report Call │ │ │ | │ │ (同步,每次) │ │ (异步,批量) │ │ │ | │ └───────┬───────┘ └─────────┬──────┘ │ │ | │ │ │ │ │ | └─────────────────┼─────────────────────────────┼──────────┘ │ | │ │ │ | ┌───────▼─────────────────────────────▼───────┐ │ | │ Mixer │ │ | │ ┌─────────────┐ ┌─────────────────────┐ │ │ | │ │ Adapter │ │ Adapter │ │ │ | │ │ Manager │ │ Manager │ │ │ | │ │ (Check) │ │ (Report) │ │ │ | │ └──────┬──────┘ └──────────┬──────────┘ │ │ | │ │ │ │ │ | │ ↓ ↓ │ │ | │ ┌──────────────┐ ┌──────────────┐ │ │ | │ │ Prometheus │ │ SkyWalking │ │ │ | │ │ Adapter │ │ Adapter │ │ │ | │ └──────────────┘ └──────┬───────┘ │ │ | │ │ │ │ | └───────────────────────────┼────────────────┘ │ | │ │ | ↓ │ | ┌──────────────────┐ │ | │ OAP Server │ │ | └──────────────────┘ │ | | ------------------------------------------------------------------三、SkyWalking Mixer Adapter的配置3.1 Mixer Handler配置# skywalking-handler.yamlapiVersion:config.istio.io/v1alpha2kind:handlermetadata:name:skywalking-handlernamespace:istio-systemspec:# 指定Handler类型SkyWalking Adapteradapter:skywalking-adapter# 连接配置connection:address:[skywalking-oap.istio-system.svc.cluster.local]:11800timeout:30s# 适配器参数params:# SkyWalking OAP 地址backend_service:skywalking-oap.istio-system.svc.cluster.local:11800# 认证信息如果OAP启用了认证# authentication: token-based# token: your-auth-token# 数据批量上报配置report_batch_size:100# 每批最多100条report_interval:5s# 每5秒上报一次# 缓存配置cache_size:10000cache_expire:15m3.2 Mixer Rule配置# skywalking-rule.yamlapiVersion:config.istio.io/v1alpha2kind:rulemetadata:name:skywalking-rulenamespace:istio-systemspec:# 匹配所有请求match:true# 关联的Action列表actions:-handler:skywalking-handlerinstances:-skywalking-instance# 请求头信息传递给Adapterrequest_header_operations:-operation:OVERWRITEvalues:-x-request-id-x-b3-traceid-x-b3-spanid-x-b3-parentspanid-sw83.3 Instance模板配置# skywalking-instance.yamlapiVersion:config.istio.io/v1alpha2kind:instancemetadata:name:skywalking-instancenamespace:istio-systemspec:template:skywalkingparams:# 来源信息source_uid:source.uid|unknownsource_namespace:source.namespace|defaultsource_workload:source.workload.name|unknown# 目标信息destination_uid:destination.uid|unknowndestination_namespace:destination.namespace|defaultdestination_workload:destination.workload.name|unknowndestination_service_host:destination.service.host|unknown# 请求信息request_method:request.method|request_path:request.path|request_scheme:request.scheme|httprequest_size:request.size|0# 响应信息response_code:response.code|0response_size:response.size|0# 时间信息request_duration:response.duration|0msrequest_time:request.timeresponse_time:response.time四、Mixer Adapter的实现原理4.1 Adapter的工作流程------------------------------------------------------------------ | Mixer Adapter的数据处理流程 | ------------------------------------------------------------------ | | | Mixer发送Report请求 | | │ | | ↓ | | ┌─────────────────┐ | | │ HandleReport() │ ← Adapter的主入口 | | └────────┬────────┘ | | │ | | ↓ | | ┌─────────────────┐ | | │ 解析Instance │ ← 从Instance中提取服务信息 | | │ 提取Attribute │ source/destination worklaod等 | | └────────┬────────┘ | | │ | | ↓ | | ┌─────────────────┐ | | │ 构建SkyWalking │ | | │ 内部数据结构 │ | | │ ─────────────── │ | | │ Service → │ ← 从source提取调用方服务 | | │ ServiceInstance │ (workload name → service name) | | │ Endpoint │ ← 从request.path提取端点 | | │ ServiceRelation │ ← source→destination构成关系 | | └────────┬────────┘ | | │ | | ↓ | | ┌─────────────────┐ | | │ 指标计算 │ | | │ ─────────────── │ | | │ CPM 1 │ ← 调用次数 | | │ AvgLatency dur │ ← 平均延迟 | | │ SuccessRate │ ← 根据response_code判断 | | └────────┬────────┘ | | │ | | ↓ | | ┌─────────────────┐ | | │ 批量缓存 │ ← 缓存到一定量后批量上报 | | └────────┬────────┘ | | │ | | ↓ | | ┌─────────────────┐ | | │ gRPC发送到OAP │ ← 使用Segment协议上报 | | └─────────────────┘ | | | ------------------------------------------------------------------4.2 核心代码简化示例// SkyWalking Mixer Adapter核心逻辑伪代码publicclassSkyWalkingAdapterimplementsHandleReportService{privatefinalSegmentReportServicereportService;privatefinalBlockingQueueUpstreamSegmentbuffer;OverridepublicvoidhandleReport(HandleReportRequestrequest){for(InstanceMsginstance:request.getInstancesList()){// 1. 提取源和目标信息StringsourceServiceextractServiceName(instance,source);StringdestServiceextractServiceName(instance,destination);// 2. 构建SpanSpanObject.BuilderspanBuilderSpanObject.newBuilder();spanBuilder.setOperationName(instance.getParamsOrDefault(request_path,/));spanBuilder.setStartTime(parseTime(instance.getParamsOrThrow(request_time)));spanBuilder.setEndTime(parseTime(instance.getParamsOrThrow(response_time)));// 3. 设置Span属性intresponseCodeInteger.parseInt(instance.getParamsOrDefault(response_code,0));spanBuilder.addTags(KeyStringValuePair.newBuilder().setKey(http.status_code).setValue(String.valueOf(responseCode)));if(responseCode400){spanBuilder.setIsError(true);}// 4. 设置组件信息spanBuilder.setComponentId(Component.ENVOY_MESH.getId());spanBuilder.setSpanLayer(SpanLayer.HTTP);// 5. 构建SegmentSegmentObjectsegmentSegmentObject.newBuilder().setService(sourceService).setServiceInstance(instance.getParamsOrThrow(source_workload)).addSpans(spanBuilder.build()).build();// 6. 加入缓冲区buffer.offer(newUpstreamSegment(segment));// 7. 达到批量大小后上报if(buffer.size()BATCH_SIZE){flush();}}}privatevoidflush(){ListUpstreamSegmentbatchnewArrayList();buffer.drainTo(batch);reportService.collect(Observable.just(batch));}}五、Mixer模式的性能问题5.1 为什么Mixer成了性能瓶颈------------------------------------------------------------------ | Mixer性能问题的根源分析 | ------------------------------------------------------------------ | | | 正常请求路径无Mixer: | | ┌──────────┐ ┌──────────┐ ┌──────────┐ │ | │ Envoy │────→│ Envoy │────→│ Backend │ │ | │ Sidecar │ │ Sidecar │ │ Service │ │ | │ (source) │ │ (dest) │ │ │ │ | └──────────┘ └──────────┘ └──────────┘ │ | | 添加Mixer后的路径: | | ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ | │ Envoy │────→│ Mixer │────→│ Envoy │────→│ Backend │ │ | │ Sidecar │ │ Check │ │ Sidecar │ │ Service │ │ | │ (source) │ │ (同步!) │ │ (dest) │ │ │ │ | └──────────┘ └──────────┘ └──────────┘ └──────────┘ │ | │ │ | 每次请求都要等待! │ | P99延迟 5-20ms │ | | | 更可怕的在后面: | | ┌──────────┐ ┌──────────┐ ┌──────────┐ │ | │ Envoy │ │ Mixer │ │ Adapter │ │ | │ Sidecar │────→│ Report │────→│ (例如 │ │ | │ │ │ (异步) │ │Prometheus│ │ | └──────────┘ └──────────┘ └──────────┘ │ | │ | | 采集数据 转发 | | CPU开销 内存开销 | | | | 问题总结: | | 1. Check是同步的 → 每个请求都增加延迟 | | 2. Mixer是集中式的 → 是所有Envoy的瓶颈 | | 3. Adapter处理增加复杂度 → 内存泄漏风险 | | 4. 横向扩展困难 → Mixer的gRPC连接数有限 | | | ------------------------------------------------------------------5.2 具体数据来自官方测试# Istio 1.4版本的性能测试数据 场景1000 QPS的HTTP请求 配置 P50延迟 P99延迟 CPU(Envoy) CPU(Mixer) ───────────────────────────────────────────────────────────────────── 无Mixer 5ms 15ms 10% - Mixer(Check only) 8ms 25ms 12% 30% Mixer(CheckReport) 10ms 35ms 15% 50% Mixer(多Adapter) 15ms 60ms 18% 80% 结论Mixer增加50%-300%的延迟CPU开销也是重要因素六、Mixer废弃后的迁移路径# 从Mixer迁移到ALS的步骤# Step 1: 移除Mixer相关配置kubectl delete handler skywalking-handler-n istio-system kubectl delete rule skywalking-rule-n istio-system kubectl delete instance skywalking-instance-n istio-system# Step 2: 更新Istio版本到1.5istioctl upgrade# Step 3: 配置ALSEnvoyFilterkubectl apply-f envoy-filter-als.yaml# Step 4: 验证kubectl logs-n istio-system deployment/skywalking-oap|grep ALS七、Mixer模式的教训Istio Mixer的故事给分布式系统设计上了一课不要在热点路径上添加同步调用——Mixer的Check就是典型的反面教材集中式数据收集需要考虑规模——单点瓶颈比分布式问题更难解决Sidecar模式的价值——为什么Mixer不能直接内嵌到Envoy中后来的WASM方向正是这个思路API设计要考虑未来变化——Mixer的Adapter API过于灵活反而导致碎片化八、总结Mixer模式虽然已被废弃但它的设计思想和教训仍值得学习方面启示设计理念集中式管理在分布式系统中往往失败性能不要在关键路径上同步等待外部服务扩展性Adapter模式增加了复杂度可维护性简单即正确下一篇我们将学习Istio推荐的ALSAccess Log Service模式。下一篇【第66篇】SkyWalking观测Service Mesh——挑战、混合部署与统一拓扑图上一篇【第68篇】SkyWalking观测Istio ALS模式——Envoy AccessLog直连OAP的完整配置指南