CNCF Landscape

定义

CNCF Landscape是云原生计算基金会(CNCF)推出并维护的一个项目，目标是为此前缺少系统梳理的云原生技术领域绘制一张地图，把该领域多数项目与产品纳入分类体系^[1][4]。它的正式名称是Cloud Native Landscape，中文常称云原生技术全景图或云原生全景图^[2]。

它不是一个单独的软件产品，而是一份持续更新的生态清单，静态版本以图片和PDF形式发布，另有可按条件筛选的交互式网页版本^[2][1]。项目还配套提供云原生路线图(Trail Map)，面向刚开始云原生实践的企业，给出推荐的实施顺序。

原理

全景图把云原生生态按功能分成若干大类，项目按类别归入对应方格，形成一张层次化的分布图。历史上常见的划分包括应用定义与开发、编排与管理、运行时、供应保障、云设施等横向层次，以及可观测性与分析、平台等功能^[5]。

在交互版本中，所有条目的数据来源是一份YAML清单文件，即landscape.yml，它是全域数据的权威来源^[1]。系统每天从外部抓取数据来充实条目内容：项目信息取自GitHub，融资信息取自Crunchbase，市值数据取自雅虎财经，另有开源项目最佳实践徽章的数据^[6]。

数据的组织方式可以用下面的流程概括：

flowchart LR

A[landscape.yml 条目清单] --> B[每日抓取外部数据]

B --> C[生成 processed_landscape.yml]

C --> D[输出 JSON 静态文件]

D --> E[浏览器内筛选与排序]

网页端不做服务端计算，JSON以静态文件形式下发，筛选、排序和分组都在访问者的浏览器本地完成^[7]。

发展历程

全景图项目在2017年前后启动。当时基金会方面把它定位为帮助企业和开发者认识云原生技术的资源地图，此后借助协作编辑收到大量改进，项目仓库也积累了两千余个收藏。

2018年3月，云原生计算基金会发布交互版全景图，也就是所谓2.0版本，访问者可以自行筛选、查看某个项目或技术的详细信息，并通过带状态的链接分享视图，全部数据同时以仓库形式公开。同一时期，基金会还发布了云原生路线图，为企业的云原生改造提供阶段性的参考路径。

此后全景图改为在浏览器中实时动态生成，替代过去由设计人员每月手工绘制一张图的流程，并支持只显示基金会托管项目、某一基金会托管项目或只显示开源项目等视图^[8]。中国大陆的开源项目也陆续被收录，例如Apache ShardingSphere在2019年6月进入全景图的应用定义与开发中的数据库类别^[3]。

应用

全景图最常见的用途是选型参照。团队在搭建云原生技术栈时，可以先确定自己处在哪一层，再在对应类别中比较可选项目与商业产品^[9]。条目卡片会展示GitHub收藏数、融资或市值、首次与最近提交时间、贡献者数量和总部所在地等信息，便于横向比较^[1]。

由于收录范围覆盖开源项目与厂商产品，全景图也被用作观察行业格局的材料。红帽等厂商的技术文档把它称作云原生技术的资源地图，用于说明容器运行时、容器网络接口、容器存储接口等标准与实现之间的关系^[10]。学术研究中也出现过以全景图分类为参照来构建软件分类体系的例子^[11]。

局限

随着收录条目不断增多，全景图体量庞大，信息密度过高，想在其中快速找到符合自身需求的工具并不容易^[12]。该文写作时图中已有一千一百多个项目，累计GitHub收藏数超过三百六十万^[12]。

全景图只负责罗列与归类，并不给出选型建议，说明哪个项目更适合某类业务或某个技术栈，也不提供组合方案的推荐，使用者仍需自行判断^[12]。分类本身相对固定，项目方通常被要求放入现有类别中最合适的一格，项目方较难推动新增类别^[4]。

收录标准还带来一定偏差。项目一般需要具备至少300个GitHub收藏并明确符合现有类别，开源软件的商业版本通常不单独收录，认证的Kubernetes实现为例外^[1]。换言之，图中的分布并不等同于各类技术在真实生产环境中的使用比例。

参见

• 云原生计算基金会 —— 全景图的主管与维护机构，也决定项目的收录规则

• Kubernetes —— 全景图编排与管理类别中最具代表性的项目

• 云原生 —— 全景图所梳理的整个技术范畴

• 云原生路线图 —— 全景图同一项目产出的分阶段实施路径

• 容器 —— 全景图运行时类别所围绕的基础技术