157 lines
3.8 KiB
Markdown
157 lines
3.8 KiB
Markdown
# Cloud-Native
|
||
|
||
> **Cloud-Native** — 一种构建和运行应用程序的方法，充分利用云计算交付模型，将计算、存储和网络作为可弹性扩展的服务。
|
||
|
||
## Definition
|
||
|
||
云原生（Cloud-Native）是一套技术方法论和最佳实践，用于：
|
||
|
||
- 构建可在云环境中弹性运行的应用程序
|
||
- 利用云平台的托管服务和自动化能力
|
||
- 采用 DevOps 和 CI/CD 实践
|
||
- 使用容器、无服务器和微服务架构
|
||
|
||
## Cloud-Native Computing Foundation (CNCF)
|
||
|
||
CNCF 定义了云原生的核心技术要素：
|
||
|
||
```
|
||
Cloud-Native Stack:
|
||
├── Container Runtime (containerd, CRI-O)
|
||
├── Orchestration (Kubernetes)
|
||
├── Service Mesh (Istio, Linkerd)
|
||
├── Observability (Prometheus, Grafana)
|
||
├── Networking (CNI, Envoy)
|
||
└── Storage (CSI)
|
||
```
|
||
|
||
## 12-Factor App Methodology
|
||
|
||
云原生应用遵循 12-Factor 原则：
|
||
|
||
| # | 因素 | 描述 |
|
||
|---|------|------|
|
||
| 1 | Codebase | 单一代码库，版本控制 |
|
||
| 2 | Dependencies | 明确声明依赖 |
|
||
| 3 | Config | 配置与环境分离 |
|
||
| 4 | Backing Services | 将服务视为资源 |
|
||
| 5 | Build, Release, Run | 严格分离构建和运行 |
|
||
| 6 | Processes | 无状态进程 |
|
||
| 7 | Port Binding | 通过端口绑定导出服务 |
|
||
| 8 | Concurrency | 通过进程模型扩展 |
|
||
| 9 | Disposability | 快速启动和优雅关闭 |
|
||
| 10 | Dev/Prod Parity | 开发、预发、生产环境一致 |
|
||
| 11 | Logs | 将日志视为事件流 |
|
||
| 12 | Admin Processes | 将管理任务作为一次性进程 |
|
||
|
||
## Core Technologies
|
||
|
||
### Containers
|
||
|
||
**优势**
|
||
- 轻量级虚拟化
|
||
- 环境一致性
|
||
- 快速启动
|
||
- 资源隔离
|
||
|
||
**关键工具**
|
||
- Docker, containerd, Podman
|
||
- OCI 镜像规范
|
||
|
||
### Kubernetes
|
||
|
||
**核心概念**
|
||
- Pod（最小调度单元）
|
||
- Deployment（声明式更新）
|
||
- Service（网络抽象）
|
||
- Ingress（HTTP 路由）
|
||
- ConfigMap/Secret（配置管理）
|
||
|
||
**生态组件**
|
||
- Helm (包管理)
|
||
- Kustomize (配置管理)
|
||
- Operators (自愈自动化)
|
||
|
||
### Service Mesh
|
||
|
||
**功能**
|
||
- 零信任网络安全
|
||
- 可观测性（追踪、指标、日志）
|
||
- 流量管理（A/B 测试、金丝雀发布）
|
||
- 熔断和限流
|
||
|
||
**工具**
|
||
- Istio, Linkerd, Consul Connect
|
||
|
||
### Serverless
|
||
|
||
**优势**
|
||
- 零服务器管理
|
||
- 弹性扩展
|
||
- 按使用付费
|
||
- 快速原型
|
||
|
||
**服务**
|
||
- AWS Lambda, Azure Functions, GCP Cloud Functions
|
||
- Knative, OpenFaaS
|
||
|
||
### Observability
|
||
|
||
**三大支柱**
|
||
- **指标 (Metrics)** — Prometheus, Datadog
|
||
- **日志 (Logs)** — ELK Stack, Loki
|
||
- **追踪 (Traces)** — Jaeger, Zipkin
|
||
|
||
## Cloud-Native Maturity Model
|
||
|
||
| Level | 特征 |
|
||
|-------|------|
|
||
| **L1: Containerized** | 应用程序容器化 |
|
||
| **L2: Orchestrated** | 容器编排（K8s） |
|
||
| **L3: Microservices** | 微服务架构 |
|
||
| **L4: Meshed** | 服务网格 |
|
||
| **L5: Auto-Pilot** | 自主运维、自愈 |
|
||
|
||
## Cloud-Native vs Traditional
|
||
|
||
| 维度 | Cloud-Native | Traditional |
|
||
|------|-------------|-------------|
|
||
| **架构** | 微服务 | 单体 |
|
||
| **部署** | 容器 | 物理机/VM |
|
||
| **扩展** | 自动、弹性 | 手动、垂直 |
|
||
| **交付** | CI/CD | 传统发布 |
|
||
| **可用性** | 多副本 | 主备 |
|
||
| **成本** | 按需 | 固定 |
|
||
| **恢复** | 自动故障转移 | 手动恢复 |
|
||
|
||
## Best Practices
|
||
|
||
### Design for Failure
|
||
|
||
- 幂等性设计
|
||
- 超时和重试
|
||
- 熔断器模式
|
||
- 限流保护
|
||
|
||
### Observability
|
||
|
||
- 结构化日志
|
||
- 分布式追踪
|
||
- 指标和告警
|
||
- 健康检查
|
||
|
||
### Security
|
||
|
||
- 零信任架构
|
||
- 最小权限
|
||
- 密钥管理
|
||
- 镜像安全扫描
|
||
|
||
## See Also
|
||
|
||
- [[Cloud Maturity Model]] — 云成熟度模型
|
||
- [[DevOps Maturity]] — DevOps 成熟度
|
||
- [[Kubernetes]] — K8s
|
||
- [[Microservices]] — 微服务
|
||
- [[Service Mesh]] — 服务网格
|