云原生
云原生是以容器化、微服务、服务网格为核心的技术体系，通过 Kubernetes 实现基础设施的声明式管理，让应用具备弹性伸缩、故障隔离、快速迭代的能力。
提示
容器、Kubernetes、服务网格的云原生技术体系
什么是云原生
云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中，构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。——CNCF 定义
云原生的本质是以云为默认环境来设计应用，而不是把传统应用「搬上云」。四个核心理念：
| 理念 | 含义 | 落地技术 |
|---|---|---|
| 容器化 | 应用与环境一起打包，运行环境一致 | Docker、containerd |
| 微服务化 | 独立部署、独立演进 | Spring Boot、Go 服务 |
| 声明式 API | 描述期望状态，系统自动调和 | Kubernetes YAML |
| 不可变基础设施 | 服务器不修只换，镜像不可变 | 镜像版本化、滚动更新 |
十二要素应用
判断应用是否「云原生就绪」，经典标准是 12-Factor（Heroku 提出）：
- 基准代码一份，多环境部署（环境配置不写进代码）
- 依赖显式声明（
pom.xml、go.mod） - 配置存于环境变量（不硬编码）
- 后端服务视为可替换资源（数据库连接串可换）
- 无状态进程（状态外置到 Redis/DB，可随意水平扩展）
- 进程无共享（实例间不共享本地状态）
- 端口绑定（应用自包含监听端口，不依赖外部容器）
- 并发模型（进程内多实例，如 Go goroutine）
- 易销毁（优雅停机、快速启动）
- 开发/生产环境一致（容器天然满足）
- 日志作为事件流（stdout 输出，由平台收集）
- 管理任务作为一次性进程（迁移、初始化独立执行）
其中 第 5 条（无状态）和第 9 条（易销毁） 是能否跑在 Kubernetes 上的硬前提：K8s 随时可能杀掉并重建 Pod，有状态应用需要 StatefulSet/外部存储配合。
核心组件
云原生技术体系由四大支柱构成：容器化（运行）、编排（调度）、服务网格（网络治理）、微服务（架构），外加横切的可观测性：
容器
容器是轻量级、可移植的运行时环境，包含应用及其依赖。
| 特性 | 说明 |
|---|---|
| 隔离性 | 进程级别隔离，环境一致 |
| 轻量 | 共享宿主机内核，秒级启动 |
| 可移植 | Build Once, Run Anywhere |
| 快速迭代 | 容器镜像版本化管理 |
Kubernetes（K8s）
Kubernetes 是 Google 开源的容器编排系统，负责容器的部署、扩缩容、负载均衡。
核心概念
| 概念 | 说明 |
|---|---|
| Pod | 最小调度单元，一个 Pod 可包含多个容器 |
| Service | 统一入口，负载均衡 + 服务发现 |
| Deployment | 声明式部署，管理 Pod 副本数 |
| Namespace | 资源隔离 |
| ConfigMap/Secret | 配置管理 |
核心能力
| 能力 | 说明 |
|---|---|
| 自愈 | 节点故障时自动重启/迁移 Pod |
| 水平扩缩容 | HPA 根据 CPU/内存自动调整副本 |
| 滚动更新 | 零宕机部署，支持回滚 |
| 服务发现 | DNS 自动注册，无需手动配置 |
apiVersion: apps/v1
kind: Deployment
metadata:
name: nginx
spec:
replicas: 3
selector:
matchLabels:
app: nginx
template:
spec:
containers:
- name: nginx
image: nginx:1.21
ports:
- containerPort: 80服务网格
服务网格通过 Sidecar 代理接管服务间通信，实现连接、安全、控制、观测。
服务A → [Envoy Sidecar] → 网络 → [Envoy Sidecar] → 服务B
↓
自动处理：熔断、重试、负载均衡、mTLS加密Istio 架构
| 组件 | 职责 |
|---|---|
| Envoy | Sidecar 代理，数据面，拦截流量 |
| Pilot | 控制面，服务发现、流量管理 |
| Citadel | 证书管理，mTLS 加密 |
核心能力：流量管理（金丝雀发布、A/B 测试）、安全（mTLS 双向认证）、可观测性（分布式追踪）。
Ambient 模式（2024+）
无需 Sidecar 注入，降低资源开销。Ztunnel 代理节点级流量，Waypoint 处理 L7 策略。
演进路径
单体 → 微服务（Spring Cloud）→ Kubernetes → 服务网格（Istio）| 阶段 | 解决的问题 | 遗留问题 |
|---|---|---|
| Spring Cloud | 服务治理、配置中心 | 非业务代码占比高 |
| Kubernetes | 基础设施自动化 | 无法精细化治理 |
| Istio | 透明的网络治理 | 资源开销、学习成本 |
云原生架构的服务网格与 流量治理 紧密相关，Istio/Envoy 天然支持限流、熔断、灰度发布。
Serverless（无服务器）
云原生的下一阶段：开发者只写业务代码，不管理任何服务器。平台按需分配资源、按调用计费。
| 形态 | 代表 | 特点 |
|---|---|---|
| FaaS（函数即服务） | AWS Lambda、腾讯云 SCF | 事件驱动、毫秒级冷启动、按次计费 |
| BaaS（后端即服务） | 对象存储、消息队列、鉴权服务 | 云厂商托管，开箱即用 |
| 容器 Serverless | Knative、阿里云 ASK | 容器 + 自动扩缩容到零 |
适用：事件驱动任务（图片处理、消息转发）、波峰波谷明显的业务（秒杀、促销）、胶水逻辑（API 聚合）。 不适用：长连接服务、有状态服务、对冷启动敏感的核心链路。
选型路径：容器化（Docker）→ 编排（K8s）→ 托管（云厂商 K8s/Serverless 容器）→ FaaS。能用托管就不用自建，自建 K8s 的运维成本是隐性的大头。
适用场景
| 场景 | 推荐方案 | 原因 |
|---|---|---|
| 新建微服务项目 | Kubernetes + Spring Cloud | 基础设施自动化 + 应用层治理 |
| 已有微服务迁移 | Kubernetes 逐步容器化 | 降低迁移风险 |
| 多团队多服务治理 | 服务网格（Istio） | 透明治理，无需修改业务代码 |
| 资源敏感型项目 | 纯 Kubernetes | 避免 Sidecar 额外开销 |
FAQ
Q: Spring Cloud 和 Kubernetes 是替代关系吗？ A: 不是。Spring Cloud 在应用层解决服务治理（配置中心、熔断、网关），Kubernetes 在基础设施层解决部署、扩缩容、服务发现。两者可以共存：用 Kubernetes 管理基础设施，用 Spring Cloud 处理应用层治理。当引入服务网格后，Spring Cloud 的部分能力可以被 Istio 替代。
Q: 什么时候该引入服务网格？ A: 当微服务数量超过 50 个、团队超过 3 个、需要统一的流量治理策略时，服务网格的价值开始显现。小规模项目直接用 Spring Cloud 即可，引入服务网格会增加运维复杂度和资源开销。
Q: 容器和虚拟机有什么区别？ A: 虚拟机通过 Hypervisor 虚拟化整套硬件，每个 VM 运行独立的操作系统，启动时间分钟级；容器共享宿主机内核，通过 Namespace 和 Cgroup 实现隔离，启动时间秒级，资源开销更小。容器更适合微服务场景，虚拟机更适合需要强隔离的场景。
Q: 什么时候该上 Serverless？ A: 满足「事件驱动 + 无状态 + 冷启动可接受」时优先考虑：图片/视频处理、定时任务、消息消费、Webhook 等。业务波峰波谷明显（白天高、夜间几乎为零）时 Serverless 的按量计费优势最大。常驻流量稳定的大服务用 K8s 部署即可，Serverless 反而更贵。
Q: 自建 K8s 和用云厂商托管 K8s 怎么选？ A: 除非有强合规/私有化要求，优先用托管（ACK/EKS/GKE 等）。自建需要维护控制平面高可用、etcd、网络插件、证书轮换、版本升级，运维负担极重。托管 K8s 保留 K8s 生态的全部能力，省去控制面运维，是多数团队的最优解。