云原生架构
云原生架构 #
云原生开发方法论,基于云环境构建和运行应用,实现弹性扩展、快速迭代、高可用和自动化运维
📋 目录 #
云原生概述 #
核心定义 #
云原生是一种基于云环境构建和运行应用程序的方法论,核心目标是:
- ✅ 弹性扩展:根据负载自动扩缩容
- ✅ 快速迭代:持续交付快速上线
- ✅ 高可用性:故障自愈和容灾备份
- ✅ 自动化运维:减少人工干预
云原生核心要素 #
十二要素应用:
- 代码库:一份代码,多环境部署
- 依赖:显式声明依赖
- 配置:存储在环境中,而非代码
- 后端服务:把后端服务当作挂载资源
- 构建、发布、运行:严格分离构建和运行
- 进程:以一个或多个无状态进程运行应用
- 端口绑定:通过端口绑定提供服务
- 并发:通过进程模型进行扩展
- 易处理:快速启动和优雅终止
- 开发环境等价:开发/预发布/生产尽可能一致
- 日志:把日志当作事件流
- 管理进程:后台进程管理任务
容器化与编排 #
容器引擎 Docker #
基础核心 ⭐⭐⭐⭐⭐
作用: 将应用及其依赖打包为轻量级、可移植的容器镜像,实现环境一致性
特点:
- 轻量化:共享宿主机内核,比虚拟机更节省资源
- 环境一致性:"一次构建,到处运行"
- 隔离性:进程、网络、文件系统隔离
应用场景:
- 本地开发环境标准化
- 测试环境镜像构建
- 微服务隔离部署
- CI/CD 流水线构建
容器编排 Kubernetes (K8s) #
核心编排 ⭐⭐⭐⭐⭐
作用: 自动化容器的部署、扩缩容、负载均衡和故障恢复
核心功能:
| 功能 | 资源对象 | 说明 |
|---|---|---|
| Pod 调度 | Deployment/StatefulSet/DaemonSet | 管理Pod生命周期 |
| 服务暴露 | Service/Ingress | 服务发现和负载均衡 |
| 配置管理 | ConfigMap/Secret | 配置和敏感信息管理 |
| 存储编排 | PV/PVC | 持久化存储 |
| 自动扩缩容 | HPA/VPA | 根据负载自动扩缩容 |
应用场景:
- 管理大规模微服务集群
- 实现滚动更新和不中断发布
- 故障自动恢复和自愈
- 资源高效利用
OpenShift #
企业级容器平台
- 基于 Kubernetes 的企业级容器平台
- 集成 CI/CD 和安全管理
- 内置镜像仓库和路由
- 提供开发者自助服务
容器 vs 虚拟机对比 #
| 特性 | 容器 | 虚拟机 |
|---|---|---|
| 启动速度 | 秒级 | 分钟级 |
| 资源占用 | 共享内核,体积小 | 完整操作系统,体积大 |
| 隔离性 | 进程级隔离 | 完全硬件隔离 |
| 密度 | 单节点可跑数百个 | 单节点跑数个 |
| 网络性能 | 接近原生 | 额外开销 |
微服务架构 #
服务框架 #
| 框架 | 生态 | 特点 | 适用场景 |
|---|---|---|---|
| Spring Cloud | Java | 服务发现、配置中心、熔断 | Java 微服务开发 |
| gRPC | 跨语言 | 基于 HTTP/2 + Protocol Buffer | 高性能服务间通信 |
| Dubbo | Java/Apache | 高性能RPC | 国内微服务生态 |
服务发现与治理 #
| 组件 | 特点 | 适用场景 |
|---|---|---|
| Consul | 服务注册发现、健康检查、多数据中心 | 云原生多数据中心 |
| etcd | 分布式键值存储 | K8s 集群存储、配置中心 |
| Eureka | Spring Cloud 原生 | Java 微服务 |
| Zookeeper | 强一致性 | 分布式协调(传统架构) |
Consul vs ZooKeeper:
- Consul 提供更完善的服务发现和健康检查
- Consul 内置 DNS 接口
- Consul 天生支持多数据中心
- ZK 强一致性,但性能较低
API 网关 #
| 网关 | 特点 | 适用场景 |
|---|---|---|
| Kong | 开源,支持插件扩展 | 管理 API 流量、鉴权、限流 |
| Envoy | 高性能代理 | Sidecar、服务网格 |
| Spring Cloud Gateway | Spring 生态 | Java 微服务网关 |
| NGINX Plus | 高性能硬件 | 传统负载均衡 |
持续集成与交付 #
CI/CD 工具链 #
| 工具 | 特点 | 适用场景 |
|---|---|---|
| Jenkins | 生态丰富,插件多 | 传统企业流水线 |
| GitLab CI/CD | 与 Git 集成,内置 | GitLab 用户首选 |
| GitHub Actions | GitHub 原生 | GitHub 开源项目 |
| Argo CD | GitOps 持续交付 | Kubernetes 原生 |
| FluxCD | GitOps 工具 | Kubernetes 场景 |
GitOps 理念 #
核心思想:
- Git 仓库作为唯一事实源
- Kubernetes 配置声明式存储在 Git
- 自动同步集群状态到 Git 定义
- 可追溯、可回滚
优势:
- ✅ 所有配置版本控制
- ✅ 可审计可回滚
- ✅ 开发流程一致(git 操作)
- ✅ 环境一致性
镜像仓库 #
| 仓库 | 特点 |
|---|---|
| Harbor | 企业级私有镜像仓库,支持镜像扫描、权限管理 |
| Docker Hub | 公共镜像托管服务 |
| ACR/ECR/GCR | 云厂商托管镜像服务 |
服务网格 #
核心概念 #
Service Mesh: 专用于服务间通信的基础设施层,处理服务间的流量。
架构:
- Control Plane: 控制面,管理配置
- Data Plane: 数据面,Sidecar 代理处理流量
Istio #
主流服务网格 ⭐⭐⭐⭐
功能:
- 通过 Sidecar (Envoy) 代理管理服务间通信
- 流量治理:金丝雀发布、流量拆分、重试超时
- 可观测性:自动收集指标、链路追踪
- 安全:mTLS 加密、身份认证
应用场景:
- 微服务链路监控
- 灰度发布/金丝雀发布
- 故障注入测试
- 安全加密通信
Linkerd #
轻量级服务网格
- 更轻量,资源占用更低
- 安装简单,运维成本低
- 适合资源敏感的场景
- 功能比 Istio 简单
服务网格 vs API 网关 #
| 维度 | 服务网格 | API 网关 |
|---|---|---|
| 位置 | 服务到服务(东西向) | 入口到服务(南北向) |
| 粒度 | 每个服务实例一个代理 | 全局入口 |
| 功能 | 流量治理、安全、可观测性 | 路由、限流、鉴权 |
可观测性 #
三大支柱 #
监控与告警 #
| 工具 | 作用 |
|---|---|
| Prometheus | 时序数据库,采集指标,支持告警 |
| Grafana | 可视化展示,丰富的仪表盘 |
| Alertmanager | 告警管理,聚合分发 |
日志管理 #
| 方案 | 组成 | 特点 |
|---|---|---|
| ELK Stack | Elasticsearch + Logstash + Kibana | 功能强大,功能完整,资源消耗大 |
| Loki | Grafana Loki | 轻量级,索引少,成本低 |
| ELF | Elasticsearch + Logstash + Fluentd | 更流行的组合 |
链路追踪 #
| 工具 | 特点 | 适用场景 |
|---|---|---|
| Jaeger | CNCF 项目,来自 Uber | 云原生,分布式追踪 |
| Zipkin | Twitter 开源 | 简单易用,适合中小规模 |
| OpenTelemetry | 统一标准 | 新一代观测性框架 |
无服务器与事件驱动 #
Serverless 框架 #
| 服务 | 特点 | 适用场景 |
|---|---|---|
| AWS Lambda | 事件驱动,按需执行 | 公有云Serverless |
| Knative | Kubernetes 上构建 Serverless | 开源,支持自动扩缩容到零 |
| OpenFaaS | 轻量级函数即服务 | 开源自建 |
优势:
- 按使用付费,降低成本
- 无需管理服务器
- 自动扩缩容
- 缩短上线时间
消息队列 #
| 中间件 | 特点 | 适用场景 |
|---|---|---|
| Apache Kafka | 高吞吐,分布式 | 事件溯源、流处理 |
| RocketMQ | 低延迟,可靠 | 金融交易场景 |
| NATS | 轻量级 | 云原生低延迟 |
| RabbitMQ | 可靠路由 | 传统企业消息 |
云原生存储与数据库 #
存储编排 #
| 项目 | 特点 |
|---|---|
| Rook | 在 K8s 上管理 Ceph 等分布式存储 |
| Longhorn | 为 K8s 提供持久化块存储,轻量 |
| OpenEBS | 开源云原生块存储 |
云原生数据库 #
| 数据库 | 特点 | 适用场景 |
|---|---|---|
| CockroachDB | 分布式 SQL,兼容 PostgreSQL | 多区域部署、强一致性 |
| TiDB | MySQL 兼容,分布式 | HTAP 场景 |
| YugabyteDB | 分布式 PostgreSQL | 全球分布式应用 |
| MongoDB | 文档数据库,云原生 | 非结构化数据 |
安全与治理 #
身份与访问管理 #
| 工具 | 特点 | 适用场景 |
|---|---|---|
| Keycloak | 开源身份认证和授权 | 支持 OAuth2.0、OpenID Connect |
| SPIFFE/SPIRE | 为微服务提供统一身份标识 | X.509 证书身份 |
| OAuth2.0 | 行业标准授权框架 | 第三方授权 |
密钥管理 #
| 工具 | 特点 | 适用场景 |
|---|---|---|
| HashiCorp Vault | 集中管理敏感数据 | API 密钥、数据库密码,动态生成 |
| Kubernetes Secret | K8s 内置 | 简单场景 |
合规与治理 #
- Pod Security Standards: K8s 内置安全标准
- OPA/Gatekeeper: 策略管理,强制合规
- RBAC: 基于角色的访问控制
基础设施即代码 #
编排工具 #
| 工具 | 特点 | 适用场景 |
|---|---|---|
| Terraform | 跨云平台管理基础设施 | HCL 配置语言 |
| Pulumi | 使用通用编程语言 (Python/Go/TS) | 更灵活 |
| Crossplane | 云原生控制平面 | 扩展 K8s 管理云资源 |
配置管理 #
| 工具 | 特点 | 适用场景 |
|---|---|---|
| Ansible | 无代理,自动化配置 | 简单易用 |
| Chef/Puppet | 传统配置管理 | 企业级场景 |
IaC 优势:
- 版本控制基础设施
- 自动化部署,减少手工操作
- 环境一致性
- 可重复部署
边缘计算与混合云 #
边缘计算 #
| 方案 | 特点 | 适用场景 |
|---|---|---|
| KubeEdge | 将 K8s 扩展到边缘设备 | 支持边缘节点离线自治 |
| EdgeX Foundry | 开源边缘计算框架 | Linux 基金会项目 |
混合云 #
| 方案 | 特点 | 适用场景 |
|---|---|---|
| OpenStack | 构建私有云基础设施 | 与公有云形成混合云 |
| Anthos | Google 混合云平台 | 跨云管理 K8s 集群 |
| Azure Arc | Microsoft 混合云服务 | 跨云管理资源 |
技术选型建议 #
复杂度权衡 #
| 技术 | 功能 | 复杂度 | 学习成本 |
|---|---|---|---|
| Kubernetes | 容器编排 | 中高 | 高 |
| 服务网格 Istio | 流量治理、安全 | 高 | 高 |
| GitOps + ArgoCD | 持续交付 | 中 | 中 |
| 纯 Docker + Compose | 简单应用 | 低 | 低 |
选型原则 #
- 标准优先: Kubernetes 是事实标准,优先选择与其集成的工具
- 按需选型: 小项目不需要服务网格,不要过度设计
- 避免厂商绑定: 尽量选择可迁移的开源方案
- 团队熟悉度: 优先选择团队已有经验的技术栈
面试题汇总 #
基础篇 #
- 什么是云原生?云原生有哪些核心特征?
- 容器和虚拟机的区别?
- Docker 的核心概念:镜像、容器、仓库?
- 什么是镜像分层?有什么好处?
编排篇 #
- Kubernetes 核心架构?Master 和 Node 组件?
- Pod 是什么?为什么需要 Pod?
- Deployment 和 StatefulSet 区别?使用场景?
- Kubernetes 健康检查有哪几种?区别?
架构篇 #
- 什么是服务网格?解决什么问题?
- 可观测性三大支柱是什么?分别作用?
- GitOps 是什么?和传统 CI/CD 区别?
- 十二要素应用是哪十二要素?核心思想?
实践篇 #
- 如何在生产环境保证 K8s 稳定性?
- 云原生环境下如何做容量规划?
- 介绍一下你理解的云原生安全?
- 基础设施即代码带来什么好处?
面试题答案详解 #
基础篇 #
- 什么是云原生?云原生有哪些核心特征?
答案:
云原生是一种基于云环境构建和运行应用程序的方法论,核心目标是:
- 弹性扩展:根据负载自动扩缩容
- 快速迭代:持续交付快速上线
- 高可用性:故障自愈和容灾备份
- 自动化运维:减少人工干预
核心特征:
- 容器化:Docker等容器技术,环境一致
- 微服务:服务拆分,独立部署
- 持续交付:CI/CD自动化
- DevOps:开发运维一体化
- 可观测性:监控、日志、链路追踪
十二要素应用:
- 代码库:一份代码,多环境部署
- 依赖:显式声明依赖
- 配置:存储在环境中
- 后端服务:当作资源
- 构建、发布、运行:严格分离
- 进程:无状态
- 端口绑定:通过端口提供服务
- 并发:通过进程模型扩展
- 易处理:快速启动和优雅终止
- 开发环境等价:环境一致
- 日志:当作事件流
- 管理进程:后台管理任务
- 容器和虚拟机的区别?
答案:
| 对比项 | 容器 | 虚拟机 |
|---|---|---|
| 隔离级别 | 进程级 | 完全硬件隔离 |
| 内核 | 共享宿主机内核 | 独立操作系统 |
| 镜像体积 | 小(MB级) | 大(GB级) |
| 启动速度 | 秒级 | 分钟级 |
| 资源占用 | 低 | 高 |
| 密度 | 高(单节点数百个) | 低(单节点数个) |
| 性能 | 接近原生 | 有Hypervisor开销 |
架构:
- 虚拟机:Hypervisor层虚拟化硬件
- 容器:Docker Engine共享内核,Cgroups/Namespace隔离
- Docker 的核心概念:镜像、容器、仓库?
答案:
镜像(Image):
- 只读模板,分层存储
- 类似面向对象的类
- 包含应用和依赖
容器(Container):
- 镜像的运行实例
- 可写层
- 类似面向对象的对象
- 独立运行环境
仓库(Registry):
- 存储和分发镜像
- Docker Hub(公共)
- Harbor(私有)
关系:
Dockerfile → Build → Image → Run → Container
↓
Push/Pull ←→ Registry
- 什么是镜像分层?有什么好处?
答案:
镜像分层:
- Docker镜像由多层构成
- 每层只读(immutable)
- 基于UnionFS联合文件系统
- 容器在顶层添加可写层
好处:
- 共享基础层:多个镜像共享基础层,节省空间
- 快速构建:不变层复用,只重建变化层
- 高效分发:只传输变化层
- 版本管理:每层独立版本,便于回滚
示例:
FROM ubuntu:latest ← Layer 1 (基础层)
RUN apt update ← Layer 2
RUN apt install nginx ← Layer 3
COPY config /etc/nginx ← Layer 4
CMD ["nginx"] ← Layer 5
编排篇 #
- Kubernetes 核心架构?Master 和 Node 组件?
答案:
Master(控制面):
| 组件 | 作用 |
|---|---|
| API Server | 统一入口,处理REST请求,认证授权 |
| etcd | 分布式键值存储,保存集群状态 |
| Scheduler | 调度Pod到合适的节点 |
| Controller Manager | 控制器,维护期望状态 |
Node(工作节点):
| 组件 | 作用 |
|---|---|
| kubelet | 与Master通信,管理Pod生命周期 |
| kube-proxy | 网络代理,Service负载均衡 |
| Container Runtime | 容器运行时(containerd) |
架构图:
- Pod 是什么?为什么需要 Pod?
答案:
Pod:
- Kubernetes最小调度单元
- 包含1个或多个容器
- 共享网络栈(IP、端口)
- 共享存储
为什么需要Pod:
- 紧密耦合容器:如Sidecar模式(日志收集、代理)
- 共享网络:localhost互相访问
- 共享存储:Volume挂载到所有容器
- 原子调度:一起调度,一起销毁
Pod示例:
apiVersion: v1
kind: Pod
metadata:
name: my-pod
spec:
containers:
- name: app
image: nginx
- name: sidecar
image: busybox
command: ['watch', 'date']
- Deployment 和 StatefulSet 区别?使用场景?
答案:
| 对比项 | Deployment | StatefulSet |
|---|---|---|
| 状态 | 无状态 | 有状态 |
| Pod名称 | 随机哈希后缀 | 固定名称(web-0, web-1) |
| 网络标识 | Service统一入口 | 每个Pod有DNS名称 |
| 存储 | 共享或不共享 | 每个Pod独立持久化 |
| 启动顺序 | 同时启动 | 按顺序启动 |
| 更新策略 | 滚动更新 | 有序更新 |
使用场景:
- Deployment:Web服务、API、无状态应用
- StatefulSet:MySQL集群、Redis集群、Kafka、需要稳定标识的应用
- Kubernetes 健康检查有哪几种?区别?
答案:
三种探针:
| 探针 | 作用 | 失败行为 |
|---|---|---|
| Readiness Probe | 就绪检查:Pod是否准备好接收流量 | 从Service中移除 |
| Liveness Probe | 存活检查:Pod是否健康运行 | 重启Pod |
| Startup Probe | 启动检查:慢启动应用,避免频繁重启 | 成功后启用Liveness |
检查方式:
- HTTP GET:访问HTTP接口
- TCP Socket:尝试连接TCP端口
- Exec Command:执行命令,返回0为成功
示例:
readinessProbe:
httpGet:
path: /health/ready
port: 8080
initialDelaySeconds: 30
periodSeconds: 10
livenessProbe:
httpGet:
path: /health/live
port: 8080
initialDelaySeconds: 60
periodSeconds: 30
架构篇 #
- 什么是服务网格?解决什么问题?
答案:
服务网格(Service Mesh): 专用于服务间通信的基础设施层,处理服务间的流量。
架构:
- Control Plane(控制面): 管理配置
- Data Plane(数据面): Sidecar代理处理流量
解决的问题:
- 流量治理:金丝雀发布、流量拆分、重试超时
- 可观测性:指标、日志、链路追踪
- 安全:mTLS加密、身份认证
- 服务发现:动态路由
主流方案:
- Istio:功能强大,生态完善
- Linkerd:轻量,资源占用低
vs API网关:
| 对比项 | 服务网格 | API网关 |
|---|---|---|
| 位置 | 服务到服务(东西向) | 入口到服务(南北向) |
| 粒度 | 每个服务一个代理 | 全局入口 |
- 可观测性三大支柱是什么?分别作用?
答案:
三大支柱:
| 支柱 | 作用 | 工具 |
|---|---|---|
| Metrics(监控指标) | 系统状态、聚合数据 | Prometheus + Grafana |
| Logging(日志) | 详细事件记录、调试 | ELK / Loki |
| Tracing(链路追踪) | 请求路径、性能分析 | Jaeger / Zipkin |
详细说明:
-
Metrics:
- 时间序列数据(QPS、延迟、错误率)
- 告警和监控
- 聚合统计
-
Logging:
- 离散事件记录
- 调试和排查问题
- 日志聚合和查询
-
Tracing:
- 请求在系统中的路径
- 跨服务调用链
- 性能瓶颈分析
- GitOps 是什么?和传统 CI/CD 区别?
答案:
GitOps:
- Git仓库作为唯一事实源
- Kubernetes配置声明式存储在Git
- 自动同步集群状态到Git定义
- 可追溯、可回滚
vs传统CI/CD:
| 对比项 | GitOps | 传统CI/CD |
|---|---|---|
| 事实源 | Git仓库 | 手动命令 |
| 部署方式 | 自动同步 | 手动推送 |
| 回滚 | Git回滚 | 手动回滚 |
| 审计 | Git历史 | 日志追溯 |
| 一致性 | 声明式保证 | 需要保证 |
GitOps工具:
- ArgoCD
- FluxCD
- 十二要素应用是哪十二要素?核心思想?
答案:
十二要素:
- 代码库:一份代码,多环境部署
- 依赖:显式声明依赖
- 配置:存储在环境中,而非代码
- 后端服务:当作资源
- 构建、发布、运行:严格分离
- 进程:无状态
- 端口绑定:通过端口提供服务
- 并发:通过进程模型扩展
- 易处理:快速启动和优雅终止
- 开发环境等价:环境一致
- 日志:当作事件流
- 管理进程:后台管理任务
核心思想:
- 声明式配置
- 环境一致
- 无状态进程
- 自动化部署
实践篇 #
- 如何在生产环境保证 K8s 稳定性?
答案:
最佳实践:
- 资源限制:设置Pod的requests和limits
- 健康检查:Readiness/Liveness探针
- 副本数:至少2-3个副本,避免单点
- PodDisruptionBudget:避免同时终止过多Pod
- 自动扩缩容:HPA根据负载自动扩容
- 滚动更新:更新时保持服务可用
- 监控告警:Prometheus + Grafana + Alertmanager
- 备份恢复:定期备份etcd
- 安全加固:RBAC、网络策略、Pod Security Standards
- 云原生环境下如何做容量规划?
答案:
要点:
- 历史数据分析:根据历史负载预测
- 资源请求合理设置:requests不要太高或太低
- 自动扩缩容:HPA/VPA动态调整
- 节点资源规划:预留系统资源(20-30%)
- 超配策略:根据业务容忍度
- 监控告警:及时发现资源瓶颈
- 容量测试:压力测试验证容量
示例:
resources:
requests:
cpu: "250m"
memory: "256Mi"
limits:
cpu: "500m"
memory: "512Mi"
- 介绍一下你理解的云原生安全?
答案:
安全维度:
- 容器安全:使用最小镜像、非root用户、只读文件系统
- 网络安全:网络策略、服务网格mTLS
- 身份认证:RBAC、Keycloak、SPIFFE
- 密钥管理:HashiCorp Vault、Kubernetes Secrets
- 镜像安全:镜像扫描、签名验证
- 运行时安全:Falco、OPA/Gatekeeper
最佳实践:
- 最小权限原则
- 零信任架构
- 持续安全扫描
- 安全策略即代码
- 基础设施即代码带来什么好处?
答案:
好处:
- 版本控制:基础设施变更可追溯
- 自动化部署:减少手工操作
- 环境一致性:开发/测试/生产环境一致
- 可重复部署:相同配置可重复使用
- 团队协作:代码评审、PR流程
- 文档化:代码即文档
工具:
- Terraform:跨云基础设施管理
- Ansible:配置管理
- Pulumi:通用编程语言
🔗 相关笔记 #
最后更新: 2026-04-29