云原生架构模式
云原生(Cloud Native)是一套技术体系与方法论,旨在充分利用云计算的弹性、分布式与自动化能力。Sidecar、Service Mesh、Serverless、GitOps 是其核心模式。
1. Sidecar 模式
将辅助功能从主容器中剥离,以独立容器部署。
┌────────────────────── Pod ──────────────────────┐
│ ┌─────────────┐ ┌─────────────┐ │
│ │ App Container│ ↔ │ Sidecar │ │
│ │ (业务逻辑) │ │ (Proxy/Log/ │ │
│ │ │ │ Monitor) │ │
│ └─────────────┘ └─────────────┘ │
│ ↑ ↑ │
│ localhost localhost │
└─────────────────────────────────────────────────┘
典型 Sidecar
| Sidecar | 功能 | 代表 |
|---|---|---|
| 服务代理 | 流量管理、mTLS | Envoy |
| 配置重载 | 监听配置变更 | 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 | 子集、流量比例 |
| 安全 | PeerAuthentication | mTLS 策略 |
| 授权 | AuthorizationPolicy | 访问控制 |
| 可观测 | Telemetry | 追踪、指标配置 |
何时使用 Service Mesh
| 适用 | 不适用 |
|---|---|
| 多语言服务治理 | 单一语言统一框架 |
| 渐进式引入安全策略 | 性能极致敏感(增加~3ms 延迟) |
| 跨集群流量管理 | 简单单体或少量服务 |
3. Serverless 与 FaaS
模型对比
传统: IaaS → CaaS → PaaS → FaaS
VM → 容器 → 平台 → 函数
Serverless 特征:
- 代码即部署单元
- 事件触发、自动扩缩
- 按调用计费
- 无服务器运维
FaaS 平台
| 平台 | 触发器 | 运行时 |
|---|---|---|
| AWS Lambda | API Gateway/S3/SQS/… | Node/Python/Go/Java |
| Azure Functions | HTTP/Event Grid | .NET/Node/Python |
| Google Cloud Functions | HTTP/PubSub | Node/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)
- 声明式系统:系统状态由声明式配置描述
- 版本化与不可变:Git 记录所有变更历史
- 自动拉取:控制器持续同步期望状态与实际状态
- 持续协调:状态漂移时自动修复
典型工作流
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, 函数计算 |
| GitOps | Git 为唯一事实来源 | ArgoCD, Flux |
云原生不是目标,而是手段——旨在提升交付速度、系统可靠性与资源效率。
继续阅读
探索更多技术文章
浏览归档,发现更多关于系统设计、工具链和工程实践的内容。