存储与部署

SkyWalking 的 OAP 是无状态分析层，数据最终落入存储。存储选型直接决定可承载的数据量和查询体验；部署形态则决定如何接入生产集群。本文覆盖存储对比、compose/Kubernetes 部署、压测调优与常见问题。

存储选型

存储	适用场景	特点
H2	单机、调试、演示	嵌入式，零配置，不适合生产大流量
MySQL / PostgreSQL	小规模生产、结构化运维	部署简单，容量和检索能力有限
Elasticsearch	大规模生产、全链路检索	分布式、检索/聚合强，运维成本高
BanyanDB	SkyWalking 原生时序数据库	专为可观测数据设计，减少 ES 依赖

判断要点：

数据量小：H2 或 MySQL 就能跑，便于低门槛验证。
链路明细需要灵活检索（按 URL、耗时、状态过滤）→ Elasticsearch。
追求轻量、少维护一个 ES 集群 → 可以评估 BanyanDB（新项目逐步推进）。

整体架构

OAP 之间横向扩展，共享同一存储，形成 OAP 集群。
UI 通过 12800 的 HTTP/GraphQL 查询 OAP。

compose 部署

最小可跑示例（H2 存储 + Prometheus Fetcher）：

yaml

services:
  oap:
    image: iharbor.abc.com/docker-hub/apache/skywalking-oap-server:9.0.0
    container_name: skywalking-oap
    ports:
      - "11800:11800"   # gRPC 接口
      - "12800:12800"   # HTTP 接口
    environment:
      SW_STORAGE: h2
      SW_RECEIVER_PROMETHEUS: default
      SW_PROMETHEUS_FETCHER_ACTIVE: "true"
      SW_PROMETHEUS_FETCHER_TARGETS: "[\"http://10.1.72.76:32644\"]"
    restart: unless-stopped

  ui:
    image: iharbor.abc.com/docker-hub/apache/skywalking-ui:9.0.0
    container_name: skywalking-ui
    depends_on:
      - oap
    ports:
      - "18081:8080"     # UI 页面端口
    environment:
      SW_OAP_ADDRESS: http://oap:12800
    restart: unless-stopped

镜像源地址请替换为你实际可拉取的 registry。

Kubernetes 部署

在生产 K8s 中，通常把 OAP 部署为可水平扩展的 Deployment，并用 Service / Ingress 暴露。

yaml

apiVersion: apps/v1
kind: Deployment
metadata:
  name: skywalking-oap
spec:
  replicas: 2
  selector:
    matchLabels: { app: skywalking-oap }
  template:
    metadata:
      labels: { app: skywalking-oap }
    spec:
      containers:
        - name: oap
          image: apache/skywalking-oap-server:9.0.0
          ports:
            - containerPort: 11800
            - containerPort: 12800
          env:
            - name: SW_STORAGE
              value: elasticsearch
            - name: SW_STORAGE_ES_CLUSTER_NODES
              value: es-1:9200,es-2:9200

接入注意点：

ClusterIP/Ingress 暴露 11800（Agent 上报）与 12800（UI 查询）。
Java Agent 的 backend_service 指向 OAP Service 地址，如 skywalking-oap.your-ns:11800。
多副本 OAP 共享同一存储，天然形成集群，需保证各实例配置一致。

Java Agent 部署

应用容器内挂载 Agent 并设置启动参数：

shell

-javaagent:/app/skywalking-agent/skywalking-agent.jar \
-Dskywalking.agent.service_name=order-service \
-Dskywalking.collector.backend_service=skywalking-oap.your-ns:11800

K8s 中常通过 initContainer 或镜像内置把 Agent 放进业务 Pod。
服务名建议与 K8s Service / 应用名保持一致，便于对账。
多环境（dev/test/prod）用不同 namespace 或地址隔离，避免串数据。

Agent 装载与配置细节见 Java Agent。

压测与调优

方向	建议
采样	高流量先降采样（`sample_n_per_3_secs`），控制明细量
Agent	只启用用到的插件；忽略静态资源后缀
OAP	多副本水平扩展；关注 gRPC 接收吞吐
ES	为链路索引配置合理的 Shard、副本与生命周期
数据保留	明确明细保留窗口（如 7 天），配合 TTL/生命周期删除

常见问题

症状	排查方向
UI 无数据	Agent 是否加载、`backend_service` 是否可达、存储是否可用
查询很慢	是否全量采集导致 ES 数据膨胀；是否缺少索引策略
链路缺失/断链	见链路追踪原理 / 断链排查
OAP 内存高	是否未合理采样、存储聚合压力大
K8s 中 Agent 上报失败	`backend_service` 是否填对 Service 域名与端口

指标告警与二次开发入口见告警与指标。

存储与部署 ​

存储选型 ​

整体架构 ​

compose 部署 ​

Kubernetes 部署 ​

Java Agent 部署 ​

压测与调优 ​

常见问题 ​