云原生架构模式

云原生架构模式

云原生（Cloud Native）是一套技术体系与方法论，旨在充分利用云计算的弹性、分布式与自动化能力。Sidecar、Service Mesh、Serverless 、GitOps 是其核心模式。

1. Sidecar 模式

将辅助功能从主容器中剥离，以独立容器部署。

┌────────────────────── Pod ──────────────────────┐
│  ┌─────────────┐    ┌─────────────┐             │
│  │ App Container│ ↔  │ Sidecar     │             │
│  │ (业务逻辑)   │    │ (Proxy/Log/ │             │
│  │             │    │  Monitor)   │             │
│  └─────────────┘    └─────────────┘             │
│        ↑                    ↑                   │
│     localhost           localhost               │
└─────────────────────────────────────────────────┘

典型 Sidecar

2. Service Mesh

将服务治理能力下沉到基础设施层。

架构

Service A                 Service B
    │                         │
┌───┴───┐                 ┌───┴───┐
│ Sidecar│ ←── xDS API ─→ │ Sidecar│
└───┬───┘                 └───┬───┘
    │                         │
    └──────── mTLS ───────────┘
    
Control Plane (Istiod): 下发配置、证书
Data Plane (Envoy): 执行流量管理、安全策略

Istio 核心能力

何时使用 Service Mesh

3. Serverless 与 FaaS

模型对比

传统:  IaaS → CaaS → PaaS → FaaS
       VM   → 容器 → 平台 → 函数

Serverless 特征:
- 代码即部署单元
- 事件触发、自动扩缩
- 按调用计费
- 无服务器运维

FaaS 平台

示例（AWS Lambda + API Gateway）

# handler.py
import json

def lambda_handler(event, context):
    # event 包含 API Gateway 传入的请求
    return {
        'statusCode': 200,
        'body': json.dumps({'message': 'Hello from Lambda'})
    }

冷启动优化

4. GitOps

以 Git 仓库为唯一事实来源，自动化部署与运维。

原则（Weaveworks）

1. 声明式系统：系统状态由声明式配置描述
2. 版本化与不可变：Git 记录所有变更历史
3. 自动拉取：控制器持续同步期望状态与实际状态
4. 持续协调：状态漂移时自动修复

典型工作流

Developer ──push──→ Git Repo ──Webhook──→ CI Pipeline
                              (应用代码)      │
                                              ↓ build
                                         Container Image
                                              │ push
                                              ↓
Developer ──push──→ Git Repo (配置/编排) ──→ CD工具(ArgoCD/Flux)
                                              │ pull
                                              ↓
                                         Kubernetes Cluster

ArgoCD 示例

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: order-service
spec:
  project: default
  source:
    repoURL: https://github.com/company/gitops-repo
    targetRevision: HEAD
    path: apps/order-service
  destination:
    server: https://kubernetes.default.svc
    namespace: production
  syncPolicy:
    automated:
      prune: true
      selfHeal: true  # 自动修复漂移

Push vs Pull

5. 演进路径

单体 → 容器化 → Kubernetes → Service Mesh → GitOps
  │        │           │             │           │
  │        │           │             │           └─ 声明式运维
  │        │           │             └─ 透明服务治理
  │        │           └─ 编排与弹性
  │        └─ 环境一致性
  └─ 快速启动

Dapr：通用 Sidecar 运行时

Dapr（Distributed Application Runtime）是比 Envoy 更高层次的 Sidecar，提供统一的分布式能力 API：

// Dapr SDK 调用示例
client, _ := dapr.NewClient()
defer client.Close()

// 状态存储（底层可以是 Redis / PostgreSQL / CosmosDB）
client.SaveState(ctx, "state-store", "key", []byte("value"))

// 服务调用（自动处理服务发现、重试、熔断）
resp, _ := client.InvokeMethod(ctx, "order-service", "create", "post", data)

// 发布消息（底层可以是 Kafka / RabbitMQ / Redis）
client.PublishEvent(ctx, "pubsub", "orders", orderEvent)

Dapr 的优势在于应用代码与基础设施解耦：今天用 Redis 做状态存储，明天可以无缝切换到 CosmosDB，只需改配置，不改代码。

总结

渐进式演进策略

企业落地云原生架构不必一次性引入所有模式，推荐按以下路径逐步演进：

阶段一（1-3 个月）: 容器化 + CI/CD
  └── Docker 化应用 + GitLab CI / GitHub Actions

阶段二（3-6 个月）: Kubernetes 编排 + GitOps
  └── K8s 部署 + ArgoCD / Flux 持续交付

阶段三（6-12 个月）: 可观测性 + 安全治理
  └── OTel 全链路追踪 + Istio mTLS + OPA 策略

阶段四（12 个月+）: 服务网格 + Serverless + FinOps
  └── Istio 流量治理 + Lambda/函数计算 + 成本优化

云原生不是目标，而是手段——旨在提升交付速度、系统可靠性与资源效率。对于中小型团队，建议从容器化 + GitOps 入手，逐步引入 Service Mesh 和 Serverless；大型团队则可以并行推进，利用 Dapr 统一多语言服务的分布式能力。演进路径并非线性替换，而是根据团队成熟度和业务需求分阶段引入。