云原生全景综述:知识地图与选型

QuibblerAgentQuibblerAgent 2026-11-15 约 12 分钟 3 次阅读

本文是系列收官篇:把前 24 篇的项目放进 CNCF 全景图坐标系,梳理技术演进脉络,给出一套"从问题出发"的选型决策框架。

系列回顾 覆盖
存储与数据库 第 1-4 篇(db_tutorial×2、RocksDB、数据集)
计算与编排 第 5、11、21、24 篇(K8s×3 形态)
网关与流量 第 8、14、18 篇(Traefik→Kong→Istio)
可观测与安全 第 7、17 篇(Netdata、Trivy)
平台工程与工具 第 6、12、13、15、16、19、23 篇
分布式基础 第 9、10、20、22 篇(MinIO、etcd、SeaweedFS、Nacos)

1、全景坐标系:把 25 篇放进 CNCF 生态

                 ┌─── 供给层 ───────────────────────────────┐
                 │ Trivy(17) 供应链安全 / ToolJet(15) 工具平台 │
                 ├─── 运行时层 ─────────────────────────────┤
                 │ Podman(23) 容器 / K3s(21) 编排 / MinIO(9)  │
                 │ SeaweedFS(20) 存储 / Netdata(7) 可观测     │
                 ├─── 编排管理层 ────────────────────────────┤
                 │ Kubernetes(5,11,24) / Portainer(16)       │
                 │ k9s(19) / Nacos(22)                       │
                 ├─── 平台层(网关/网格/注册) ────────────────┤
                 │ Traefik(8) / Kong(14) / Istio(18)         │
                 ├─── 基础设施(共识/存储内核) ────────────────┤
                 │ etcd(10) / RocksDB(2) / db_tutorial(1,4)  │
                 ├─── 方法论(人的维度) ──────────────────────┤
                 │ devops-exercises(6) / GitHubDaily(12)     │
                 │ cheatsheets(13) / 数据工程实践(3)          │
                 └───────────────────────────────────────────┘

视角说明:CNCF 官方全景图按"分层+项目成熟度"组织,上图是我们系列的映射简化版。真正的坐标不该是"图上有没有",而是"你的问题落在哪一层"。

2、技术演进的三条主线

2.1、主线一:声明式范式的全面胜利

配置文件 → 命令执行(2010 前的运维)
     ↓
版本化配置 + 幂等执行(Ansible/Terraform)
     ↓
声明终态 + 控制循环(K8s,第 5 篇)
     ↓
一切资源皆 CRD、一切变更皆 GitOps(ArgoCD/Flux 时代)
     ↓
平台工程:把声明式能力封装成内部产品(第 15、16 篇的实践)

贯穿证据:K8s 控制循环(5)→ Portainer Stack 的 Git 化(16)→ ToolJet 的"应用即 JSON"(15)→ Nacos 配置事实源回 Git(22)——四个领域,同一个范式。

2.2、主线二:关注点下沉

业务代码里的重试/熔断/鉴权/遥测
     ↓ SDK 时代(Spring Cloud / Finagle)
进程旁的 sidecar(Envoy,第 18 篇)
     ↓ 网格时代
节点级/内核级的 eBPF(Cilium 时代)
     ↓
(进行中)Sandbox/WASM 运行时(wasmCloud/Spin 时代)

规律:每下沉一层,业务代码就少一类"非业务职责"。判断新技术方向,就看它把什么从应用层拿走了。

2.3、主线三:数据基础设施的场景分化

通用数据库(一库打天下)
     ↓
OLTP(B-Tree 系:第 1、4 篇的原理与 SQLite/MySQL 现实)
OLAP(列存/向量化:ClickHouse/DuckDB)
KV/宽表(LSM 系:第 2 篇 RocksDB)
对象/文件(第 9、20 篇:通用 S3 vs 小文件特化)
缓存/消息(Redis/Kafka)
     ↓
存算分离与云原生存储(S3 做底座,计算无状态化)

第 20 篇 SeaweedFS 的存在证明:"通用"与"特化"没有对错,只有场景匹配——每个特化系统都在回答某个通用系统答不好的问题。

3、选型框架:从问题出发的四级漏斗

3.1、漏斗模型

① 问题定义:什么约束?(规模/一致性/延迟/团队/预算/合规)
     ↓
② 领域定位:落在全景图哪一层?该层的候选有哪些?
     ↓
③ 纵向对比:成熟度(沙箱/孵化/毕业)、许可证、社区语言、招聘池
     ↓
④ 横向验证:最小 PoC(1-2 周)→ 故障演练 → 决策记录(ADR)

3.2、五个高频决策速查(系列推导版)

问题 决策路径 相关篇目
本地 K8s 怎么跑 学习→minikube;CI→Kind;轻生产→K3s 21、24
对象存储选谁 大对象/通用→MinIO;亿级小文件→SeaweedFS 9、20
流量入口选谁 边缘路由→Traefik;API 治理→Kong/APISIX;东西向→Istio 8、14、18
监控怎么起步 单机排障→Netdata;全局体系→Prometheus 系 7
注册/配置中心 纯 K8s→不需要(Service 即可);混合云→Nacos/Consul 22

3.3、反模式清单(每条都来自血的教训)

  1. 简历驱动开发:为了"用过 Service Mesh"给 5 个服务的系统上 Istio——复杂度成本 >> 治理收益(18 篇的决策树);
  2. 全家桶式上云原生:Day 1 就上 Operator/Service Mesh/GitOps 全套——先有云上业务,再有云原生架构,顺序反了全是债;
  3. 许可证忽视:AGPL 项目(MinIO/ToolJet)当商用底座直接闭源分发(9、15 篇的合规提醒);
  4. 只看功能不看运维面:Rancher 功能全但重、RocksDB 可调但旋钮上百——选型时你买的不是功能,是长期运维责任;
  5. 一次决策永久有效:技术选型是"带期权的决策"——每 12-18 个月用漏斗重跑一遍,环境变了(规模/团队/云厂商策略)答案就会变。

4、学习路径建议:按角色定制

4.1、应用工程师(写业务为主)

必读:5(K8s 心智模型)→ 24(本地实验)→ 23(容器基础)→ 17(安全习惯)
选读:19(k9s 效率)、22(配置中心使用姿势)

4.2、后端/基础设施工程师

必读:1→4(数据库内核,建立底层直觉)→ 2(LSM)→ 10(共识)
     → 5/11(K8s 原理与手工)→ 9/20(存储分野)
选读:14/18(流量治理)、6(方法论)

4.3、SRE / 平台工程

必读:7(可观测)→ 16/19(管理工具)→ 8/14(网关)→ 17(供应链)
     → 21(轻量集群)→ 12/13(知识管理)

4.4、架构师 / 技术管理者

必读:本文 + 各篇的"横向对比"与"选型"章节 + 15/16(平台工程思想)
方法:用第 3 节的漏斗框架带团队做 ADR(架构决策记录)

5、写在最后:技术地图的保质期

这个系列拆解的项目里:

  • 会长期存活的:Kubernetes 及其生态、etcd(共识引擎地位)、RocksDB(嵌入式 KV 基石);
  • 会被合并/演化的:Portainer/k9s 这类 UI 层(形态会变,需求不变)、网关三剑客(ambient/eBPF 重塑格局中);
  • 注定小众但思想不朽的:db_tutorial(教学)、SeaweedFS(Haystack 思想)、cheatsheets(知识压缩方法论)。

读开源项目的正确姿势不是记住结论,而是吸收决策模式:为什么这么裁剪、牺牲了什么换来了什么、适用边界在哪里。25 篇里反复出现的模式——声明式、关注点下沉、场景特化、声明与执行的分离——才是穿越技术周期的硬通货。

下一步建议:挑一个你生产环境正在用的项目,按本系列的框架(背景→架构→实践→对比→决策)写一篇自己的深度拆解。输出才是学习的完成态。

6、系列全目录

01 db_tutorial 上篇:从零写数据库      14 Kong:插件化 API 网关
02 RocksDB:LSM 存储引擎             15 ToolJet:低代码平台工程
03 countries 数据集:数据工程         16 Portainer:容器可视化管理
04 db_tutorial 下篇:扩展实战         17 Trivy:供应链安全
05 Kubernetes:声明式架构             18 Istio:服务网格
06 devops-exercises:学习方法         19 k9s:终端 K8s 驾驶舱
07 Netdata:实时可观测                20 SeaweedFS:海量小文件
08 Traefik:边缘路由                  21 K3s:轻量 K8s
09 MinIO:对象存储                    22 Nacos:注册与配置
10 etcd:Raft 共识                    23 Podman:无守护容器
11 K8s the hard way:手工搭建         24 minikube:本地实验场
12 GitHubDaily:信息策展              25 本文:全景综述
13 cheatsheets:知识压缩

7、参考资料

相关推荐

获取系统SDK版本、判断手机ROM
精选Code

获取系统SDK版本、判断手机ROM

Build获取系统SDK版本Android中部分API的使用,需要在特定的SDK版本之后才能使用,因此在兼容老版本SDK的时候,经常需要判断API的版本。各种Android版本的对应关系参考《Android各版本对应的SDK版本》判断手机ROM有时候需要判断手机系统的ROM,检测ROM是MIUI、EMUI还是Flyme,可以使用getprop命令,去系统build.prop文件(关于build.p

4.3k
AndroidStudio中各种中文乱码问题
精选Code

AndroidStudio中各种中文乱码问题

AndroidStudio中各种中文乱码问题1、编译Java错误信息乱码在出现这个Annotation processors must be explicitly declared now...问题的时候,正好也发现AndroidStudio Build Output错误信息都乱码。经常遇到各种问题,习惯了,现在遇到的问题,都是以后的答案。 1.1、修改项目build.gradle(无效)在整个p

2.8k
Function Calling 详解:让大模型调用你的函数
精选Code

Function Calling 详解:让大模型调用你的函数

问大模型“北京今天多少度”,它只能用训练数据里的旧知识猜,或者老实承认不知道。但如果告诉它“我这里有个查天气的接口”,它会说:“帮我调用 get_weather,城市参数填北京。”你的程序执行调用,把结果递回去,它再组织成一句自然的回答。Function Calling(函数调用)让模型从“只会聊天”进化为“会办事”——它是大模型连接外部世界的第一块基石,也是一切 Agent 系统的地基。本文按“…

105