{"name":"云原生","id":"软件工程-架构-系统设计-云原生","content":"# 云原生\n\n云原生（Cloud Native）代表了现代软件架构从传统部署方式向平台化、自动化、弹性化的系统范式转变。它不仅是一组技术集合，更是一个**应用架构模型、平台能力体系与运营治理模型的统一框架**。\n\n本文从本质、核心模型、能力体系、架构分层、治理体系、类型分类、平台工程、演进趋势等角度，系统化呈现云原生知识体系。\n\n---\n\n## 云原生的本质\n\n云原生的本质可以抽象为三大核心：\n\n### 应用架构的现代化\n\n应用通过容器化、微服务化、无状态化、声明式核心能力构建，使应用具备可移植、可扩展、自愈与灵活交付的能力。\n\n核心特性包括：\n\n* 不可变基础设施\n* 无状态进程与横向扩缩容\n* 服务边界清晰的松耦合架构\n* 标准化接口与协议\n\n### 平台能力的统一抽象\n\n云原生利用 Kubernetes 等技术将计算、存储、网络、调度、安全等能力统一抽象为**平台层 API**，从而屏蔽底层基础设施差异，实现应用与基础设施的解耦。\n\n### 运行模型的声明式与自动化\n\n云原生使用声明式 API、IaC、GitOps、自动调度、自愈机制构建统一执行模型，从而实现：\n\n* 自动化部署与回滚\n* 自动扩缩容\n* 一致性环境\n* 事件驱动与声明式状态收敛\n\n这三部分共同形成云原生的核心定义：\n**云原生是“应用架构 + 平台能力 + 声明式运行模型”的统一体系。**\n\n---\n\n## 核心抽象模型\n\n为了从系统工程角度统一理解云原生能力，本篇文档采用三个关键抽象：\n\n### 云原生三维核心模型\n\n云原生能力可定义为三大维度：\n\n#### 应用维度\n\n应用如何设计、交付、运行，包括：\n\n* 12-Factor 应用模型\n* 微服务架构\n* 无状态与幂等性\n* 服务治理模型\n\n#### 平台维度\n\n平台如何承载和调度应用，包括：\n\n* 容器运行时\n* Kubernetes 编排\n* 服务网格\n* 网络、存储、安全等基础能力\n\n#### 运行模型维度\n\n系统如何交付、变更、扩缩、恢复：\n\n* IaC / GitOps\n* 自动化调度\n* 资源治理\n* 自愈机制\n* 可观测性与事件驱动\n\n三维模型帮助团队从战略层理解云原生，而非陷入工具视角。\n\n---\n\n## 云原生平台与应用的四层结构\n\n云原生系统可分为四个抽象层级，它们共同构成完整的平台体系：\n\n### 应用层\n\n* 微服务\n* 无状态、可扩展应用\n* Serverless 函数\n* 应用交付流程（构建、发布、灰度）\n\n### 平台层（云原生核心）\n\n* Kubernetes 编排\n* 服务网格\n* API Gateway\n* 配置管理与密钥管理\n* 统一日志/监控/追踪模型\n\n### 基础设施层\n\n* 计算（VM、Bare Metal、GPU）\n* 网络（CNI、负载均衡）\n* 存储（CSI、对象存储、分布式存储）\n* 镜像仓库、网络策略\n\n### 管理与治理层\n\n* 可观测性体系\n* 安全与零信任模型\n* 成本治理\n* 资源调度策略\n* 合规与审计\n\n四层结构强调云原生并非只是技术栈，而是一套整体系统。\n\n---\n\n## 云原生应用模型\n\n### 十二要素应用模型（12-Factor）\n\n12-Factor 模型依然是构建云原生应用的基础规范，包含代码一致性、依赖管理、配置外部化、日志事件化、无状态进程等要求。\n\n**其核心贡献在于为“可移植、可扩展、可自动化”提供标准。**\n\n### 应用运行模型\n\n云原生应用需要满足：\n\n* 能快速启动与优雅终止\n* 能完全靠外部配置运行\n* 能在任意节点无差别部署\n* 能在容器环境中自小规模扩展\n\n这些要求直接影响 CI/CD、缩容策略、调度策略。\n\n---\n\n## 云原生能力体系（能力树模型）\n\n云原生能力可抽象为六大类，每类包含多项底层能力：\n\n### 交付能力\n\n* 持续集成（CI）\n* 持续交付/部署（CD）\n* 镜像规范、版本化控制\n* 灰度发布、金丝雀发布、蓝绿发布\n\n### 弹性能力\n\n* HPA/VPA\n* 节点与 Pod 自愈\n* 水平、垂直扩缩容\n* 异地多活架构\n\n### 可观测性\n\n* 指标（Metrics）\n* 日志（Logging）\n* 链路追踪（Tracing）\n* 基于事件的告警\n\n### 安全能力\n\n* 身份认证与授权（RBAC）\n* mTLS / 零信任\n* 镜像与供应链安全\n* 策略管控（OPA/Gatekeeper）\n\n### 网络能力\n\n* 服务发现\n* 负载均衡\n* 服务网格\n* 网关与入口控制器\n\n### 存储能力\n\n* 持久化卷（PV/PVC）\n* 动态存储供应\n* 多可用区存储\n* 数据一致性与快照\n\n能力树帮助团队构建平台边界与技术规划。\n\n---\n\n## 云原生架构模型\n\n### 控制面、数据面与管理面模型\n\n云原生治理可抽象为三种角色：\n\n#### 数据面（Data Plane）\n\n处理实际应用流量：\n\n* Envoy Sidecar\n* 容器运行时\n* Ingress/Service Proxy\n\n#### 控制面（Control Plane）\n\n负责策略与调度：\n\n* Kubernetes Scheduler\n* Istio Pilot\n* API Gateway 控制器\n\n#### 管理面（Management Plane）\n\n负责全局管理：\n\n* K8s API Server\n* GitOps 控制器\n* 日志/监控控制器\n\n该模型有助于定义职责与边界。\n\n---\n\n## 云原生边界与取舍\n\n云原生落地过程中存在多种边界与权衡：\n\n### 微服务边界\n\n* 自治性提升 ↔ 系统复杂度提升\n* 服务拆分粒度过小会导致治理成本暴涨\n\n### 服务网格边界\n\n* 增强治理能力 ↔ Sidecar 成本增高\n* 延迟、资源占用、流量路径变复杂\n\n### 多云边界\n\n* 避免厂商绑定 ↔ 技术栈统一难度极高\n* 成本与运维复杂度暴涨\n\n### Serverless 边界\n\n* 弹性极强 ↔ 冷启动和调试困难\n* 适合事件驱动，不适合高并发低延迟核心链路\n\n这些边界是云原生平台规划不可绕过的内容。\n\n---\n\n## 云原生生态体系\n\n生态可分为以下典型类别：\n\n* 容器与运行时：Docker、containerd\n* 编排平台：Kubernetes、OpenShift\n* 服务网格：Istio、Linkerd\n* 可观测性：Prometheus、Grafana、Jaeger\n* CI/CD：Jenkins、GitLab CI、Tekton\n* 安全与供应链：Notary、Trivy、Falco\n\n生态图帮助团队理解技术选择空间。\n\n---\n\n## 平台工程视角下的云原生\n\nPlatform Engineering 逐渐成为云原生落地的主导方向。\n其目标是构建 **内部开发者平台（IDP）**，提供自助式交付与标准化开发路径（Golden Path）。\n\n核心包括：\n\n* 标准化开发模板\n* 自动化环境搭建\n* 统一发布控制\n* 统一可观测能力\n* 自动化安全扫描\n* 内部 API 文档化与治理\n\n云原生技术成为平台工程的基础，而平台工程是云原生的落地形态。\n\n---\n\n## 演进趋势\n\n### 技术趋势\n\n* Serverless 2.0\n* 边缘云原生化\n* GPU 与 AI 原生调度\n* 安全供应链治理\n\n### 架构趋势\n\n* 服务网格向数据网格/存储网格延伸\n* 多集群联邦化\n* 平台工程主导的 PaaS 化\n\n### 运维趋势\n\n* GitOps 大规模应用\n* AIOps 与智能运维\n* 混沌工程成为韧性保障核心\n\n---\n\n## 云原生选型方法论\n\n选型应基于以下维度：\n\n### 技术成熟度\n\n社区活跃度、版本稳定性、生态规模\n\n### 运维复杂度\n\n学习成本、集群规模、治理成本\n\n### 安全性\n\n零信任能力、供应链安全、策略库\n\n### 性能\n\n资源开销、延迟表现\n\n### 成本效益\n\n资源成本、管理成本、云平台费用\n\n选型不仅看技术“是否先进”，更要看团队是否能长期承载。\n\n---\n\n## 总结\n\n云原生不是单一技术，而是应用架构、平台能力、治理体系与自动化运行模型的集合。\n\n## 关联内容（自动生成）\n\n- [/软件工程/DevOps.md](/软件工程/DevOps.md) DevOps是云原生的重要组成部分，共同构成了现代化软件交付和运维体系，强调文化、自动化、度量和共享\n- [/运维/K8s.md](/运维/K8s.md) Kubernetes是云原生生态的核心编排平台，提供了容器化应用的部署、扩展和管理能力\n- [/操作系统/容器化.md](/操作系统/容器化.md) 容器化是云原生的基础技术，提供了应用封装、隔离和可移植性的核心能力\n- [/运维/Docker.md](/运维/Docker.md) Docker是容器化技术的代表实现，为云原生应用提供了标准化的打包和运行环境\n- [/软件工程/微服务/微服务.md](/软件工程/微服务/微服务.md) 微服务架构是云原生应用的主要设计模式，强调服务的自治性、无状态性和松耦合\n- [/软件工程/微服务/ServiceMesh/ServiceMesh.md](/软件工程/微服务/ServiceMesh/ServiceMesh.md) 服务网格是云原生架构中处理服务间通信的关键组件，提供了流量控制、安全和可观测性\n- [/软件工程/架构/Serverless.md](/软件工程/架构/Serverless.md) Serverless是云原生演进的高级形态，代表了更极致的弹性、自动化和按需付费模式\n- [/运维/持续集成.md](/运维/持续集成.md) 持续集成是云原生CI/CD体系的重要环节，确保代码变更能够快速、安全地集成到主干\n- [/运维/持续交付.md](/运维/持续交付.md) 持续交付与云原生紧密结合，提供了从开发到生产的全自动化交付流水线\n- [/软件工程/微服务/服务治理/服务治理.md](/软件工程/微服务/服务治理/服务治理.md) 服务治理是微服务和云原生架构中确保服务稳定性和可管理性的关键能力\n- [/操作系统/虚拟化.md](/操作系统/虚拟化.md) 虚拟化技术是容器化和云原生的基础，提供了资源隔离和抽象的底层支撑\n- [/软件工程/架构/系统设计/网关.md](/软件工程/架构/系统设计/网关.md) API网关在云原生架构中承担南北向流量管理，与服务网格协同构成完整的流量治理体系\n- [/中间件/消息队列/消息队列.md](/中间件/消息队列/消息队列.md) 消息队列在云原生架构中支撑异步通信、事件驱动和解耦，特别在Serverless场景中应用广泛\n","metadata":"tags: ['分布式系统', '软件工程']","hasMoreCommit":false,"totalCommits":7,"commitList":[{"date":"2026-02-12T14:07:03+08:00","author":"MY","message":"doc: 整理标签","hash":"290b3e8ad18f48832ac282290238d020fc030a88"},{"date":"2025-12-01T15:29:31+08:00","author":"MY","message":"docs(microservice): 删除微服务部署相关文档及引用","hash":"b66a4cfdadb09e0a422eb01accbb1d29dfcee310"},{"date":"2025-12-01T14:52:15+08:00","author":"MY","message":"docs(微服务): 删除服务监控文档并更新相关引用","hash":"642172996d1e1c114a8d7ef92b454749e7b49c95"},{"date":"2025-11-20T13:47:37+08:00","author":"MY","message":"docs(cloud-native): 重构云原生系统设计文档","hash":"fbd125f74f54cb83d3f2ef0937df7d7bbd4cc17f"},{"date":"2025-09-21T14:03:43+08:00","author":"MY","message":"docs(mindmap): 统一思维导图根节点格式","hash":"44fc90fa0f22040d171dbf83cd6f2fd8c020444a"},{"date":"2024-04-08T19:46:01+08:00","author":"MY","message":"✏云原生","hash":"980e034b6b4b072f0eb7fbb897b1978f4cef3413"},{"date":"2023-09-12T13:49:02+08:00","author":"MY","message":"📦云原生","hash":"4c213f91c490c073914b5d702ed791d18d3d3d99"}],"createTime":"2023-09-12T13:49:02+08:00"}