云原生技术栈技术汇总 2026-05-22
云原生技术栈技术汇总
单体架构 vs 云原生架构
| 维度 | 单体架构 | 云原生架构 |
|---|---|---|
| 交付速度 | 慢,牵一发而动全身 | 快,服务独立发布 |
| 扩展性 | 粗粒度,整体复制,浪费资源 | 细粒度,按需伸缩,高效利用 |
| 可靠性 | 弱,单点故障可能导致全盘崩溃 | 强,高韧性与故障隔离、自动恢复、优雅降级 |
| 技术选型 | 单一、锁定 | 灵活、异构,为场景选最优 |
| 团队协作 | 困难,代码冲突多,协调成本高 | 高效,团队自治,边界清晰 |
| 运维复杂度 | 前期简单,后期运维噩梦 | 前期有学习成本,后期自动化程度高 |
云原生并非“银弹”。它引入了分布式系统的固有复杂性(网络延迟、数据一致性、服务发现、链路追踪等),对团队的技术能力和运维文化提出了更高要求。对于小型、简单、预期用户量不大的项目,单体架构反而可能是更务实的选择。
平台工程与云原生平台
-
内部开发者平台 (IDP)
-
Backstage (CNCF 毕业, 开发者门户)
-
DevPortal, Kratix
-
-
企业级云原生平台
-
Rancher(多集群管理), OpenShift (RedHat 全栈平台)
-
VMware Tanzu, 阿里云 ACK, 腾讯云 TKE
-
电子云 CECSTACK
-
应用开发与运行时层
-
微服务框架 Microservices 由一个较小的团队开发
-
Java: Spring Cloud, Spring Cloud Alibaba, Dubbo (Apache)
-
Go: Go-Micro, Gin, Echo
-
多语言: gRPC (CNCF 毕业, RPC 框架)
-
-
无服务器技术 Serverless
-
函数计算: 函数即服务 (FaaS) 由一个较小的团队开发
-
Knative
-
AWS Lambda
-
阿里云函数计算/SAE
-
腾讯云函数计算/SF
-
Azure Functions
-
Google Functions
-
Oracle Functions
-
-
后端即服务 (BaaS)
-
Knative (CNCF 毕业,K8s 原生 Serverless)
-
OpenFaaS, Fission
-
-
新兴运行时
-
WebAssembly: WasmEdge (CNCF 沙箱), Wasmtime
-
Unikernel: Unikraft, Nanos
-
中间件与数据服务层(云原生化的基础组件)
-
云原生数据库
-
分布式 SQL: TiDB, CockroachDB, YugabyteDB
-
时序数据库: InfluxDB, Prometheus TSDB
-
图数据库: Neo4j, NebulaGraph
-
-
缓存与搜索引擎
-
缓存: Redis, Memcached
-
搜索引擎: Elasticsearch, OpenSearch
-
-
AI/ML 云原生平台
-
Kubeflow (CNCF 毕业,机器学习工作流)
-
MLflow, Kserve (CNCF 孵化,模型服务)
-
安全与合规层
-
容器安全
-
镜像扫描: Trivy(CNCF 毕业), Clair
-
运行时安全: Falco (CNCF 毕业, 异常行为检测)
-
供应链安全: Sigstore (CNCF 毕业,镜像签名), SLSA 框架
-
-
身份与密钥管理
-
密钥管理: Vault, K8s Secret, External Secrets Operator
-
身份认证: Keycloak, OAuth2 Proxy, Dex (CNCF 毕业)
-
-
网络安全
-
网络策略: Calico, Cilium
-
零信任:核心策略是"默认拒绝、显式授权、双向验证"
-
Istio mTLS:通过Istio PeerAuthentication策略强制所有服务间通信启用 mTLS
-
SPIFFE/SPIRE (CNCF 毕业)
-
微服务中零信任的三大支柱
-
服务网格 (实现 mTLS + 细粒度授权)
-
工作负载身份 (SPIFFE/SPIRE)
-
持续运行时验证 (策略引擎 + 可观测性反馈)
-
-
落地首选技术组合: Istio (或 Linkerd) + SPIRE + OPA/Casbin + Kubernetes NetworkPolicy + eBPF 运行时安全 (如 Falco, Tetragon)
-
-
CI/CD 与 DevOps 工具链
-
持续集成 CI
-
Jenkins
-
GitLab CI
-
GitHub Actions
-
Tekton (CNCF 毕业, 云原生 CI)
-
-
持续交付 CD 与 GitOps
-
GitOps 工具: Argo CD (CNCF 毕业), Flux CD (CNCF 毕业)
-
工作流编排: Argo Workflows (CNCF 毕业), Airflow
-
-
基础设施即代码 IaC
-
Terraform, Pulumi, Crossplane (CNCF 孵化, 多云资源编排)
-
-
包管理与配置
-
Helm (CNCF 毕业,K8s 包管理)
-
Kustomize (K8s 原生配置管理)
-
可观测性 Observability
-
统一可观测平台
-
Grafana Stack: Prometheus + Loki + Tempo
-
ELK Stack: Elasticsearch + Logstash + Kibana
-
-
日志管理 Logging (常用:
ELK Stack)-
ELK Stack 核心组件:
-
Elasticsearch: 负责接收、存储和索引所有类型的数据,并能进行近实时的搜索和分析
-
Logstash: 服务器端的数据处理管道
-
Kibana
-
日志关联层通过ELK Stack聚合Envoy访问日志与应用业务日志,建立TraceID贯穿机制,实现从监控告警到链路追踪再到日志详情的一键跳转。
-
-
采集: Fluentd (CNCF 毕业), Fluent Bit
-
存储与查询: Loki (CNCF 毕业), Elasticsearch
-
Loki (+ Promtail 采集): 轻量级日志系统,只索引元数据(与 Prometheus 标签体系一致),存储成本为 ELK 的 1/5~1/10,K8s 环境下优先选用
-
-
-
指标监控 Metrics (常用: Prometheus & Grafana)
-
采集: Prometheus 云原生监控的事实标准
-
可视化: Grafana 可视化展示,仪表盘 Dashboard
-
存储: Thanos (CNCF 毕业, 长期存储), Mimir
-
Prometheus + Grafana: CNCF 事实标准,Pull 模型采集聚合指标,提供 PromQL 查询与可视化面板
-
-
-
分布式链路追踪 Tracing: 追踪请求在分布式系统中的完整调用链, 帮助定位性能瓶颈
-
追踪原理
-
Trace Id: 标记trace,全局唯一 ID
-
Span Id: 标记服务,每个服务一个
-
Parent Id: 标记前置服务
-
SpanContext: 跨服务传递上下文(TraceID、SpanID、采样状态)
-
-
标准: OpenTelemetry (CNCF 毕业, 统一采集规范)
-
后端
-
Jaeger(CNCF 毕业, 开源标杆,云原生)-
支持 Elasticsearch
-
原生数据格式: OpenTracing
-
OpenTelemetry支持: 原生支持
-
Span 数量上限: 支持 80000+ spans
-
集成Jaeger收集Envoy生成的OpenTelemetry格式追踪数据,实现跨服务调用链可视化。
-
-
SkyWalking (Apache 顶级项目,华为)
-
支持 Elasticsearch
-
原生数据格式: SkyWalking 格式
-
Span 数量上限: 支持大量 spans
-
支持 eBPF 分析
-
Zipkin(Twitter,分布式追踪领域的先驱,老前辈)-
原生数据格式: Zipkin 格式
-
OpenTelemetry支持: 需要适配器
-
Span 数量上限: 受存储限制
-
-
-
微服务与服务治理层
-
微服务架构 MSA
-
API 网关: (请求路由, 认证授权, 限流熔断, 日志监控, 协议转换, 流量控制)
-
Ingress 控制器
-
Ingress-Nginx (CNCF 毕业)
-
Traefik (简单自动配置)
-
Kong (企业级 API 管理, 丰富插件生态)
-
-
云原生网关
-
Apache APISIX (CNCF 毕业,功能全面、生态成熟的 API 管理平台)
-
极致性能
-
AI 网关
-
动态插拔
-
-
Envoy (CNCF 毕业,Envoy Gateway,极致性能、深度定制,服务网格)
-
服务网格数据平面
-
-
-
Spring Cloud Gateway (Java/Spring 技术栈内部微服务网关)
-
不建议作为集群入口网关
-
-
-
服务网格平台 Service Mesh: Sidecar
-
Istio (控制平面, 主流, CNCF 毕业, 功能全面的集成式解决方案)
-
核心代理是 Envoy (数据平面)
-
架构相对较重
-
Linkerd (数据平面, 轻量级, CNCF 毕业, 简单、轻量、高性能)
-
使用 Rust 编写, 内存占用比 Envoy 低约60%
-
-
服务发现与配置
-
配置中心: Nacos, Apollo, Consul (CNCF 毕业)
-
K8s 原生: ConfigMap, Secret
-
-
消息与事件流
-
消息队列
-
Kafka
-
分区顺序写日志(基于磁盘顺序 IO 实现超高吞吐)
-
超高吞吐、持久化
-
适用于日志采集
-
大数据 ETL
-
-
RabbitMQ
-
发送确认机制 + 事务消息
-
适用于电商金融核心业务
-
-
NATS:
-
-
事件总线
-
CloudEvents (CNCF 毕业)
-
Knative Eventing
-
-
容器编排与调度层 Container Orchestration
-
容器编排平台: 云原生微服务的基础设施底座, 实现弹性伸缩、动态扩缩容、服务自愈
-
Kubernetes: (CNCF,事实标准)-
声明式 API(即描述你想要的状态,系统自动实现)来管理复杂的分布式系统
-
-
K3s: (CNCF, 轻量级, 边缘 / 小型集群)
-
OpenShift (企业级, RedHat)
-
Rancher
-
RKE2
-
Cloud Foundry
-
Mesos
-
Nomad
-
产品
-
AWS EKS
-
阿里云 ACK
-
腾讯云 TKE
-
-
-
集群管理工具
-
集群部署: kubeadm, kubespray, kops
-
集群升级: KubeKey, Cluster API (CNCF)
-
多集群管理: Karmada (CNCF), Fleet
-
-
调度增强
-
通用调度:Koordinator (CNCF 沙箱,混部调度)
-
批处理调度:Volcano (CNCF 毕业,AI / 大数据场景)
-
大数据调度:YuniKorn (CNCF 孵化)
-
容器运行时与镜像层
-
容器运行时 Container Runtime (OCI 标准)
-
containerd(CNCF, K8s 默认) -
CRI-O(Redhat)
-
-
安全容器
-
Kata Containers(CNCF, 硬件隔离) -
gVisor (Google, 内核隔离)
-
-
容器引擎
-
技术选型
-
生产环境 Kubernetes 节点(容器运行时): Podman + CRI-O 或 containerd
-
-
Podman-
无守护进程
-
原生支持 rootless
-
兼容 Kubernetes YAML
-
原生支持 Pod
-
兼容 Docker CLI
-
可直接实现 CRI 接口 (cri-o)
-
-
Docker
-
C/S 模式, 有常驻守护进程
-
需要 root 运行
-
不支持 Pod
-
K8s 已废弃 Docker 作为运行时
-
-
nerdctl (containerd 官方 cli)
-
-
镜像与分发
-
镜像规范: OCI 镜像格式, OCI 运行时规范
-
镜像仓库: Harbor (CNCF), Quay
-
镜像构建: BuildKit, Kaniko, Buildpacks
-
计算资源
-
弹性虚拟机
-
Qemu/KVM
-
产品
-
AWS EC2
-
阿里云 ECS
-
腾讯云 CVM
-
-
-
裸金属 Ironic
-
产品
-
AWS: Nitro 系统
-
阿里云: 神龙裸金属
-
腾讯云: 黑石裸金属
-
-
云原生操作系统
-
通用
-
Ubuntu Server
-
Rocky Linux
-
CentOS Stream
-
CCLinux 自研 OS
-
-
轻量级
-
K3OS
-
Flatcar Container Linux
-
Talos Linux
-
CoreOS
-
RancherOS
-
存储资源
-
云原生存储 CNS
-
块存储 (提供虚拟机 qcow2)
-
Ceph RBD-
成熟、生产验证广泛
-
性能稳定
-
与 OpenStack/K8s 集成良好
-
缺点
-
部署运维复杂
-
资源消耗较高
-
-
-
Longhorn (CNCF) 实践证明: 不稳定
-
-
对象存储
-
MinIO (CNCF)
-
Ceph RGW
-
AWS S3
-
-
分布式文件存储
-
Ceph FS
-
GlusterFS
-
JuiceFS
-
-
存储编排
-
容器存储接口 CSI
-
Rook (CNCF)
-
网络资源: 云原生网络 CNN
-
CNI 网络插件 (Pod间通信和网络策略的核心, 选型决定了网络的性能与安全边界)
-
Calico(CNCF)-
技术选型:
单集群,稳定/安全 > 性能 -
L3路由
-
高吞吐、低延迟
-
路由模式性能接近物理网络
-
安全稳健
-
缺点
-
配置复杂, 部署和排障难度高
-
L7策略弱, 策略聚焦于L3/L4
-
-
-
Cilium(CNCF)-
技术选型:
单集群-
极致性能与可观测性: Cilium eBPF 模式 -
简化运维,快速部署: Cilium 通用模式
-
-
eBPF
-
高性能
-
可观测性
-
网络指标
-
L7网络策略: HTTP控制流量
-
缺点
-
学习曲线陡峭: eBPF技术
-
-
-
-
负载均衡 (负责将外部流量引入集群, Service/Ingress 协同工作)
-
MetalLB (适用于
裸金属 K8s)-
仅适用于裸机K8s环境
-
-
HAProxy
-
极高性能
-
配置复杂, 学习曲线陡峭
-
-
NGINX-
功能强大,集Web服务器、反向代理和负载均衡器于一体
-
开源免费,生态成熟
-
高 HTTP 吞吐
-
缺点
-
动态配置需reload,可能造成毫秒级服务中断
-
-
-
-
服务发现 (集群的“DNS导航”)
-
CoreDNS (CNCF, K8s 内置)
-
-
多集群网络-
Submariner (CNCF 沙箱)
-
Antrea (VMWare 深度绑定)
-
参考链接
更多推荐
所有评论(0)