下一篇【第61篇】数据上报通信扩展——用Kafka传输Trace数据的完整实战上一篇【第63篇】监控SkyWalking本身——别让你的APM成为盲点一、各通信方案全景对比------------------------------------------------------------------ | gRPC vs HTTP vs Kafka 三维对比 | ------------------------------------------------------------------ | | | 维度 gRPC HTTP Kafka | | ─────────────────────────────────────────────────────────────── │ | 序列化协议 Protobuf JSON/Protobuf 自定义 | | 传输方式 长连接(HTTP/2) 短连接(HTTP/1.1) 异步消息 | | 性能 ★★★★★ ★★★ ★★★★ | | 延迟 ~5ms ~20ms ~10-50ms | | 吞吐量 高 中 极高 | | 可靠性 中(连接断开) 中(网络波动) 高(持久化) | | | | 防火墙友好 ★★ ★★★★ ★★★ | | 代理/负载均衡 需特殊支持 原生支持 无需 | | 实现复杂度 低(官方内置) 中(需扩展) 低(官方内置) | | 运维复杂度 低 低 中 | | 额外依赖 无 无 Kafka集群 | | | | 双向通信 原生支持 需轮询 需额外Topic | | 数据缓冲 × × ✓ | | 批量发送 支持(流) 需手动实现 原生支持 | | 连接管理 Channel池 连接池 Producer池 | | | | 适用Agent数 500 200 500 | | 适用数据量 中等 少 大 | | 适用网络环境 稳定 受限 各种 | | | ------------------------------------------------------------------二、各方案详评2.1 gRPC —— 默认选择最适合中小规模优势清单零额外依赖Agent原生支持序列化效率最高Protobuf二进制格式双向流支持Agent ↔ OAP 可以双向通信HTTP/2多路复用单连接承载大量请求劣势清单gRPC端口可能被防火墙拦截不支持标准的HTTP代理长连接断开后需要重连逻辑2.2 HTTP —— 网络受限环境的最爱优势清单天然穿透防火墙80/443端口支持HTTP代理调试方便curl/Postman可直接测试劣势清单每次请求建立连接HTTP/1.1JSON序列化效率低没有原生流式支持SkyWalking官方支持度较低2.3 Kafka —— 大规模场景的标配优势清单消息持久化不怕OAP宕机天然的削峰填谷能力消费可回溯重新消费历史数据消费者组天然支持OAP水平扩展劣势清单需要额外的Kafka集群数据延迟比gRPC高10-50ms运维复杂度增加需要监控Kafka的Consumer Lag三、网络受限环境下的方案选择在企业级部署中网络环境是最常见的阻碍因素。不同的网络受限场景需要不同的应对策略。------------------------------------------------------------------ | 网络受限场景与对应方案 | ------------------------------------------------------------------ | | | 场景1: Agent和OAP在同一VPC但不同安全组 | | ┌────────────────────────────────────────────┐ │ | │ 解决方案: gRPC (打开11800端口) │ │ | │ 配置: 安全组添加入站规则 │ │ | │ 允许 Agent网段 → OAP:11800 │ │ | └────────────────────────────────────────────┘ │ | | | 场景2: Agent在公网OAP在VPC云环境 | | ┌────────────────────────────────────────────┐ │ | │ 解决方案: HTTP或Kafka │ │ | │ - HTTP: 在OAP前面加Nginx反向代理 │ │ | │ - Kafka: 走公网Kafka(SASL加密) │ │ | │ 注意: 必须开启TLS/认证 │ │ | └────────────────────────────────────────────┘ │ | | | 场景3: 跨云/混合云AWS → 阿里云 │ | ┌────────────────────────────────────────────┐ │ | │ 解决方案: Kafka (推荐) │ │ | │ - 每个云部署独立的Kafka Cluster │ │ | │ - 使用MirrorMaker做跨云复制 │ │ | │ - OAP在目标云消费 │ │ | │ 或: 在每个云部署独立的SkyWalking集群 │ │ | │ 通过UI聚合显示 │ │ | └────────────────────────────────────────────┘ │ | | | 场景4: 只有80/443端口可用 | | ┌────────────────────────────────────────────┐ │ | │ 解决方案: HTTP Nginx │ │ | │ Agent → Nginx(443) → OAP(12800) │ │ | │ 使用HTTP/2提高性能 │ │ | └────────────────────────────────────────────┘ │ | | ------------------------------------------------------------------四、通信层压力测试通信方案选好了但你的配置能不能扛住实际流量压力测试来验证# # 用wrk测试OAP的gRPC/HTTP接收能力# # 1. 测试HTTP接收端如果启用了HTTP扩展wrk-t4-c100-d60s--latency\-strace-segment.lua\http://oap-server:12800/receive# 输出示例# Running 1m test http://oap-server:12800/receive# 4 threads and 100 connections# Thread Stats Avg Stdev Max /- Stdev# Latency 8.23ms 3.12ms 45.67ms 89.01%# Req/Sec 3.05k 452.34 4.23k 75.33%# Latency Distribution# 50% 7.12ms# 75% 9.45ms# 90% 12.34ms# 99% 18.67ms# 732456 requests in 1.00m, 856.23MB read# Requests/sec: 12207.60# 2. 测试Kafka写入kafka-producer-perf-test.sh\--topicskywalking-segments\--num-records1000000\--record-size1024\--throughput50000\--producer-propsbootstrap.serverslocalhost:9092\acksall4.1 压测结果解读指南------------------------------------------------------------------ 通信层压测关键指标 ------------------------------------------------------------------ | | | 指标 健康值 危险值 处理方式 | | ─────────────────────────────────────────────────────────────── │ | P99延迟 50ms 200ms 检查资源/降级 | | 错误率 0.1% 1% 检查连接/重试 | | 吞吐量 5000/s 1000/s 横向扩展 | | Kafka Consumer 1000 10000 增加消费者 | | Lag | | | | 压测环境配置建议: | | - 与生产环境相同规格的服务器 | | - 模拟生产级别的Trace数据非空数据 | | - 同时压Agent端和OAP端 | | - 跑至少30分钟排除JIT预热影响 | | | ------------------------------------------------------------------五、通信超时与重试配置通信不可避免会遇到超时。合理的超时与重试配置可以显著提高数据可靠性。5.1 gRPC超时配置# agent/config/agent.config# gRPC Channel配置collector.grpc_channel_check_interval30# Channel健康检查间隔(秒)collector.backend_service127.0.0.1:11800# OAP地址collector.grpc_upstream_timeout30# 上游数据上报超时(秒)# 连接管理collector.heartbeat_period30# 心跳周期(秒)collector.properties.max_retry_timeout300# 最大重试超时(秒)5.2 HTTP超时配置# 自定义HTTP扩展的超时配置http.reporter.connect_timeout5000# 连接超时(ms)http.reporter.read_timeout10000# 读取超时(ms)http.reporter.max_retries3# 最大重试次数http.reporter.retry_backoff1000# 重试退避(ms)http.reporter.max_connections50# 最大连接数http.reporter.max_connections_per_route105.3 Kafka重试配置# Kafka Producer重试配置plugin.kafka.producer_config:retries:5# 重试次数retry.backoff.ms:100# 重试间隔request.timeout.ms:30000# 请求超时delivery.timeout.ms:120000# 投递超时max.in.flight.requests.per.connection:5# 并发请求数# Kafka Consumer配置plugin.kafka.consumer_config:session.timeout.ms:30000# 会话超时heartbeat.interval.ms:3000# 心跳间隔max.poll.interval.ms:300000# 最大轮询间隔六、高可用通信配置------------------------------------------------------------------ 高可用通信架构 ------------------------------------------------------------------ | | | gRPC高可用: | | ┌──────────┐ ┌──────────┐ ┌──────────┐ | | │ Agent │ │ Agent │ │ Agent │ | | └────┬─────┘ └────┬─────┘ └────┬─────┘ | | │ │ │ | | └──────────────┼──────────────┘ | | │ | | ┌───────────┼───────────┐ | | │ │ │ | | ↓ ↓ ↓ | | ┌──────────┐ ┌──────────┐ ┌──────────┐ | | │OAP Node 1│ │OAP Node 2│ │OAP Node 3│ | | │ :11800 │ │ :11800 │ │ :11800 │ | | └──────────┘ └──────────┘ └──────────┘ | | | | 配置: collector.backend_service | | oap1:11800,oap2:11800,oap3:11800 | | Agent会随机选择一个OAP连接 | | | | ─────────────────────────────────────────────────────────────── │ | | | Kafka高可用: | | ┌──────────┐ ┌──────────┐ ┌──────────┐ | | │ Agent │ │ Agent │ │ Agent │ | | └────┬─────┘ └────┬─────┘ └────┬─────┘ | | │ │ │ | | └──────────────┼──────────────┘ | | │ | | ┌───────────┼───────────┐ | | │ │ │ | | ↓ ↓ ↓ | | ┌───────────────────────────────────┐ | | │ Kafka Cluster (3 Broker) │ | | │ ┌───────┐ ┌───────┐ ┌───────┐ │ | | │ │Broker1│ │Broker2│ │Broker3│ │ | | │ └───────┘ └───────┘ └───────┘ │ | | └───────────────┬───────────────────┘ | | │ | | ┌─────────┼─────────┐ | | │ │ │ | | ↓ ↓ ↓ | | ┌──────────┐ ┌──────────┐ ┌──────────┐ | | │OAP Node 1│ │OAP Node 2│ │OAP Node 3│ | | │同一CG │ │同一CG │ │同一CG │ | | │Partition1│ │Partition2│ │Partition3│ | | └──────────┘ └──────────┘ └──────────┘ | | | | 每个OAP消费不同的Partition | | OAP宕机时 → 自动Rebalance → 其他OAP接管 | | | ------------------------------------------------------------------七、终极选型决策树------------------------------------------------------------------ | SkyWalking通信方案选型决策树 | ------------------------------------------------------------------ | | | 你的部署规模 | | ├── 100个Agent | | │ └── → gRPC (默认) ✓ 零额外依赖即开即用 | | │ | | ├── 100-500个Agent | | │ ├── 网络通畅? | | │ │ ├── 是 → gRPC (高可用配置) | | │ │ └── 否 → HTTP Nginx | | │ └── → gRPC 适当调参 | | │ | | └── 500个Agent | | ├── 有Kafka集群? | | │ ├── 是 → Kafka Reporter ✓ 最佳选择 | | │ └── 否 | | │ ├── 愿意维护Kafka? | | │ │ ├── 是 → 搭建Kafka Kafka Reporter | | │ │ └── 否 → gRPC (集群模式调优) | | │ └── → gRPC 集群模式 (退而求其次) | | │ | | 你的网络环境 | | ├── 同VPC/内网 → gRPC | | ├── 跨VPC但有专线 → gRPC | | ├── 跨公网 → Kafka SASL | | ├── 只能走80/443 → HTTP Nginx | | └── 多云/混合云 → 每云独立集群 或 Kafka MirrorMaker | | | | 你的可观测性需求 | | ├── 需要重放历史数据 → Kafka | | ├── 需要极低延迟 → gRPC | | └── 需要高可靠性 → Kafka | | | ------------------------------------------------------------------八、总结三种通信方案没有绝对的最好只有最适合gRPC默认选择简单快速适合中小规模部署HTTP兼容性强适合网络受限环境但性能有限Kafka大规模标配解耦缓冲可靠但有运维成本下一篇文章我们将把视角转回SkyWalking本身——如何监控APM系统自身的运行状态。下一篇【第61篇】数据上报通信扩展——用Kafka传输Trace数据的完整实战上一篇【第63篇】监控SkyWalking本身——别让你的APM成为盲点