使用 SkyWalking-Satellite 为 Apache SkyWalking OAP 集群构建 gRPC 负载均衡与水平扩展【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sky/skywalking本文基于 docs/en/academy/scaling-with-apache-skywalking.md 展开系统讲解 Apache SkyWalking 观测数据链路中 OAP 集群面临的负载失衡与扩容挑战以及 Apache SkyWalking 官方的解决思路以 SkyWalking-Satellite 作为 gRPC 代理网关结合路由算法与 Kubernetes HPA 实现数据流的负载均衡与弹性伸缩。读完本文你将掌握 gRPC 场景下代理 vs 客户端侧两种负载均衡路线的取舍、同步/异步两种传输策略、Round-Robin / Weight Round-Robin / Fixed 三种路由算法的适用场景并能独立完成一套基于 Bookinfo Istio ALS SWCK HPA 的端到端扩容演练。背景OAP 集群的负载失衡与扩容挑战在 Apache SkyWalking 生态中OAPObservability Analysis Platform通过 SkyWalking Agent、Envoy 或其他数据源获取指标metrics、链路traces、日志logs与事件event数据。在 gRPC 协议下数据源通常与单个服务器节点通信传输数据只有连接断开时才会基于 DNS 轮询DNS round-robin模式触发重连策略。这种单节点长连接的通信模型在以下两类场景中会暴露出明显问题运行时新增服务运行期间不断有新的被观测服务接入此时 OAP 集群需要横向扩容以应对增长的数据流量既有节点负载偏高当被观测服务的流量上升、OAP 负载持续处于高位时需要扩展 OAP 集群。但新扩容出的 OAP 节点负载会很低——因为所有存量 Agent 已经连接到旧节点上新节点分不到连接。即使不做扩容OAP 节点之间的负载也可能天然不均衡Agent 在启动阶段采用随机策略选择连接目标且连接一旦建立就会长期保持。因此如何在需要时顺利扩容、并让所有节点保持健康状态就成了一道需要专门设计的难题。本文将重点讨论 SkyWalking 是如何解决这一挑战的。负载均衡的两种路线代理Proxy还是客户端侧Client-sideSkyWalking 主要使用 gRPC 协议进行数据传输因此负载均衡的讨论也聚焦于 gRPC 场景。根据 gRPC 官方负载均衡博客的归纳业界存在两种实现路线客户端侧Client-side客户端感知到多个后端服务使用某种负载均衡算法为每次 RPC 调用选择一个后端服务代理Proxy客户端把消息发送给代理服务器由代理服务器将消息负载均衡地分发到后端服务。从可观测性系统的架构视角看二者的优劣可以总结为下表优点缺点Client-side消除了额外一跳性能更高客户端实现复杂需要集群感知、负载均衡、健康检查等能力要求每个数据源客户端都具备这种复杂能力Proxy客户端实现简单延迟更高SkyWalking 选择Proxy 模式理由如下可观测数据对时间并不敏感传输带来的少量延迟可以接受多一跳对客户端侧没有影响作为可观测性平台SkyWalking 不能也不应该要求客户端做出改变——客户端各有各的技术选型与商业考量。从仓库配套文档 docs/en/setup/backend/backend-load-balancer.md 也可以看到同样的定位SkyWalking-Satellite 被推荐作为原生网关代理在 Agent/Envoy 数据到达 OAP 之前提供基于数据内容的负载均衡能力其与 Envoy 等通用代理的最大区别在于它按数据内容content而非连接connection进行路由因为 gRPC 流streaming在 SkyWalking 中被广泛使用。传输策略同步 vs 异步批处理在代理模式下需要确定下游客户端与上游OAP之间的传输路径。不同数据协议需要不同的处理策略主要分为两种同步Synchronous适用于需要与客户端进行数据交换的协议例如SkyWalking 动态配置服务Dynamic Configuration Service。这类协议提供实时结果要求代理在收到客户端消息时立即把消息转发给上游服务器并同步将响应数据返回给下游客户端。整体流程为客户端发送请求到 Proxy → Proxy 同步发送消息到服务器 → Proxy 收到结果后返回给客户端。通常只有少数协议需要同步策略。异步批处理Asynchronous Batch当客户端不关心上游处理结果、只关心数据是否被传输时例如链路上报、日志上报等采用异步批处理策略。这是更常见的策略——SkyWalking 中的大多数协议本质上都是数据上报。官方认为使用队列作为缓冲区能取得很好的效果执行步骤如下Proxy 接收到数据将其封装为 Event 对象Event 被加入队列当达到周期时间cycle time或队列元素达到固定数量时队列中的元素被并行消费并发送到 OAP。使用队列的好处分离数据接收与发送降低相互影响利用间隔量化机制合并事件加快向 OAP 的发送速度多线程消费队列事件更充分地利用网络 IO。流程可概括为Proxy 收到消息 → 封装为 Event 推入队列 → 消息发送器从队列批量取出事件并发送到上游 OAP。这一队列缓冲 批量消费的设计理念与 OAP 集群内部的数据处理架构一脉相承。在 oap-server/server-core 中集群内节点间通过RemoteSenderService见 RemoteSenderService.java发送流式数据同样以StreamData为载体、通过选择器Selector决定投递目标。路由算法把消息路由到单一上游节点路由算法用于把消息路由到单一上游服务器节点。SkyWalking 讨论了三种候选算法Round-Robin轮询按顺序从上游服务节点列表中依次选择节点。优点是每个节点被选中的次数平均当每条数据的大小接近时每个上游节点能处理相同数量的数据内容。Weight Round-Robin加权轮询每个上游节点都有对应的路由权重比例。与 Round-Robin 的区别在于每个上游节点根据其权重获得更多被路由的机会。当上游服务器节点的机器配置不一致时该算法更适用。Fixed固定路由混合算法这是一个混合算法能够保证相同的数据被路由到同一个上游服务器节点即使上游扩容仍然保持路由到同一节点除非该节点不存在才会重新路由。该算法主要用于SkyWalking Meter 协议因为该协议需要保证同一服务实例的指标发送到同一个 OAP 节点。Fixed 算法的路由步骤如下基于数据内容生成一个唯一标识字符串尽可能短使数据量可控从LRU Cache中获取该标识对应的上游节点若存在则直接使用根据标识生成对应的哈希值从上游节点列表中查找目标节点将上游节点 ↔ 标识的映射关系保存到 LRU Cache。该算法的优点是把数据与上游节点尽量绑定让上游服务器能更好地处理连续数据缺点是保存映射关系需要占用一定内存空间。SkyWalking 的最终选择SkyWalking 最终采用Round-Robin 与 Fixed 的组合Fixed 路由算法适用于特定协议主要用于 SkyWalking Meter 协议传递指标数据时Round-Robin 算法作为默认算法。当 SkyWalking OAP 集群部署时要求各节点配置尽量一致因此无需使用 Weight Round-Robin 算法。有趣的是OAP 集群内部的节点间数据路由也采用了类似的设计。在 oap-server/server-core/src/main/java/org/apache/skywalking/oap/server/core/remote/selector 包中定义了三种RemoteClientSelector实现RollingSelector.java轮询选择远端节点HashCodeSelector.java对StreamData.remoteHashCode()取模定位节点Math.abs(streamData.remoteHashCode()) % size与 Fixed 算法的哈希取模思想一致ForeverFirstSelector.java固定选择第一个节点。例如指标数据在集群内分发时使用Selector.HashCode见 MetricsRemoteWorker.java这与网关侧Fixed 路由保证同一实例指标落到同一 OAP的目标相互呼应从源码层面印证了按内容绑定节点的稳定性设计。负载均衡器自身的负载均衡Proxy 集群怎么分压Proxy 仍然需要解决从客户端到 Proxy 自身的负载均衡问题尤其是在生产环境部署Proxy 集群时。官方提出了三种候选方案连接管理Connection management集群感知Cluster awareness资源限制 HPAResource limit HPA优点使用简单保证每个 Proxy 的连接数相对均衡使用简单缺点每个客户端需要确保数据不丢失客户端需要接受 GOAWAY 响应可能导致某些节点流量突增每个客户端需要确保数据不丢失各实例间的流量不会特别均衡三种方案的具体说明连接管理在客户端侧使用max_connection配置指定每条连接的最大连接时长详见 gRPC A9 server-side connection management 提案。到期的连接由服务端主动断开促使客户端重新选择节点集群感知Proxy 具备集群感知能力当负载不均衡时主动断开连接让客户端重新挑选 Proxy资源限制 HPA限制每个 Proxy 的连接资源达到资源上限后不再接受新连接同时利用 Kubernetes 的 HPAHorizontal Pod Autoscaler机制动态扩展 Proxy 数量。SkyWalking 选择Limit HPA理由如下配置和使用简单基于基础数据指标即可理解不会因连接断开丢失数据——客户端无需实现任何防止数据丢失的额外协议尤其当客户端是商业产品时这一点很关键Proxy 集群中各节点的连接数不需要特别均衡只要 Proxy 节点本身高性能即可。SkyWalking-Satellite官方实现的代理网关上述 Proxy 已在SkyWalking-Satellite项目中实现部署于 Client 与 SkyWalking OAP 之间有效解决负载均衡问题。系统部署完成后Satellite 会接收来自 Client 的流量并通过Kubernetes Label Selector或手动配置感知 OAP 的所有节点将流量负载均衡到上游 OAP 节点。典型拓扑为单个客户端与单个 Satellite 保持连接Satellite 与每个 OAP 建立连接并把消息均衡地分发到 OAP 节点。当需要扩展 Satellite 时需要部署SWCKSkyWalking Cloud on Kubernetes适配器并在 Kubernetes 中配置 HPA。SWCK 是面向 SkyWalking 用户的平台负责在 Kubernetes 上供给provision、升级、维护 SkyWalking 相关组件使其原生地运行在 Kubernetes 之上。部署完成后自动扩容按以下步骤进行从 OAP 读取指标HPA 请求 SWCK 指标适配器动态读取 OAP 中的指标扩容 SatelliteKubernetes HPA 感知到指标值符合预期后自动对 Satellite 进行扩容。即HPA 通过 SWCK Adapter 读取 OAP 中的指标当达到阈值时HPA 对 Satellite 的 Deployment 进行扩容。结合仓库Satellite 的观测指标从哪来SWCK Adapter 读取的指标依赖 Satellite 的自观测能力。根据 docs/en/setup/backend/dashboards-so11y-satellite.mdSkyWalking Satellite 会以Prometheus 格式和SkyWalking metrics service protobuffer 格式收集并导出自身指标然后推送到 SkyWalking OAPOAP 使用 MALMetrics Analysis Language 解析表达式进行过滤/计算/聚合后存储结果。卫星自观测的核心指标包括指标名单位描述数据来源satellite_service_grpc_connect_countCount连接数SkyWalking Satellitesatellite_service_server_cpu_utilizationPercentageCPU 使用率%SkyWalking Satellitesatellite_service_queue_used_countCountpipeline 队列已使用数SkyWalking Satellitesatellite_service_receive_event_countCount从下游接收的事件数SkyWalking Satellitesatellite_service_fetch_event_countCount从下游获取的事件数SkyWalking Satellitesatellite_service_queue_input_countCount推入队列的事件数SkyWalking Satellitesatellite_service_send_event_countCount推送到上游的数据事件数SkyWalking Satellite其中satellite_service_grpc_connect_count正是后文 HPA 演练中用于驱动自动扩容的核心指标。结合仓库OAP 侧接收端配置解析要让 Satellite 把流量正确送到 OAPOAP 侧需要开启对应的接收端并配置 gRPC 监听。以 Envoy ALSAccess Log Service为例在 oap-server/server-starter/src/main/resources/application.yml 中envoy-metric模块的默认配置如下envoy-metric: selector: ${SW_ENVOY_METRIC:default} default: acceptMetricsService: ${SW_ENVOY_METRIC_SERVICE:true} alsHTTPAnalysis: ${SW_ENVOY_METRIC_ALS_HTTP_ANALYSIS:} alsTCPAnalysis: ${SW_ENVOY_METRIC_ALS_TCP_ANALYSIS:} # k8sServiceNameRule 允许通过 Kubernetes 元数据自定义 ALS 中的服务名 k8sServiceNameRule: ${K8S_SERVICE_NAME_RULE:${pod.metadata.labels.(service.istio.io/canonical-name)}.${pod.metadata.namespace}} istioServiceNameRule: ${ISTIO_SERVICE_NAME_RULE:${serviceEntry.metadata.name}.${serviceEntry.metadata.namespace}} istioServiceEntryIgnoredNamespaces: ${SW_ISTIO_SERVICE_ENTRY_IGNORED_NAMESPACES:} gRPCHost: ${SW_ALS_GRPC_HOST:0.0.0.0} gRPCPort: ${SW_ALS_GRPC_PORT:0} maxConcurrentCallsPerConnection: ${SW_ALS_GRPC_MAX_CONCURRENT_CALL:0} maxMessageSize: ${SW_ALS_GRPC_MAX_MESSAGE_SIZE:0} gRPCThreadPoolSize: ${SW_ALS_GRPC_THREAD_POOL_SIZE:0} gRPCSslEnabled: ${SW_ALS_GRPC_SSL_ENABLED:false} gRPCSslKeyPath: ${SW_ALS_GRPC_SSL_KEY_PATH:} gRPCSslCertChainPath: ${SW_ALS_GRPC_SSL_CERT_CHAIN_PATH:} gRPCSslTrustedCAsPath: ${SW_ALS_GRPC_SSL_TRUSTED_CAS_PATH:}关键环境变量说明SW_ALS_GRPC_PORTALS gRPC 服务端口默认0表示与核心 gRPC 端口共用即默认的 11800 端口。若设置为非0值例如11802ALS 流量将走独立端口——这正对应 backend-load-balancer.md 中将 ALS 连接拆到专用端口避免连接数限流把 ALS 与 metrics 两类连接挤到一个 OAP的实践SW_ENVOY_METRIC_ALS_HTTP_ANALYSIS/SW_ENVOY_METRIC_ALS_TCP_ANALYSIS指定 ALS 分析器支持k8s-mesh、mx-mesh、persistence多个用逗号拼接作为快速成功链SW_ENVOY_METRIC_SERVICE是否接受 Envoy Metrics Service 上报默认true。这些配置项在源码 EnvoyMetricReceiverConfig.java 中被逐一解析ALS 的 gRPC 请求由 AccessLogServiceGRPCHandlerV3.java 与SatelliteAccessLogServiceGRPCHandlerV3.java处理。ALS 分析器的完整说明可参考 docs/en/setup/envoy/als_setting.mdk8s-mesh基于 Kubernetes 集群元数据OAP 需要对Pod、Service、Endpoints具有访问权限mx-mesh基于 Envoy 元数据交换metadata exchange机制获取服务名要求 Istio 开启 metadata exchange 插件Istio 1.7 使用demo/previewprofile 安装时默认开启persistence将 Envoy 访问日志适配为 SkyWalking 原生日志格式转发给 LAL 处理需在log-analyzer/default/lalFiles或环境变量SW_LOG_LAL_FILES中激活envoy-als规则且需要前置配置k8s-mesh或mx-mesh之一来定位日志所属服务。备选方案不使用 Satellite 时用 EnvoyFilter 限制每 OAP 实例连接数如果不想部署 SkyWalking-Satellitebackend-load-balancer.md 还提供了第二种手段为 OAP Pod 开启 Istio sidecar 注入并用 EnvoyFilter 限制每个 OAP 实例的连接数使各 OAP 实例的 gRPC 连接数大致相等。连接数估算方式为NUMBER_OF_SERVICE_PODS被 SkyWalking 监控的服务 Pod 数量 # 每个服务 Pod 到 OAP 有 2 条连接 NUMBER_OF_TOTAL_CONNECTIONS$((NUMBER_OF_SERVICE_PODS * 2)) # 除以 OAP 副本数得到每实例连接上限 NUMBER_OF_CONNECTIONS_PER_OAP$((NUMBER_OF_TOTAL_CONNECTIONS / $NUMBER_OF_OAP_REPLICAS))再通过envoy.filters.network.ConnectionLimit网络过滤器对 11800 端口或SW_ALS_GRPC_PORT指定的专用 ALS 端口做连接数限制。该方案属于连接级均衡当服务 Pod 数量极大时仍可能出现极端失衡例如一个 OAP 实例承接全部 Envoy metrics 连接、另一个承接全部 ALS 连接因此官方文档建议优先使用 Satellite。端到端演练Bookinfo Istio ALS Satellite SWCK HPA以下示例演示两个场景SkyWalking ScalingSkyWalking OAP 扩容后流量通过 Satellite 自动负载均衡Satellite ScalingSatellite 自身的流量负载均衡基于 HPA 自动扩容。示例使用Apache SkyWalking 8.9.1与Apache SkyWalking-Satellite 0.5.0通过Bookinfo 应用与Envoy ALS 协议观测服务网格。开始前请确保已有一个可用的 Kubernetes 环境。注以下命令来自原文档配套的演示脚本仓库sw-satellite-demo-scripts版本固定的资源文件以5821a909...commit 引用。场景一SkyWalking Scaling1. 安装 IstioIstio 提供了非常便捷的方式来配置 Envoy 代理并启用访问日志服务ALS步骤为本地安装 istioctl 管理网格 → 以 demo 配置 profile 安装 Istio 并启用 Envoy ALS将 ALS 消息发送给稍后部署的 Satellite → 给 default 命名空间打标签使 Istio 在部署应用时自动注入 Envoy sidecar# install istioctl export ISTIO_VERSION1.12.0 curl -L https://istio.io/downloadIstio | sh - sudo mv $PWD/istio-$ISTIO_VERSION/bin/istioctl /usr/local/bin/ # install istio istioctl install -y --set profiledemo \ --set meshConfig.enableEnvoyAccessLogServicetrue \ --set meshConfig.defaultConfig.envoyAccessLogService.addressskywalking-system-satellite.skywalking-system:11800 # enable envoy proxy in default namespace kubectl label namespace default istio-injectionenabled注意envoyAccessLogService.address指向的是skywalking-system-satellite.skywalking-system:11800——即** Satellite 服务**而不是 OAP 直连地址。这正是Proxy 模式的落地Envoy 只与 Satellite 建立连接。2. 安装 SWCKSWCK 方便用户在 Kubernetes 上部署和升级 SkyWalking 相关组件Satellite 的自动伸缩功能也主要依赖 SWCK# Install cert-manager kubectl apply -f https://github.com/jetstack/cert-manager/releases/download/v1.3.1/cert-manager.yaml # Deploy SWCK mkdir -p skywalking-swck cd skywalking-swck wget https://dlcdn.apache.org/skywalking/swck/0.6.1/skywalking-swck-0.6.1-bin.tgz tar -zxvf skywalking-swck-0.6.1-bin.tgz cd config kubectl apply -f operator-bundle.yaml3. 部署 Apache SkyWalking 与 Apache SkyWalking-Satellite使用官方提供的脚本一键部署 SkyWalking OAP、UI 与 Satellite# Create the skywalking components namespace kubectl create namespace skywalking-system kubectl label namespace skywalking-system swck-injectionenabled # Deploy components kubectl apply -f https://raw.githubusercontent.com/mrproliu/sw-satellite-demo-scripts/5821a909b647f7c8f99c70378e197630836f45f7/resources/sw-components.yamlswck-injectionenabled标签确保 SWCK 能够管理该命名空间下的 SkyWalking 组件。4. 部署 Bookinfo 应用export ISTIO_VERSION1.12.0 kubectl apply -f https://raw.githubusercontent.com/istio/istio/$ISTIO_VERSION/samples/bookinfo/platform/kube/bookinfo.yaml kubectl wait --forconditionReady pods --all --timeout1200s kubectl port-forward service/productpage 9080然后打开浏览器访问http://localhost:9080应能看到 Bookinfo 应用。多次刷新页面以产生足够的访问日志。随后即可在 SkyWalking WebUI 上看到 Bookinfo 应用的拓扑与指标——这说明 Satellite 已经开始工作。5. 部署监控OpenTelemetry Collector需要安装 OpenTelemetry Collector 来采集 OAP 中的指标并进行分析# Add OTEL collector kubectl apply -f https://raw.githubusercontent.com/mrproliu/sw-satellite-demo-scripts/5821a909b647f7c8f99c70378e197630836f45f7/resources/otel-collector-oap.yaml kubectl port-forward -n skywalking-system service/skywalking-system-ui 8080:80打开浏览器访问http://localhost:8080/并在仪表盘上新建一个指标项即可观察数据内容的实际呈现。6. 扩容 OAP通过 Deployment 扩容 OAP 副本数kubectl scale --replicas3 -n skywalking-system deployment/skywalking-system-oap一段时间后你会看到 OAP 数量变为 3且ALS 流量被均衡地分发到每个 OAP——这正是 Satellite 按内容路由发挥的作用存量与新增 OAP 都能公平承接流量无需客户端重连。场景二Satellite Scaling完成 SkyWalking Scaling 后继续演示 Satellite 自身的自动扩容。1. 部署 SWCK HPASWCK 提供适配器adapter通过读取 SkyWalking OAP 中的指标实现 Kubernetes external metrics从而驱动 HPA。具体做法是把 Satellite 的指标服务暴露给 OAP并配置 HPA 资源以自动扩缩容 Satellite。安装 SWCK adapterkubectl apply -f skywalking-swck/config/adapter-bundle.yaml创建 HPA 资源并限制每个 Satellite 最多处理 10 条连接kubectl apply -f https://raw.githubusercontent.com/mrproliu/sw-satellite-demo-scripts/5821a909b647f7c8f99c70378e197630836f45f7/resources/satellite-hpa.yaml此时可以看到一个 Satellite 上有 9 条连接注意一个 Envoy 代理可能与 Satellite 建立多条连接$ kubectl get HorizontalPodAutoscaler -n skywalking-system NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE hpa-demo Deployment/skywalking-system-satellite 9/10 1 3 1 5m18s2. 扩容应用制造更多连接扩容应用以建立更多到 Satellite 的连接验证 HPA 是否生效kubectl scale --replicas3 deployment/productpage-v1 deployment/details-v13. 完成观察 HPA 自动扩容默认情况下 Satellite 部署为单实例且单实例只接受11 条连接HPA 资源限制单 Satellite 处理10 条连接并使用**稳定窗口stabilization window**让 Satellite 平稳扩容。本案例中 Bookinfo 应用扩容后部署了 10 实例意味着会向 Satellite 建立 10 条连接。因此 HPA 资源运行后Satellite 会被自动扩容到2 个实例副本数计算算法详见 Kubernetes HPA 官方文档的 algorithm details。运行以下命令查看运行状态$ kubectl get HorizontalPodAutoscaler -n skywalking-system --watch NAME REFERENCE TARGETS MINPODS MAXPODS REPLICAS AGE hpa-demo Deployment/skywalking-system-satellite 11/10 1 3 1 3m31s hpa-demo Deployment/skywalking-system-satellite 11/10 1 3 1 4m20s hpa-demo Deployment/skywalking-system-satellite 11/10 1 3 2 4m38s hpa-demo Deployment/skywalking-system-satellite 11/10 1 3 2 5m8s hpa-demo Deployment/skywalking-system-satellite 6/10 1 3 2 5m23s观察连接数指标可以看到当每个 gRPC 节点的连接数超过 10 时Satellite 通过 HPA 规则自动扩容扩容后连接数回落到正常状态本例中小于 10。可用 swctl 查询连接数指标swctl metrics linear --name satellite_service_grpc_connect_count --service-name satellite::satellite-service该指标正是上文 dashboards-so11y-satellite.md 中satellite_service_grpc_connect_count它通过 OAP 的指标服务被 SWCK Adapter 读取形成HPA → SWCK Adapter → OAP → Satellite 自观测指标的完整闭环。小结围绕OAP 集群如何在 gRPC 长连接模型下保持负载均衡、按需扩容这一核心问题Apache SkyWalking 给出的答案是清晰且分层的网关层部署 SkyWalking-Satellite 作为按内容路由的 gRPC 代理客户端只与 Satellite 建立连接由 Satellite 通过 Kubernetes Label Selector / 手动配置感知 OAP 节点并按 Round-Robin / Fixed 等算法分发数据传输层绝大多数上报类协议采用队列缓冲 异步批量发送策略少量需要实时应答的协议如动态配置服务采用同步策略伸缩层Satellite 集群自身采用资源限制 HPA方案——以satellite_service_grpc_connect_count等自观测指标驱动 SWCK Adapter让 Kubernetes HPA 自动扩缩容 Satellite从而在不要求客户端配合、不丢数据的前提下应对流量增长兜底方案若不想引入 Satellite也可通过 EnvoyFilter 限制每个 OAP 实例的连接数必要时用SW_ALS_GRPC_PORT拆分 ALS 专用端口但该方案是连接级均衡在大规模场景下仍有失衡风险。这套设计既有明确的取舍依据可观测数据对延迟不敏感、客户端不可变更、连接不主动断开避免丢数又有仓库侧完整的配置与源码支撑application.yml、EnvoyMetricReceiverConfig.java、RemoteSenderService.java可作为在 Kubernetes 上规划 SkyWalking 大规模观测基础设施时的直接参考。【免费下载链接】skywalkingAPM, Application Performance Monitoring System项目地址: https://gitcode.com/gh_mirrors/sky/skywalking创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考