云原生生态
云原生不是一种技术，而是一种理念和方法的集合。
云原生（Cloud Native）这个词现在几乎无处不在，但你真的理解它的含义吗？
Cloud Native Computing Foundation（CNCF）对云原生的定义是：云原生技术使组织能够在公共云、私有云和混合云环境中构建和运行可扩展的应用。包含容器、服务网格、微服务、不可变基础设施和声明式 API。
简单来说：云原生就是为云而生的软件开发方法论。它不是「把应用搬到云上」，而是「从设计之初就考虑云环境的特性」。
四大核心特征
容器化（Containers）：应用及其所有依赖被打包成轻量级、可移植的容器镜像。Docker 是容器化的事实标准。
微服务（Microservices）：将大型应用拆分为一组小而自治的服务，每个服务独立部署、独立扩展、独立演进。服务之间通过轻量级协议通信。
不可变基础设施（Immutable Infrastructure）：基础设施的每次变更都生成新的镜像/实例，而不是在原有实例上修改。如果需要更新，重建并替换整个实例。这让环境一致性成为可能，也简化了回滚操作。
声明式 API（Declarative API）：你不告诉系统「怎么做」，你只告诉它「你想要什么」。Kubernetes 就是声明式 API 的典型代表——你声明期望状态，K8s 负责达成状态。
核心生态图谱
云原生生态非常庞大，以下是关键组件：
| 类别 | 代表项目 |
|---|---|
| 容器编排 | Kubernetes、Docker Swarm |
| 服务网格 | Istio、Linkerd、Envoy |
| 日志与监控 | Prometheus、Grafana、Fluentd、Jaeger |
| 持续交付 | ArgoCD、Tekton、Flagger |
| 存储 | Rook、Ceph、Longhorn |
| 安全 | OPA、 Falco、Vault |
| 数据库 | TiDB、CockroachDB、etcd |
Service Mesh：微服务治理的新范式
传统的微服务治理是在应用代码里做：Ribbon 做负载均衡、Hystrix 做熔断、Feign 做服务调用。但这种方式的问题是：治理逻辑和应用代码耦合，每次改治理策略都需要改代码和重新部署。
Service Mesh 把治理逻辑从应用层剥离出来，下沉到基础设施层。以 Istio 为例，它在每个 Pod 里注入一个 Sidecar 代理（Envoy），所有进出的流量都经过这个代理。负载均衡、熔断、重试、超时、mTLS 加密、流量分割……这些治理能力全部由 Sidecar 处理，应用代码完全不需要感知。
这样的好处是：治理策略的调整变成了配置变更，不需要改代码和重新部署应用。
GitOps：云原生的交付方式
GitOps 是 Weaveworks 提出的一种持续交付方法，它的核心思想是：Git 是真理的唯一来源。
在 GitOps 流程中：
- 应用的 Kubernetes 配置（YAML/Helm Chart）存放在 Git 仓库中
- 每次代码提交触发 CI 流水线，构建镜像并更新配置
- Git 仓库的变更自动同步到集群（通过 ArgoCD 等工具）
- 如果集群状态与 Git 仓库不一致，ArgoCD 会自动同步或告警
GitOps 的优势在于：完整的变更历史、可审计、可回滚、环境一致性。你不需要 SSH 到服务器手动改配置，所有变更都通过 Git 完成。
面试的核心逻辑
云原生生态的面试，核心考察你的全局视野和工程判断力：
- 概念理解：能说清楚云原生四大特征吗？微服务和传统单体架构的核心区别是什么？
- 工具选型：什么场景用 Kubernetes？什么场景用 Docker Compose？什么时候需要 Service Mesh？
- 架构思维：如何设计一个云原生架构？服务如何拆分？数据如何管理？网络如何规划？
- 工程实践：GitOps 相比传统 CI/CD 有什么优势？Service Mesh 带来了什么代价？
"云原生不是追新技术，而是解决真实问题的思路。理解云原生的『为什么』，比记住『用什么』更重要。"