L14·10^26 – 10^30

云原生

Cloud Native

核心抽象弹性 / 声明式

容器、编排、服务网格——让软件在云上弹性伸缩、自我修复。

学习进度:
What

云原生(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 作为系统状态的唯一事实来源。

Why

传统部署方式(手动配置服务器、大版本发布)无法满足互联网时代的需求——快速迭代、弹性伸缩、高可用。云原生通过容器化实现环境一致性('在我机器上能跑'问题消失);通过编排实现自动扩缩容和自愈(节点故障自动迁移 Pod);通过声明式 API 实现可审计、可重现的基础设施管理;通过微服务实现独立部署和团队自治。云原生使组织能够以天甚至小时为单位发布新功能,同时保持系统的高可用性。

How

程序员通过编写 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 msSidecar 代理引入的额外延迟
Serverless 冷启动~100 ms-数秒取决于运行时和依赖大小
云资源成本按使用量计费CPU/内存/存储/网络分别计费

常见陷阱

  • !Kubernetes 复杂性:K8s 概念繁多(Pod/Service/Deployment/Ingress/PV/PVC),学习曲线陡峭。小团队应评估是否需要 K8s,托管服务(ECS/Cloud Run)可能更合适
  • !微服务过度拆分:过早或过度拆分微服务会导致运维成本激增(服务间通信、数据一致性、部署协调)。应从模块化单体开始,按需拆分
  • !可观测性缺失:没有足够的日志、指标和追踪,分布式系统的问题排查如同大海捞针。应在系统设计阶段就规划可观测性