可观测性后端微服务云原生【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址https://gitcode.com/gh_mirrors/sky/skywalking点击查看免费下载OAPObservability Analysis Platform服务器在集群环境中通过相互通信完成分布式聚合但默认情况下所有节点都以 Mixed 角色运行。本文以 SkyWalking 官方文档 advanced-deployment.md 为主体结合当前仓库源码系统讲解 OAP 的三种可用角色Mixed、Receiver、Aggregator的职责划分、配置方式、底层实现原理以及如何在 Kubernetes 中按角色拆分部署帮助读者在安全策略和网络策略复杂的生产环境中搭建职责清晰的 OAP 集群。OAP 集群与角色机制概述SkyWalking 的 OAP 服务器在集群环境下会互相通信以便对不同节点接收到的数据进行分布式聚合。在默认的集群模式下所有 OAP 节点都运行在 Mixed混合模式下即每个节点同时承担接收、聚合、持久化等全部职责。然而当集群规模扩大、或面临严格的网络安全与策略要求时用户可能希望集群节点具有清晰定义的职责边界。为此SkyWalking 为 OAP 提供了以下三种角色Mixed默认Receiver接收者Aggregator聚合者这些角色是专为安全策略与网络策略复杂的部署需求而设计的允许用户将接收 Agent 数据与聚合/落库分离到不同的网络分区或部署组中。Mixed 角色默认的完整职责节点Mixed 是 OAP 的默认角色对应源码中CoreModuleConfig.Role枚举的第一个值。在 CoreModuleConfig.java 中其注释明确说明Mixed 角色同时承担 Receiver 与 Aggregator 两份工作。Mixed 模式下单个 OAP 节点负责以下完整链路接收 Agent 的 Trace 或 Metrics 数据通过 gRPC/HTTP 接收探针上报L1 聚合第一级本地聚合即节点内的初步聚合内部通信发送/接收与其他 OAP 节点交换数据L2 聚合第二级分布式聚合跨节点完成最终聚合持久化将聚合结果写入存储告警Alarm基于聚合结果触发告警规则。从源码结构看Mixed 角色下CoreModuleProvider会同时完成接收端、聚合端与持久化端的全部初始化是功能最完整、也最容易被直接使用的部署形态适合中小规模或对网络分区无要求的集群。Receiver 角色专职数据接收与 L1 聚合当 OAP 节点被设置为 Receiver 角色时其职责被收窄为接收 Agent 的 Trace 或 Metrics 数据L1 聚合内部通信发送——将 L1 聚合结果转发给 Mixed 与 Aggregator 角色的 OAP 节点。在 CoreModuleConfig.java 的角色枚举注释中有一个关键细节对于 Record 类型数据如 Trace Segment 记录它们不需要第二轮分布式聚合会由 Receiver 角色的 OAP 节点直接写入存储而 Metrics 类数据则需要经过 L1 聚合后发送给 Aggregator 完成 L2 聚合。这意味着 Receiver 节点是 Agent 流量的入口墙它暴露接收端口、只做本地初步聚合不参与跨节点的二级聚合与持久化Record 数据除外适合部署在更靠近 Agent 的隔离网络区域。Receiver 角色的健康检查差异Receiver 角色的特殊之处在源码中也有体现。OAPNodeChecker.java 的健康检查逻辑为 Receiver 角色做了豁免if (!CoreModuleConfig.Role.Receiver.equals(ROLE)) { ListRemoteInstance selfInstances remoteInstances.stream() .filter(remoteInstance - remoteInstance.getAddress().isSelf()) .collect(Collectors.toList()); if (CollectionUtils.isEmpty(selfInstances)) { return ClusterHealthStatus.unHealth(cant get itself); } }即非 Receiver 角色要求集群实例列表中存在自身实例而 Receiver 角色不要求在集群中发现自身因为 Receiver 节点只向集群发送数据、不注册为接收方。该行为由测试 OAPNodeCheckerTest.java 中的healthWhenReceiverRoleWithEmptySelfInstance用例验证。Aggregator 角色专职二级聚合与持久化Aggregator 角色与 Receiver 形成互补其职责为内部通信接收——接收来自 Receiver 与 Mixed 角色 OAP 节点的数据L2 聚合持久化告警。Aggregator 节点不直接接收 Agent 数据只消费集群内部转发的 L1 聚合结果完成跨节点的第二轮分布式聚合后写入存储并基于最终数据执行告警逻辑。它适合部署在存储层附近的安全区域与暴露在公网/边缘的 Receiver 节点物理隔离。三种角色职责对比职责Mixed默认ReceiverAggregator接收 Agent Trace/Metrics✅✅❌L1 聚合✅✅❌内部通信发送✅✅❌内部通信接收✅❌✅L2 聚合✅❌✅持久化✅❌Record 数据除外✅告警✅❌✅角色配置方法application.yml 与 SW_CORE_ROLEOAP 的角色通过核心模块core配置项role指定默认值为Mixed。在默认配置文件中 application.yml 可以找到core: selector: ${SW_CORE:default} default: # Mixed: Receive agent data, Level 1 aggregate, Level 2 aggregate # Receiver: Receive agent data, Level 1 aggregate # Aggregator: Level 2 aggregate role: ${SW_CORE_ROLE:Mixed} # Mixed/Receiver/Aggregator对应的 Java 配置字段定义在 CoreModuleConfig.javaprivate String role Mixed;因此配置角色有三种等价方式直接修改 application.yml将core.default.role改为Receiver或Aggregator通过环境变量覆盖设置SW_CORE_ROLEReceiver或Aggregator无需改动文件这也是容器化与 Kubernetes 部署推荐的注入方式通过启动脚本/系统属性注入与其它SW_CORE_*环境变量风格保持一致。角色名大小写不敏感CoreModuleConfig.Role.fromName()使用equalsIgnoreCase匹配未知的名称会回退到默认的Mixed。源码视角角色如何在启动流程中生效角色的生效路径贯穿 OAP 启动的多个环节核心逻辑集中在 CoreModuleProvider.java 中远程注册registerRemote在start()阶段L401-L409只有Mixed与Aggregator角色会把自身 gRPC 地址注册为RemoteInstance并加入集群协调器if (CoreModuleConfig.Role.Mixed.name().equalsIgnoreCase(moduleConfig.getRole()) || CoreModuleConfig.Role.Aggregator.name().equalsIgnoreCase(moduleConfig.getRole())) { RemoteInstance gRPCServerInstance new RemoteInstance(gRPCServerInstanceAddress); coordinator.registerRemote(gRPCServerInstance); }这从实现上印证了文档所述Receiver 节点只向集群发送数据不把自己注册为接收方而 Mixed 与 Aggregator 需要被其它节点发现以接收内部数据。角色写入静态检查器随后执行OAPNodeChecker.setROLE(CoreModuleConfig.Role.fromName(moduleConfig.getRole()))供健康检查逻辑见上文 Receiver 豁免逻辑使用。L2 聚合的输入来源Aggregator 节点的 L2 聚合 Worker 消费来自RemoteSenderService的远程数据这些数据由 Mixed/Receiver 节点通过内部 gRPC默认端口11800配置项gRPCPort发送从而形成Receiver 收 → Aggregator 聚 → 存储的分层数据流。角色拆分的典型适用场景根据文档说明这些角色专为复杂的安全与网络策略部署需求设计。典型的拆分场景包括网络分区隔离Receiver 节点部署在允许 Agent 接入的非安全区Aggregator 节点部署在与存储同处的安全区两者之间仅通过受控的内部 gRPC 端口通信Agent 无法直接触达聚合与存储节点职责与权限收敛减少暴露面使每个节点的最小权限原则更容易落地例如只有 Aggregator 具备存储凭据与告警通道容量规划接收密集型场景可以独立扩容 Receiver 节点聚合密集型场景独立扩容 Aggregator 节点避免互相干扰。Kubernetes 环境下的角色拆分部署当使用 SkyWalking 原生 Kubernetes 协调器 时如果坚持按角色安装 OAP 节点文档给出了明确的部署要求为每种角色创建独立的 Deployment即一套 Deployment 部署 Receiver 角色的 OAP另一套部署 Aggregator 角色的 OAP从而将两种不同的系统环境配置分离开来为 Aggregator 角色设置labelSelectorKubernetes 集群协调器通过labelSelector选择参与集群的 Pod因此需要为 Aggregator 角色设置对应的选择规则让集群发现正确的 OAP Deployment。Kubernetes 协调器中的 labelSelector 配置在默认配置 application.yml 中Kubernetes 集群协调器的配置为cluster: kubernetes: namespace: ${SW_CLUSTER_K8S_NAMESPACE:default} labelSelector: ${SW_CLUSTER_K8S_LABEL:appcollector,releaseskywalking} uidEnvName: ${SW_CLUSTER_K8S_UID:SKYWALKING_COLLECTOR_UID}namespaceOAP Pod 所在的 Kubernetes 命名空间默认defaultlabelSelector用于发现 OAP Pod 的标签选择器默认appcollector,releaseskywalking。当按角色拆分 Deployment 时应为 Aggregator 角色的 Deployment 设置独立标签并同步调整此处的选择器uidEnvName标识当前 Pod 唯一 UID 的环境变量名用于区分自身实例默认SKYWALKING_COLLECTOR_UID。从实现上看KubernetesCoordinator.java 通过NamespacedPodListInformer监听命名空间内的 Pod 事件ADDED/MODIFIED/DELETED把 Pod IP 列表转换为RemoteInstance列表并通知集群协调器只有处于Running阶段的 Pod 才会被加入实例集合L181-L182。因此labelSelector必须精确命中目标角色的 Pod才能让 Aggregator 正确接收 Receiver/Mixed 转发的数据。Kubernetes 部署示意以下为按角色拆分部署的概念示意两套 Deployment 各自的角色配置# Receiver 角色 Deployment 的核心配置片段 env: - name: SW_CORE_ROLE value: Receiver - name: SW_CLUSTER value: kubernetes - name: SW_CLUSTER_K8S_LABEL value: appskywalking-oap-aggregator # 指向 Aggregator 的选择规则 - name: SW_CORE_GRPC_HOST value: 0.0.0.0# Aggregator 角色 Deployment 的核心配置片段 env: - name: SW_CORE_ROLE value: Aggregator - name: SW_CLUSTER value: kubernetes - name: SW_CLUSTER_K8S_LABEL value: appskywalking-oap-aggregator要点总结Receiver 与 Aggregator 两套 Deployment 使用相同的命名空间与 labelSelector 规则时Aggregator 才能发现集群中的接收节点数据实际标签值请以你的 Deployment 标签为准Mixed 与 Aggregator 角色会被注册为可接收内部数据的节点而 Receiver 不注册自身因此集群协调器发现的节点集合主要由 Mixed/Aggregator 构成若集群中同时存在多角色节点建议通过namespace命名空间与labelSelector组合隔离避免 Receiver Pod 被误纳入聚合数据消费链路。总结SkyWalking OAP 的 Mixed / Receiver / Aggregator 三种角色为集群部署提供了从全功能节点到职责分离的弹性选择Mixed 适合默认与简单场景Receiver 专注数据接收与 L1 聚合将 Record 直接落库Aggregator 专注 L2 聚合、持久化与告警。配合环境变量SW_CORE_ROLE与 Kubernetes 协调器的labelSelector配置可以在安全策略与网络策略复杂的环境中快速搭建职责清晰、分区隔离的 OAP 集群。相关实现细节可进一步阅读 CoreModuleConfig.java、CoreModuleProvider.java 与 KubernetesCoordinator.java。赞分享可观测性后端微服务云原生【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址https://gitcode.com/gh_mirrors/sky/skywalking点击查看免费下载相关推荐Apache SkyWalking OAP 高级部署理解 Mixed / Receiver / Aggregator 三种角色与 Kubernetes 集群拆分实践Apache SkyWalking OAP 高级部署理解 Mixed / Receiver / Aggregator 三种角色与 Kubernetes 集群拆可观测性APM链路追踪指标监控日志分析微服务Vector 部署角色详解AgentDaemon/Sidecar与 Aggregator 角色的选择与组合Vector 部署角色详解AgentDaemon/Sidecar与 Aggregator 角色的选择与组合 Vector 是一个端到端的数据管道obse可观测性数据工程数据集成日志分析Vector 部署指南Agent 与 Aggregator 角色、三大拓扑选型及 Kubernetes 清单解析Vector 部署指南Agent 与 Aggregator 角色、三大拓扑选型及 Kubernetes 清单解析 本文基于 Vector 官方文档中的部署D可观测性数据工程数据集成日志分析上一篇FlutterBoost深色模式实现原生与Flutter主题统一管理下一篇DiT中的EMA机制update_ema函数实现与效果分析创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考