返回首页

Golang项目实践：4.6 容器化与云原生部署

2026-03-05 18:53 Golang 11 阅读 #项目实践

在现代 Golang 项目中，写出可运行的服务只是第一步。真正进入团队协作、测试联调、持续交付和生产环境运行阶段后，容器化与云原生部署能力会直接影响项目的开发效率、交付质量与系统稳定性。

本章将围绕一个最小可运行的 Go Web 服务，系统讲解从 Docker 容器化、本地联调、Kubernetes 部署、Helm Chart 管理，到 CI/CD 流水线设计的完整实践过程。你可以把这篇文章当成一套从本地到线上落地的参考模板。

一、示例项目说明

为了让后续内容可直接运行，我们先准备一个简单的 HTTP 服务。该服务提供两个接口：

  • GET /healthz：用于健康检查
  • GET /config：读取环境变量中的配置信息

项目结构如下：

cloud-native-demo/
├── cmd/
│   └── server/
│       └── main.go
├── go.mod
├── go.sum
├── Dockerfile
├── docker-compose.yml
├── k8s/
│   ├── deployment.yaml
│   ├── service.yaml
│   └── configmap.yaml
├── helm/
│   └── cloud-native-demo/
│       ├── Chart.yaml
│       ├── values.yaml
│       └── templates/
│           ├── deployment.yaml
│           ├── service.yaml
│           ├── configmap.yaml
│           └── _helpers.tpl
└── .github/
    └── workflows/
        └── ci.yml

1.1 Go 服务代码

cmd/server/main.go：

package main

import (
	"encoding/json"
	"log"
	"net/http"
	"os"
)

type ConfigResponse struct {
	AppName string `json:"app_name"`
	Version string `json:"version"`
	Env     string `json:"env"`
}

func main() {
	mux := http.NewServeMux()

	mux.HandleFunc("/healthz", func(w http.ResponseWriter, r *http.Request) {
		w.WriteHeader(http.StatusOK)
		_, _ = w.Write([]byte("ok"))
	})

	mux.HandleFunc("/config", func(w http.ResponseWriter, r *http.Request) {
		resp := ConfigResponse{
			AppName: getEnv("APP_NAME", "cloud-native-demo"),
			Version: getEnv("APP_VERSION", "1.0.0"),
			Env:     getEnv("APP_ENV", "dev"),
		}

		w.Header().Set("Content-Type", "application/json")
		_ = json.NewEncoder(w).Encode(resp)
	})

	addr := ":8080"
	log.Printf("server listening on %s", addr)
	if err := http.ListenAndServe(addr, loggingMiddleware(mux)); err != nil {
		log.Fatal(err)
	}
}

func getEnv(key, fallback string) string {
	if v := os.Getenv(key); v != "" {
		return v
	}
	return fallback
}

func loggingMiddleware(next http.Handler) http.Handler {
	return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
		log.Printf("%s %s", r.Method, r.URL.Path)
		next.ServeHTTP(w, r)
	})
}

go.mod：

module cloud-native-demo

go 1.22

本示例依赖极少，便于你把关注点放在容器化和部署流程本身。

二、Docker 容器化：多阶段构建优化

Docker 是 Go 服务交付中最常见的打包方式。Go 的静态编译特性非常适合容器部署，但如果直接把源码和构建工具全部塞进镜像，最终镜像会偏大，也会带来额外的攻击面。

这时，多阶段构建（Multi-stage Build）就是最推荐的方式。

2.1 为什么要用多阶段构建

直接使用单阶段构建时，通常会出现以下问题：

  • 镜像体积大，拉取慢，启动慢
  • 生产镜像中保留了编译器、源码和缓存，不够安全
  • CI 构建传输成本高
  • 部署时浪费存储与网络资源

多阶段构建的核心思想是：

  1. 在构建阶段使用 Golang 官方镜像完成编译
  2. 在运行阶段只保留最终二进制文件和必要运行环境

2.2 基础版多阶段 Dockerfile

下面是一个生产可用的 Dockerfile：

# syntax=docker/dockerfile:1

FROM golang:1.22-alpine AS builder

WORKDIR /app

RUN apk add --no-cache ca-certificates tzdata

COPY go.mod go.sum ./
RUN go mod download

COPY . .

RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -ldflags="-s -w" -o /app/server ./cmd/server

FROM alpine:3.20

WORKDIR /app

RUN apk add --no-cache ca-certificates tzdata

COPY --from=builder /app/server /app/server

EXPOSE 8080

ENV APP_NAME=cloud-native-demo
ENV APP_VERSION=1.0.0
ENV APP_ENV=prod

ENTRYPOINT ["/app/server"]

2.3 Dockerfile 关键优化点解析

（1）先复制 go.mod 和 go.sum

这是为了充分利用 Docker 层缓存。

COPY go.mod go.sum ./
RUN go mod download

当业务代码变更但依赖未变化时，Docker 可以复用依赖下载层，大幅减少构建时间。

（2）关闭 CGO，生成静态二进制

RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -ldflags="-s -w" -o /app/server ./cmd/server

其中：

  • CGO_ENABLED=0：避免依赖系统动态库，便于跨环境部署
  • -ldflags="-s -w"：去掉调试符号，减小二进制体积

（3）运行镜像尽量轻量

第二阶段只保留运行所需环境，而不保留编译工具链。

（4）显式暴露端口

EXPOSE 8080

虽然 EXPOSE 不会自动映射端口，但它能提高镜像可读性，也便于容器平台识别默认监听端口。

2.4 更进一步：使用 distroless 镜像

如果你的服务只需要二进制运行环境，可以进一步减小镜像面并提升安全性：

FROM golang:1.22-alpine AS builder

WORKDIR /app
COPY go.mod go.sum ./
RUN go mod download
COPY . .
RUN CGO_ENABLED=0 GOOS=linux GOARCH=amd64 go build -ldflags="-s -w" -o /server ./cmd/server

FROM gcr.io/distroless/static-debian12

COPY --from=builder /server /server

EXPOSE 8080

ENTRYPOINT ["/server"]

这类镜像没有 shell，也没有额外包管理工具，安全性更高，但排障时不如 Alpine 方便。团队可以根据运维能力与安全要求进行选择。

2.5 构建与运行命令

构建镜像：

docker build -t cloud-native-demo:1.0.0 .

运行容器：

docker run --rm -p 8080:8080 \
  -e APP_NAME=cloud-native-demo \
  -e APP_VERSION=1.0.0 \
  -e APP_ENV=local \
  cloud-native-demo:1.0.0

验证接口：

curl http://localhost:8080/healthz
curl http://localhost:8080/config

2.6 .dockerignore 也很重要

很多项目镜像构建慢，不是 Dockerfile 写得不好，而是上下文太大。建议增加 .dockerignore：

.git
.github
.idea
.vscode
bin
coverage.out
*.log
helm/**/charts
node_modules
Dockerfile*
docker-compose*.yml
README.md

这样可以减少构建上下文体积，提升构建效率。

三、Docker Compose 本地开发环境

在本地开发阶段，服务往往不是单独运行的。常见情况包括：

  • Go 应用需要依赖 Redis、MySQL、PostgreSQL
  • 团队成员需要一键拉起完整联调环境
  • 测试环境希望尽量贴近线上部署结构

Docker Compose 很适合解决这类本地多容器协作问题。

3.1 示例：Go 服务 + Redis

下面给出一个 docker-compose.yml，用于启动应用和 Redis：

version: "3.9"

services:
  app:
    build:
      context: .
      dockerfile: Dockerfile
    container_name: cloud-native-demo-app
    ports:
      - "8080:8080"
    environment:
      APP_NAME: cloud-native-demo
      APP_VERSION: 1.0.0
      APP_ENV: compose
      REDIS_ADDR: redis:6379
    depends_on:
      - redis
    restart: unless-stopped

  redis:
    image: redis:7-alpine
    container_name: cloud-native-demo-redis
    ports:
      - "6379:6379"
    volumes:
      - redis-data:/data
    restart: unless-stopped

volumes:
  redis-data:

3.2 启动与停止命令

启动服务：

docker compose up --build

后台运行：

docker compose up -d --build

查看日志：

docker compose logs -f app

停止环境：

docker compose down

删除数据卷并清理：

docker compose down -v

3.3 Compose 在本地开发中的价值

场景 价值
新成员入项 一条命令快速启动依赖环境
多服务联调 避免本机手工安装多个中间件
环境一致性 降低“我本地能跑，你那里不行”的问题
自动化测试 可在 CI 中复用 Compose 拉起依赖服务

3.4 开发态优化建议

如果你希望开发时支持热重载，可以单独准备开发版 Dockerfile，或者将源码挂载进去，例如：

services:
  app:
    image: golang:1.22-alpine
    working_dir: /workspace
    volumes:
      - .:/workspace
    command: sh -c "go run ./cmd/server"
    ports:
      - "8080:8080"
    environment:
      APP_ENV: dev

这种方式适合开发调试，但不建议直接用于生产镜像。

四、Kubernetes 部署：Deployment、Service、ConfigMap

当应用进入测试、预发、生产环境后，单机容器运行通常已经不够。Kubernetes 提供了声明式部署、自动恢复、弹性扩缩容、服务发现等能力，是云原生部署的核心平台。

本节重点介绍最常用的三类资源：

  • Deployment：管理 Pod 副本与滚动更新
  • Service：对外暴露服务与集群内服务发现
  • ConfigMap：管理非敏感配置

4.1 ConfigMap 配置文件

k8s/configmap.yaml：

apiVersion: v1
kind: ConfigMap
metadata:
  name: cloud-native-demo-config
  labels:
    app: cloud-native-demo
data:
  APP_NAME: cloud-native-demo
  APP_VERSION: 1.0.0
  APP_ENV: production

ConfigMap 适合保存：

  • 应用环境标识
  • 日志级别
  • 外部接口地址
  • 业务开关

但不要把数据库密码、Access Token 等敏感信息放进 ConfigMap，这类内容应该使用 Secret。

4.2 Deployment 资源

k8s/deployment.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: cloud-native-demo
  labels:
    app: cloud-native-demo
spec:
  replicas: 3
  selector:
    matchLabels:
      app: cloud-native-demo
  template:
    metadata:
      labels:
        app: cloud-native-demo
    spec:
      containers:
        - name: app
          image: cloud-native-demo:1.0.0
          imagePullPolicy: IfNotPresent
          ports:
            - containerPort: 8080
          envFrom:
            - configMapRef:
                name: cloud-native-demo-config
          readinessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 3
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /healthz
              port: 8080
            initialDelaySeconds: 10
            periodSeconds: 10
          resources:
            requests:
              cpu: 100m
              memory: 128Mi
            limits:
              cpu: 500m
              memory: 256Mi

4.3 Deployment 关键字段说明

（1）副本数 replicas

replicas: 3

表示同时运行 3 个 Pod，可提高可用性并支持负载分担。

（2）标签选择器 selector

Deployment 通过标签匹配自己管理的 Pod，因此：

  • spec.selector.matchLabels
  • spec.template.metadata.labels

这两部分必须一致。

（3）探针配置

readinessProbe 表示“是否可以接流量”； livenessProbe 表示“是否还活着，需要不需要被重启”。

这两个探针是线上稳定性的关键配置，建议在 Go 服务中始终提供健康检查接口。

（4）资源限制

资源声明可以帮助调度器更合理地分配节点资源，也能避免单个服务异常占用过多 CPU 或内存。

4.4 Service 资源

k8s/service.yaml：

apiVersion: v1
kind: Service
metadata:
  name: cloud-native-demo
  labels:
    app: cloud-native-demo
spec:
  selector:
    app: cloud-native-demo
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: ClusterIP

该配置表示：

  • 集群内访问地址为 cloud-native-demo:80
  • 实际转发到 Pod 的 8080 端口
  • ClusterIP 只在集群内部暴露服务

如果需要对外访问，可以结合 Ingress 或将 type 设为 LoadBalancer。

4.5 部署命令

应用资源：

kubectl apply -f k8s/configmap.yaml
kubectl apply -f k8s/deployment.yaml
kubectl apply -f k8s/service.yaml

查看 Pod：

kubectl get pods -l app=cloud-native-demo

查看 Service：

kubectl get svc cloud-native-demo

查看 Deployment 滚动状态：

kubectl rollout status deployment/cloud-native-demo

4.6 实践建议

配置项 建议
健康检查 所有服务都实现 /healthz 或类似接口
资源限制 明确设置 requests/limits，避免资源争抢
镜像标签 不要长期使用 latest，应使用版本号或 commit sha
配置管理 非敏感配置用 ConfigMap，敏感配置用 Secret
副本数 生产环境建议至少 2 个副本，避免单点问题

五、Helm Chart 编写

当 Kubernetes 资源文件越来越多时，手工维护 YAML 会逐渐变得痛苦。不同环境的副本数、镜像标签、配置项和 Service 类型也常常不一样。

Helm 的价值就是把这些重复配置模板化、参数化，实现可复用部署。

5.1 Chart 基本结构

helm/cloud-native-demo/Chart.yaml：

apiVersion: v2
name: cloud-native-demo
description: A Helm chart for deploying cloud-native-demo
version: 0.1.0
appVersion: "1.0.0"
type: application

helm/cloud-native-demo/values.yaml：

replicaCount: 2

image:
  repository: cloud-native-demo
  tag: "1.0.0"
  pullPolicy: IfNotPresent

service:
  type: ClusterIP
  port: 80
  targetPort: 8080

config:
  APP_NAME: cloud-native-demo
  APP_VERSION: "1.0.0"
  APP_ENV: production

resources:
  requests:
    cpu: 100m
    memory: 128Mi
  limits:
    cpu: 500m
    memory: 256Mi

5.2 模板辅助函数

helm/cloud-native-demo/templates/_helpers.tpl：

{{- define "cloud-native-demo.name" -}}
{{- .Chart.Name -}}
{{- end -}}

{{- define "cloud-native-demo.fullname" -}}
{{- printf "%s-%s" .Release.Name .Chart.Name | trunc 63 | trimSuffix "-" -}}
{{- end -}}

5.3 ConfigMap 模板

helm/cloud-native-demo/templates/configmap.yaml：

apiVersion: v1
kind: ConfigMap
metadata:
  name: {{ include "cloud-native-demo.fullname" . }}-config
data:
  APP_NAME: {{ .Values.config.APP_NAME | quote }}
  APP_VERSION: {{ .Values.config.APP_VERSION | quote }}
  APP_ENV: {{ .Values.config.APP_ENV | quote }}

5.4 Deployment 模板

helm/cloud-native-demo/templates/deployment.yaml：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: {{ include "cloud-native-demo.fullname" . }}
  labels:
    app: {{ include "cloud-native-demo.name" . }}
spec:
  replicas: {{ .Values.replicaCount }}
  selector:
    matchLabels:
      app: {{ include "cloud-native-demo.name" . }}
  template:
    metadata:
      labels:
        app: {{ include "cloud-native-demo.name" . }}
    spec:
      containers:
        - name: app
          image: "{{ .Values.image.repository }}:{{ .Values.image.tag }}"
          imagePullPolicy: {{ .Values.image.pullPolicy }}
          ports:
            - containerPort: {{ .Values.service.targetPort }}
          envFrom:
            - configMapRef:
                name: {{ include "cloud-native-demo.fullname" . }}-config
          readinessProbe:
            httpGet:
              path: /healthz
              port: {{ .Values.service.targetPort }}
            initialDelaySeconds: 3
            periodSeconds: 5
          livenessProbe:
            httpGet:
              path: /healthz
              port: {{ .Values.service.targetPort }}
            initialDelaySeconds: 10
            periodSeconds: 10
          resources:
{{ toYaml .Values.resources | indent 12 }}

5.5 Service 模板

helm/cloud-native-demo/templates/service.yaml：

apiVersion: v1
kind: Service
metadata:
  name: {{ include "cloud-native-demo.fullname" . }}
spec:
  type: {{ .Values.service.type }}
  selector:
    app: {{ include "cloud-native-demo.name" . }}
  ports:
    - port: {{ .Values.service.port }}
      targetPort: {{ .Values.service.targetPort }}
      protocol: TCP

5.6 Helm 常用命令

渲染模板：

helm template demo-release ./helm/cloud-native-demo

安装 Chart：

helm install demo-release ./helm/cloud-native-demo

升级发布：

helm upgrade demo-release ./helm/cloud-native-demo

卸载发布：

helm uninstall demo-release

指定环境变量覆盖：

helm upgrade --install demo-release ./helm/cloud-native-demo \
  --set image.tag=1.0.1 \
  --set replicaCount=3 \
  --set config.APP_ENV=staging

5.7 Helm 的实际收益

问题 直接写 YAML 使用 Helm
多环境部署 复制多份配置，容易漂移 参数化管理，更统一
版本升级 手动改镜像标签 --set image.tag=... 即可
模板复用 重复配置较多 模板统一输出
运维协作 可读性一般 Chart 结构更清晰

如果你的项目已经进入团队协作阶段，Helm 基本可以视为 Kubernetes 部署标准配套工具。

六、CI/CD 流水线设计（GitHub Actions / GitLab CI）

容器化和 Kubernetes 部署只是“交付物”的一部分。真正实现持续交付，还需要把代码检查、测试、镜像构建、镜像推送和部署更新串成自动化流水线。

一个典型的 Go 服务 CI/CD 流程通常包括：

  1. 拉取代码
  2. 安装 Go 环境
  3. 执行依赖下载
  4. 运行格式检查、静态检查、单元测试
  5. 构建 Docker 镜像
  6. 推送镜像到仓库
  7. 更新 Kubernetes 或 Helm 发布

6.1 GitHub Actions 示例

.github/workflows/ci.yml：

name: Go CI/CD

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

jobs:
  test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup Go
        uses: actions/setup-go@v5
        with:
          go-version: '1.22'

      - name: Cache Go modules
        uses: actions/cache@v4
        with:
          path: |
            ~/.cache/go-build
            ~/go/pkg/mod
          key: ${{ runner.os }}-go-${{ hashFiles('**/go.sum') }}
          restore-keys: |
            ${{ runner.os }}-go-

      - name: Download dependencies
        run: go mod download

      - name: Run tests
        run: go test ./...

  docker:
    runs-on: ubuntu-latest
    needs: test
    if: github.ref == 'refs/heads/main'
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Set up Docker Buildx
        uses: docker/setup-buildx-action@v3

      - name: Log in to GitHub Container Registry
        uses: docker/login-action@v3
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}

      - name: Build and push image
        uses: docker/build-push-action@v6
        with:
          context: .
          push: true
          tags: ghcr.io/example/cloud-native-demo:${{ github.sha }}

  deploy:
    runs-on: ubuntu-latest
    needs: docker
    if: github.ref == 'refs/heads/main'
    steps:
      - name: Checkout code
        uses: actions/checkout@v4

      - name: Setup kubectl
        uses: azure/setup-kubectl@v4

      - name: Setup Helm
        uses: azure/setup-helm@v4

      - name: Deploy with Helm
        env:
          KUBECONFIG_DATA: ${{ secrets.KUBECONFIG_DATA }}
        run: |
          echo "$KUBECONFIG_DATA" | base64 -d > kubeconfig
          export KUBECONFIG=$PWD/kubeconfig
          helm upgrade --install demo-release ./helm/cloud-native-demo \
            --set image.repository=ghcr.io/example/cloud-native-demo \
            --set image.tag=${{ github.sha }}

6.2 GitHub Actions 设计说明

这个流程分成三个阶段：

  • test：保证代码质量不过线就不继续
  • docker：构建并推送镜像
  • deploy：更新 Helm 发布

这种设计有几个优点：

  • 阶段职责清晰
  • 失败点容易定位
  • 主分支自动部署，便于持续交付
  • 可逐步插入 lint、SAST、镜像扫描等步骤

6.3 GitLab CI 示例

如果你的团队使用 GitLab，也可以采用类似设计。

.gitlab-ci.yml：

stages:
  - test
  - build
  - deploy

variables:
  GO_VERSION: "1.22"
  IMAGE_NAME: registry.example.com/cloud-native-demo

cache:
  paths:
    - .go/pkg/mod
    - .cache/go-build

test:
  stage: test
  image: golang:${GO_VERSION}-alpine
  before_script:
    - go env -w GOPATH=$CI_PROJECT_DIR/.go
    - mkdir -p .cache/go-build
    - export GOCACHE=$CI_PROJECT_DIR/.cache/go-build
    - go mod download
  script:
    - go test ./...

build:
  stage: build
  image: docker:27
  services:
    - docker:27-dind
  variables:
    DOCKER_HOST: tcp://docker:2375
    DOCKER_TLS_CERTDIR: ""
  before_script:
    - docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" $CI_REGISTRY
  script:
    - docker build -t ${IMAGE_NAME}:${CI_COMMIT_SHA} .
    - docker push ${IMAGE_NAME}:${CI_COMMIT_SHA}
  only:
    - main

deploy:
  stage: deploy
  image: alpine/helm:3.15.2
  before_script:
    - mkdir -p ~/.kube
    - echo "$KUBECONFIG_CONTENT" | base64 -d > ~/.kube/config
  script:
    - helm upgrade --install demo-release ./helm/cloud-native-demo \
        --set image.repository=${IMAGE_NAME} \
        --set image.tag=${CI_COMMIT_SHA}
  only:
    - main

6.4 CI/CD 流水线设计原则

原则 说明
先测试，后构建 避免无效镜像进入仓库
镜像不可变 使用 commit sha 或版本号作为标签
部署可追踪 每次发布都应能定位到具体代码版本
凭据外置 仓库密码、KubeConfig 使用平台 Secret 管理
失败可回滚 Helm 或 Deployment 滚动发布需支持快速回退

6.5 生产实践建议

在真实生产场景中，建议把流水线进一步拆分为以下层次：

  • 代码质量层：gofmt、go vet、golangci-lint
  • 测试层：单元测试、集成测试、接口测试
  • 制品层：Docker 镜像构建、SBOM、镜像扫描
  • 部署层：Helm 发布、灰度发布、回滚
  • 观测层：部署后健康检查、日志与指标校验

例如，可以在测试阶段加入：

gofmt -w .
go vet ./...
golangci-lint run
go test ./... -cover

如果团队对发布稳定性要求较高，还可以结合：

  • 蓝绿发布
  • 金丝雀发布
  • Argo CD / Flux 这类 GitOps 工具

不过对于大多数中小型 Go 服务来说，本文给出的 GitHub Actions 或 GitLab CI 方案，已经足够搭建起一条清晰、可靠、可扩展的交付链路。

七、从本地开发到线上发布的完整链路总结

把本章的内容串起来，你会得到一条非常清晰的 Go 云原生交付路径：

  1. 使用 Go 编写标准化 HTTP 服务
  2. 通过 Docker 多阶段构建生成轻量镜像
  3. 使用 Docker Compose 在本地拉起依赖环境
  4. 使用 Kubernetes Deployment、Service、ConfigMap 进行集群部署
  5. 使用 Helm 管理模板与多环境配置
  6. 使用 GitHub Actions 或 GitLab CI 实现自动化测试、构建与发布

这条链路的核心收益是：

  • 开发环境更一致
  • 部署过程更标准
  • 配置管理更清晰
  • 发布流程更自动化
  • 服务运维更可控

对于 Golang 项目而言，语言本身的编译速度快、单二进制部署简单，再加上 Docker 和 Kubernetes 的组合，能够非常自然地构建出一套适合现代团队协作的交付体系。

当你真正把这些流程落到项目中后，会明显感受到：容器化与云原生部署并不是“额外负担”，而是把开发、测试、运维和发布串成闭环的关键基础设施能力。

📝 版权声明：本文为原创技术博客，转载请注明出处。

如文章中存在错误或不准确之处，欢迎在评论区指正，感谢您的阅读与支持！

上一篇

Golang项目实践：4.3 数据库与存储
下一篇

Golang项目实践：4.7 监控与可观测性