云原生架构模式

Sidecar、Service Mesh、Serverless、FaaS、GitOps 等云原生架构模式的原理与实践。

云原生架构模式

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

1. Sidecar 模式

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

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

典型 Sidecar

Sidecar功能代表
服务代理流量管理、mTLSEnvoy
配置重载监听配置变更config-reloader
日志收集文件转发型Fluent Bit
监控 Agent指标采集Prometheus Node Exporter

2. Service Mesh

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

架构

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

Istio 核心能力

能力配置资源说明
流量管理VirtualService路由、重试、超时
灰度发布DestinationRule子集、流量比例
安全PeerAuthenticationmTLS 策略
授权AuthorizationPolicy访问控制
可观测Telemetry追踪、指标配置

何时使用 Service Mesh

适用不适用
多语言服务治理单一语言统一框架
渐进式引入安全策略性能极致敏感(增加~3ms 延迟)
跨集群流量管理简单单体或少量服务

3. Serverless 与 FaaS

模型对比

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

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

FaaS 平台

平台触发器运行时
AWS LambdaAPI Gateway/S3/SQS/…Node/Python/Go/Java
Azure FunctionsHTTP/Event Grid.NET/Node/Python
Google Cloud FunctionsHTTP/PubSubNode/Python/Go
阿里云函数计算HTTP/定时/事件多运行时

示例(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'})
    }

冷启动优化

策略效果
预置并发保持实例常驻
精简依赖减少包体积
运行时选择Go/Rust 比 Java 启动快
SnapStart恢复快照(AWS Java 专属)

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

模式Push(传统)Pull(GitOps)
触发CI 推送控制器拉取
安全性需集群访问凭据集群无需外网访问
一致性可能漂移持续调和
回滚手动Git revert 自动同步

5. 演进路径

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

总结

模式核心思想代表技术
Sidecar功能分离、独立演进Envoy, Dapr
Service Mesh治理能力下沉Istio, Linkerd
Serverless函数即服务、按需计费Lambda, 函数计算
GitOpsGit 为唯一事实来源ArgoCD, Flux

云原生不是目标,而是手段——旨在提升交付速度、系统可靠性与资源效率。

继续阅读

探索更多技术文章

浏览归档,发现更多关于系统设计、工具链和工程实践的内容。

全部文章 返回首页

「架构」更多文章

  1. 架构评审与技术债管理
  2. SLA/SLO/SLI 与容量规划
  3. CQRS 与事件溯源