云原生
Cloud Native
容器、编排、服务网格——让软件在云上弹性伸缩、自我修复。
云原生(Cloud Native)是一套在云环境中构建和运行应用的方法论和技术栈。核心组件包括:容器(Container,通过 Linux namespace 和 cgroup 实现进程隔离,Docker 是最流行的容器运行时)、容器编排(Kubernetes,声明式管理容器的部署、扩缩容、自愈)、服务网格(Service Mesh,如 Istio/Linkerd,通过 Sidecar 代理处理服务间通信、负载均衡、熔断、可观测性)、基础设施即代码(IaC,如 Terraform/Pulumi,用代码定义云资源)、不可变基础设施(Immutable Infrastructure,通过替换而非修改来更新系统)、Serverless(FaaS,按调用计价的无服务器计算)。可观测性三大支柱:日志(Logging)、指标(Metrics)、追踪(Tracing)。GitOps 将 Git 作为系统状态的唯一事实来源。
传统部署方式(手动配置服务器、大版本发布)无法满足互联网时代的需求——快速迭代、弹性伸缩、高可用。云原生通过容器化实现环境一致性('在我机器上能跑'问题消失);通过编排实现自动扩缩容和自愈(节点故障自动迁移 Pod);通过声明式 API 实现可审计、可重现的基础设施管理;通过微服务实现独立部署和团队自治。云原生使组织能够以天甚至小时为单位发布新功能,同时保持系统的高可用性。
程序员通过编写 Dockerfile 容器化应用,通过 Kubernetes YAML/Helm Chart 定义部署配置,通过 CI/CD 流水线自动构建和部署。可观测性工具(Prometheus + Grafana 监控指标,Jaeger/Zipkin 分布式追踪,ELK/Loki 日志聚合)帮助理解和诊断系统行为。理解云原生有助于理解:为什么容器比虚拟机轻量(共享内核,秒级启动);为什么 Kubernetes 使用声明式而非命令式 API(期望状态 vs 实际状态的调和循环);为什么可观测性在微服务架构中至关重要(服务数量多,调用链复杂)。
Bottom-up:由下层如何构建
本层建立在以下层级之上:
Top-down:向上暴露什么接口
Programmer View:程序员视角
我能操作吗?
通过 Docker CLI 构建容器镜像,通过 kubectl/Helm 管理 Kubernetes 资源,通过 Terraform 管理云基础设施。CI/CD 工具(GitHub Actions/GitLab CI/ArgoCD)自动化部署流程。
成本模型
| 指标 | 量级 | 备注 |
|---|---|---|
| 容器启动时间 | ~0.1-2 秒 | 远快于虚拟机(分钟级) |
| Kubernetes Pod 调度 | ~1-10 秒 | 取决于集群规模和资源 |
| Service Mesh 延迟开销 | ~1-5 ms | Sidecar 代理引入的额外延迟 |
| Serverless 冷启动 | ~100 ms-数秒 | 取决于运行时和依赖大小 |
| 云资源成本 | 按使用量计费 | CPU/内存/存储/网络分别计费 |
常见陷阱
- !Kubernetes 复杂性:K8s 概念繁多(Pod/Service/Deployment/Ingress/PV/PVC),学习曲线陡峭。小团队应评估是否需要 K8s,托管服务(ECS/Cloud Run)可能更合适
- !微服务过度拆分:过早或过度拆分微服务会导致运维成本激增(服务间通信、数据一致性、部署协调)。应从模块化单体开始,按需拆分
- !可观测性缺失:没有足够的日志、指标和追踪,分布式系统的问题排查如同大海捞针。应在系统设计阶段就规划可观测性