前面 14 篇我们已经把大模型链路的采集、拆解、关联、告警、存储选型全部打通。但所有这些能力都建立在一个前提上SkyWalking 自身是稳定可用的。如果 OAP 是单节点它一宕机全公司的链路监控就黑屏正在发生的大模型事故你将完全失明。本篇是阶段收官讲如何把 SkyWalking 从单机演示升级为生产级高可用OAP 横向扩成无状态集群存储用多节点 ES 加副本前置负载均衡并通过故障演练验证真正的高可用。落地这套架构你才算真正具备线上大模型性能问题 7x24 可观测的能力。为什么单节点不够高可用诉求整体架构OAP 集群 高可用 ES部署实战OAP 无状态集群高可用存储ES 多节点 副本负载均衡与网关接入灰度发布与故障演练最佳实践与踩坑1. 为什么单节点不够高可用诉求单机 OAP 有三道致命单点第一进程单点。OAP 挂了Agent 上报失败数据丢失或堆积在 Agent 缓冲UI 打不开告警停发。而在大模型高峰恰恰最容易因写入压力把单 OAP 压垮。第二存储单点。即使是 ES单节点磁盘损坏 历史 Trace 全丢事故复盘无据。第三升级单点。改 OAP 配置或升级版本必须停服期间监控空白。高可用的目标不是永远不挂那不现实而是挂一个不影响整体OAP 任一实例故障其余实例无缝接管存储一节点故障副本保证数据不丢、读写不中断。2. 整体架构OAP 集群 高可用 ES生产推荐架构自上而下接入层Agent 通过环境变量指向 oap:11800gRPC由 DNS / K8s Service 做客户端负载均衡UI 前面挂 Nginx/SLB。计算层2~N 个 OAP 实例无状态共享同一存储通过集群协调器Kubernetes / Nacos / Zookeeper / Consul / Etcd互相发现。存储层ES 至少 3 节点索引副本数 1跨可用区部署。协调层选一个你们已有的协调服务K8s 集群内直接用 cluster.selectorkubernetes 最省事。关键认知OAP 无状态正是因为它把状态全交给了存储。所以集群部署的重点一半在 OAP 多实例一半在存储高可用。两层都冗余才是真高可用。3. 部署实战OAP 无状态集群OAP 集群配置在 application.yml 的 cluster 段。以 Kubernetes 为例最简洁cluster:selector: ${SW_CLUSTER:kubernetes}kubernetes:namespace: ${SW_CLUSTER_K8S_NAMESPACE:skywalking}labelSelector: ${SW_CLUSTER_K8S_LABEL:appoap}uidEnvName: ${SW_CLUSTER_K8S_UID:SKYWALKING_UID}core 段固定 gRPC/HTTP 端口多实例靠 K8s 多 Pod 实现每个 Pod 内部端口相同core:selector: ${SW_CORE:default}default:gRPCHost: ${SW_CORE_GRPC_HOST:0.0.0.0}gRPCPort: ${SW_CORE_GRPC_PORT:11800}restHost: ${SW_CORE_REST_HOST:0.0.0.0}restPort: ${SW_CORE_REST_PORT:12800}K8s Deployment 关键片段3 副本apiVersion: apps/v1kind: Deploymentmetadata:name: oapnamespace: skywalkinglabels: { app: oap }spec:replicas: 3selector:matchLabels: { app: oap }template:metadata:labels: { app: oap }spec:containers:- name: oapimage: apache/skywalking-oap-server:9.7.0env:- name: SW_CLUSTERvalue: kubernetes- name: SW_STORAGEvalue: elasticsearch- name: SW_ES_CLUSTER_NODESvalue: es:9200ports:- { containerPort: 11800 }- { containerPort: 12800 }Agent 侧通过 K8s Service 名访问无需关心具体实例-DSW_AGENT_COLLECTOR_BACKEND_SERVICESoap.skywalking.svc:11800扩缩容只需改 replicasOAP 通过协调器自动感知新节点无数据迁移成本。4. 高可用存储ES 多节点 副本ES 高可用靠分片副本。部署 3 个数据节点SkyWalking 索引副本设为 1即每份数据存 2 份分布在 2 个节点storage:elasticsearch:clusterNodes: ${SW_ES_CLUSTER_NODES:es1:9200,es2:9200,es3:9200}indexShardsNumber: 3indexReplicasNumber: 1副本的作用某节点宕机另一节点上的副本立即升为主分片读写不中断。但副本数也不是越大越好——副本2 会把写入放大约 2 倍、存储翻倍。大模型高写入场景replicas1 是性价比最优。跨可用区部署时用 ES 的 shard allocation awareness 让主副分片落在不同 AZ避免单 AZ 故障同时丢主副# 每个节点标注 zone# elasticsearch.ymlnode.attr.zone: az-a # az-b / az-c# 集群级cluster.routing.allocation.awareness.attributes: zone这样即使 az-a 整体断电数据仍在 az-b/az-c 完整可用。5. 负载均衡与网关接入虽然 Agent 支持配置多个 backend_service逗号分隔但更稳妥是在前面放一层负载均衡让 Agent 只认一个稳定地址。Nginx 对 UIrest 12800做反向代理upstream oap_rest {server oap-0:12800;server oap-1:12800;server oap-2:12800;}server {listen 12800;location / {proxy_pass http://oap_rest;proxy_set_header Host $host;}}gRPC11800建议用支持 HTTP/2 的 LB如 Nginx Plus、Envoy、或云 SLB 的 TCP 转发。K8s 环境下直接用 Service 的 ClusterIP kube-proxy 轮询即可Agent 配 Service 名。UI 单独部署skywalking-uiSW_OAP_ADDRESS 指向 LB 地址docker run -d --name ui -e SW_OAP_ADDRESShttp://oap-lb:12800 \-p 8080:8080 apache/skywalking-ui:9.7.0注意UI 与 OAP 版本必须一致否则 GraphQL 接口不兼容会白屏。6. 灰度发布与故障演练高可用不是配完就高可用要靠演练验证。两类必做动作第一滚动发布。OAP 升级用 K8s 滚动更新maxUnavailable1保证始终有实例在跑。因为 OAP 无状态升级期间 Agent 会自动重连到存活实例监控不中断。演练命令kubectl -n skywalking set image deployment/oap oapapache/skywalking-oap-server:9.7.1kubectl -n skywalking rollout status deployment/oap第二故障演练Chaos。主动 kill 一个 OAP Pod确认① 其余实例自动接管② Agent 侧 Trace 不丢短暂缓冲后重连上报③ UI 和告警正常。再 kill 一个 ES 节点确认① 副本升主、读写无中断② 数据完整。推荐用混沌工程工具如 Chaos Mesh定期自动演练把我以为高可用变成验证过高可用。下表给出高可用等级对照帮你对标等级OAP存储故障影响适用---------------L0单节点H2全盲演示L12 节点单 ES实例故障可扛测试L23 节点ES 3 节点副本1单点故障无感生产L33 节点ES 跨 AZ 副本AZ 故障无感核心生产7. 最佳实践与踩坑第一OAP 版本与存储、UI 必须一致。跨小版本连 ES 常因 mapping 不兼容报错UI 与 OAP 版本差一级就可能 GraphQL 白屏。升级走全栈同版本策略。第二协调器别引入新单点。用 Zookeeper/Consul 做集群协调时协调器本身也要集群化否则为去单点引入新单点。K8s 内部直接用 cluster.selectorkubernetes 最省心。第三Agent 缓冲要留足。OAP 滚动升级瞬间Agent 会短暂连不上靠 Agent 内存缓冲暂存。缓冲有上限默认几十 MB升级要快、实例不要同时重启否则高峰会丢数据。可用 agent.config 的 buffer 相关参数调大。第四ES 磁盘水位线要监控。ES 默认磁盘超 85% 停止分配分片、超 90% 只读。OAP 写不进去时静默失败监控又恰好依赖 ES——典型的监控自杀。务必告警 ES 磁盘使用率。第五别把 OAP 和 ES 放同一台机器。它们都吃内存OAP 堆 ES 堆 OS 缓存混部会互相抢占反而更易整体崩。计算与存储分离部署。第六配置统一走环境变量。所有 SW_* 环境变量不要写死在镜像里用 ConfigMap / 部署变量注入便于多环境测试/生产切换也方便灰度。至此第 46 阶段大模型调用链路追踪SkyWalking 排查线上性能15 篇全部完成从链路模型、Token 耗时拆解、Trace-Log 联动、OAL 告警到存储选型、集群高可用构成了完整的大模型可观测性落地路径。把这套体系接进你的线上大模型服务下一次性能工单你将不再是盲猜的那个人。