云原生（Cloud Native）全面解析

一、核心定义

云原生（Cloud Native） 是一种构建和运行应用的方法论，充分利用云计算优势，实现快速交付和弹性伸缩。

CNCF 官方定义

云原生技术使组织能够在公有云、私有云和混合云等现代动态环境中，构建和运行可弹性扩展的应用。

四大核心特征

容器化（Containerization）：应用打包为容器镜像
微服务（Microservices）：松耦合的服务架构
动态编排（Orchestration）：K8s 自动化管理
DevOps：CI/CD 快速迭代

二、云原生 vs 传统架构

对比项	传统架构	云原生
部署方式	物理机/虚拟机	容器 + K8s
扩展性	手动加机器	自动弹性伸缩
发布周期	月/季度	周/天（持续交付）
故障恢复	人工介入	自愈（Pod 重启）
资源利用	30-40%	60-80%
多云支持	绑定厂商	跨云迁移

三、云原生技术栈

CNCF Landscape 核心组件

容器运行时: Docker / containerd
编排调度: Kubernetes
服务网格: Istio / Linkerd
可观测性: Prometheus + Grafana + Jaeger
CI/CD: GitLab CI / ArgoCD / Tekton
镜像仓库: Harbor
配置管理: Helm / Kustomize
安全: Falco / OPA

典型架构

┌──────────────────────────────────┐
│      CI/CD Pipeline              │
│  (GitLab CI → ArgoCD → K8s)      │
└───────────┬──────────────────────┘
            ↓
┌──────────────────────────────────┐
│    Kubernetes Cluster            │
│  ┌────────────────────────────┐  │
│  │  Istio (Service Mesh)      │  │
│  └─────────┬──────────────────┘  │
│            ↓                     │
│  ┌─────────────┐ ┌────────────┐ │
│  │ Microservice│ │Microservice│ │
│  │     A       │ │     B      │ │
│  └─────────────┘ └────────────┘ │
└──────────────────────────────────┘
            ↓
┌──────────────────────────────────┐
│   Observability Stack            │
│  Prometheus + Grafana + Jaeger   │
└──────────────────────────────────┘

四、12 要素应用（The Twelve-Factor App）

云原生应用设计原则：

要素	说明	示例
代码库	版本控制，一份代码多环境部署	Git + 分支策略
依赖	显式声明依赖	`pom.xml`、`requirements.txt`
配置	配置与代码分离	ConfigMap、环境变量
后端服务	服务即资源	数据库、MQ 可替换
构建发布运行	严格分离	CI 构建 → CD 发布
无状态进程	应用无状态	Session 存 Redis
端口绑定	自包含服务	Spring Boot 内嵌 Tomcat
并发	水平扩展	`kubectl scale`
快速启动	秒级启动关闭	容器化
开发环境一致	Dev 与 Prod 相同	Docker 镜像
日志	日志流处理	stdout → ELK
管理进程	一次性任务	K8s Job

五、Kubernetes 核心能力

1. 声明式 API

# 声明期望状态，K8s 自动调谐
apiVersion: apps/v1
kind: Deployment
metadata:
  name: nginx
spec:
  replicas: 3  # 期望 3 个副本
  template:
    spec:
      containers:
      - name: nginx
        image: nginx:1.21

2. 自动化运维

能力	说明
自愈	Pod 挂掉自动重启
弹性伸缩	HPA 根据 CPU/内存自动扩容
滚动更新	零停机发布
服务发现	Service 自动负载均衡

3. HPA 自动扩缩容示例

apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
  name: app-hpa
spec:
  scaleTargetRef:
    apiVersion: apps/v1
    kind: Deployment
    name: my-app
  minReplicas: 2
  maxReplicas: 10
  metrics:
  - type: Resource
    resource:
      name: cpu
      target:
        type: Utilization
        averageUtilization: 70  # CPU > 70% 扩容

六、DevOps 与 GitOps

CI/CD 流程

开发提交代码 → Git Push
    ↓
CI 自动触发 (GitLab CI)
    ↓
编译 → 单元测试 → 构建镜像 → 推送到 Harbor
    ↓
CD 自动部署 (ArgoCD)
    ↓
K8s 滚动更新 → 健康检查
    ↓
Prometheus 监控告警

GitOps 示例

# Git 仓库存储 K8s YAML
# ArgoCD 监听 Git 变化自动同步
apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: my-app
spec:
  source:
    repoURL: https://github.com/myrepo/k8s-manifests
    path: production
  destination:
    server: https://kubernetes.default.svc

七、可观测性（Observability）

三大支柱

指标（Metrics）：Prometheus 采集 QPS、延迟
日志（Logs）：ELK Stack 集中管理
链路追踪（Tracing）：Jaeger 分布式追踪

Prometheus 监控示例

// Spring Boot Actuator 暴露指标
@RestController
public class OrderController {
    
    @Timed(value = "order.create")  // 自动采集耗时
    @PostMapping("/order")
    public Order create(@RequestBody OrderDTO dto) {
        return orderService.create(dto);
    }
}

八、云原生的挑战

挑战	解决方案
学习曲线陡	分阶段引入（容器化 → K8s → 服务网格）
运维复杂	使用托管 K8s（阿里云 ACK、AWS EKS）
成本问题	资源配额管理、Spot 实例降成本
安全风险	OPA 策略控制、镜像扫描（Trivy）

九、落地路径

阶段 1：容器化（3-6 个月）

Docker 化现有应用
镜像仓库搭建（Harbor）
CI/CD 集成

阶段 2：K8s 编排（6-12 个月）

部署 K8s 集群
应用迁移到 K8s
配置 HPA、健康检查

阶段 3：服务网格（12-18 个月）

引入 Istio
灰度发布、流量治理
可观测性完善

十、答题总结

2 分钟框架：

定义：云原生是一套方法论，利用容器、微服务、K8s 实现弹性高效的应用
核心技术：
- 容器化（Docker）
- 编排（Kubernetes）
- 服务网格（Istio）
- DevOps（GitOps）
关键价值：
- 快速交付（CI/CD 自动化）
- 弹性伸缩（HPA 自动扩容）
- 高可用（自愈、滚动更新）
12 要素：无状态、配置分离、日志流等
挑战：学习曲线、运维复杂度（可用托管 K8s）

加分点：提及 CNCF、12 要素、GitOps、可观测性三大支柱