什么是云原生¶

目录¶

一、为什么探讨"什么是云原生"
二、云原生的常见理解
三、云原生的历史演进
四、云原生的本质理解
五、云原生的商业因素
六、腾讯内部云原生实践
七、总结与建议

一、为什么探讨"什么是云原生"¶

1.1 问题的由来¶

从2018年开始频繁进行招聘面试,面试了数百位候选人后,发现一个惊人的现象:

每个人对云原生的理解都不一样
无论是毕业1-2年、3年还是10年的候选人
有人说云原生是Kubernetes、DevOps、微服务等技术组合
问为什么,能讲出这些技术的价值
但为什么这些技术组成就是云原生?每个人又说不清楚
缺乏统一认知
有人说云原生是某某提出的概念,但无证据证明
对云原生的理解与个人岗位、工作内容强相关
这种理解的差异会直接影响行为和实践

1.2 探究的意义¶

核心观点: 对云原生本身的理解会影响你的行为

理解会拓宽思维边界,加深思维深度
思维的边界和深度会影响我们的行为
最终让我们去践行对云原生的理解

这不是一个可有可无的概念探究,而是对实践有重要指导意义的认知升级

二、云原生的常见理解¶

2.1 面试中的7种常见说法¶

graph TD
    A[云原生的常见理解] --> B[概念组成角度]
    A --> C[应用架构角度]
    A --> D[运维能力角度]
    A --> E[生态角度]
    A --> F[目的角度]
    A --> G[商业角度]

    B --> B1[容器+微服务+DevOps等技术组合]
    C --> C1[一种开发方式/架构设计模式]
    D --> D1[帮用户管好云/用好云]
    E --> E1[生态云上/长在云上]
    F --> F1[提升效率/降低成本]
    G --> G1[Google发明的词语/云市场营销工具]

2.2 理解与岗位的关系¶

理解类型	典型岗位	行为导向
管好云/用好云	基础设施团队	优化云资源使用
商业概念	云产品团队	利用云原生概念营销
学习对象	培训/教育	教授云原生赚钱

启发: 每个人的理解似乎都是对的,但都只是从某一个角度出发

2.3 行业主流定义的矛盾¶

Pivotal的定义演进¶

2015年第一版:

十二因素应用(12-Factor App)
微服务
容器化
持续交付

Matt Stine加入Pivotal后:

DevOps + 持续交付 + 微服务 + 容器

问题: 为什么云原生就是这些?为什么是四大特征?为什么是抗脆弱?

CNCF基金会的定义演进¶

2015年第一版:

云原生 = 容器化 + 微服务 + 动态调度

第二版(巨大变化):

云原生技术有利于各组织在公有云、私有云、混合云等新型动态环境中,
构建和运行可弹性扩展的应用。
致力于厂商中立的开源生态。

疑问:

两版定义完全不同,为什么?
CNCF的定义为什么强调"多云"和"厂商中立"?
为什么站在基础设施角度理解云原生?

其他常见说法¶

说法1: "管好云,用好云,凡是能够提高云上资源利用率和交付效率的都是云原生"

问题: 云原生的字面意义是"原生在云上",但这里说的是"目的"

说法2: "一切为云而生的都是云原生,不上云就不是云原生"

问题: 谁来定义什么是"为云而生"?

2.4 常见解释的逻辑¶

典型的"价值驱动"解释逻辑:

graph TD
    A[互联网高速发展] --> B[业务挑战]
    B --> C[少量客户 -> 海量客户]
    B --> D[慢速开发 -> 快速迭代]
    B --> E[简单服务 -> 不间断服务]
    B --> F[流量稳定 -> 流量突增]

    C --> G[需要资源弹性]
    D --> H[需要快速交付]
    E --> I[需要高可用架构]
    F --> J[需要组织协作效率]

    G --> K[所以需要容器]
    H --> L[所以需要持续交付]
    I --> M[所以需要微服务]
    J --> N[所以需要DevOps]

    K --> O[这四个就是云原生]
    L --> O
    M --> O
    N --> O

    style O fill:#f9f,stroke:#333,stroke-width:4px

问题: 这些技术很有用 ≠ 这些技术就是云原生

只解释了"为什么需要这些技术"
没有解释"为什么这些技术组合就叫云原生"

三、云原生的历史演进¶

3.1 时间线总览¶

graph TD
    A[2009年] --> B[首次提出Native Cloud Application]
    B --> C[2010年] --> D[增加错误处理/反脆弱概念]
    D --> E[2011年] --> F[AWS大规模故障,提出面向失败设计]
    F --> G[2012年] --> H[Heroku提出12因素应用]
    H --> I[2013年] --> J[Netflix提出Cloud Native Company]
    J --> K[2015年] --> L[Matt Stine正式提出Cloud Native]
    L --> M[2015年] --> N[CNCF基金会成立]

3.2 2009年: Native Cloud Application的诞生¶

首次提出: 原生云应用(Native Cloud Application)

背景:

应用从IDC迁移到云上
探讨如何适应云的模式,如何使用云环境

核心观点:

传统应用上云后: 负载不均衡、云服务使用不好、容易被云厂商锁定
提出三个原则:
并行与弹性: 充分利用云的弹性特性
充分运用云服务: 而非简单的IaaS
跨云: 避免被单一云厂商锁定

定义: 云原生1.0 = 如何用好云

3.3 2010-2011年: 面向失败设计¶

2010年: 提出需要增加更多错误处理相关特征

这成为后来Pivotal提出的"反脆弱"(Anti-Fragile)的源头

2011年AWS大规模故障事件:

事件影响:

AWS某个可用区整体中断
引发行业对"云可靠性"的大讨论

核心认知转变:

graph LR
    A[云会故障] --> B[云会出错]
    B --> C[假设失败会发生]
    C --> D[面向失败设计]
    D --> E[关注点分离]
    D --> F[应用可抛弃]

    style D fill:#f96,stroke:#333,stroke-width:2px

重要概念:

面向失败设计(Design for Failure): 假设云一定会出故障
关注点分离: 云厂商、运维、开发各司其职
牲口模式(Cattle, not Pets): 应用应该像牲口一样可抛弃,而非宠物般精心呵护

定义: 云原生2.0 = 用好云 + 面向失败设计

3.4 2012年: Heroku的12因素应用¶

Heroku提出软件架构的7条原则(后扩展为12因素):

只要达成这些原则,企业就能在软件交付中高效运转:

代码库(Codebase)
依赖(Dependencies)
配置(Config)
后端服务(Backing Services)
构建、发布、运行(Build, Release, Run)
进程(Processes)
端口绑定(Port Binding)
并发(Concurrency)
易处理(Disposability)
开发环境与线上环境等价(Dev/Prod Parity)
日志(Logs)
管理进程(Admin Processes)

意义: 从技术实现上升到方法论层面

3.5 2013年: Netflix定义Cloud Native Company¶

里程碑事件: Netflix首次用"Cloud Native"形容整个公司

Netflix背景:

2008年开始上云
当时是AWS消费额最大的客户
完全运行在云上的公司
技术架构先进,研发效率极高

核心定义:

graph TD
    A[Cloud Native Company] --> B[设计目标]
    A --> C[设计原则]
    A --> D[最佳实践]

    B --> B1[弹性伸缩]
    B --> B2[可用性]
    B --> B3[开发敏捷]
    B --> B4[运维效率]

    C --> C1[不可变基础设施]
    C --> C2[关注点分离]
    C --> C3[反脆弱]
    C --> C4[高信任组织]
    C --> C5[信息共享]

    D --> D1[云上部署]
    D --> D2[微服务]
    D --> D3[混沌工程]
    D --> D4[开源]
    D --> D5[持续部署]

重要性:

没有说"这些技术就是云原生"
而是说"我们公司从一开始就在云上,所以是Cloud Native的Company"
我们的架构是"Cloud Native的Architecture"

3.6 2015年: Matt Stine正式命名¶

《迁移到云原生架构》一书作者: Matt Stine

背景:

需要一个名词既能形容微服务架构,又能表达可移植性
借鉴了Netflix等公司的云原生概念
对之前的概念进行重新整理

争议点:

很多人说他"首次提出云原生",实际上并不准确
他自己承认是借鉴和整理了之前的概念
但确实对云原生概念的推广起到重要作用

四、云原生的本质理解¶

4.1 概念演进的三个阶段¶

graph TD
    A[云原生概念演进] --> B[阶段1: 字面意义]
    A --> C[阶段2: 架构探索]
    A --> D[阶段3: 效能目标]

    B --> B1[应用运行在云上<br/>Born in the Cloud]

    C --> C1[什么样的应用特征<br/>能更好用好云?]
    C1 --> C2[弹性/容错/分布式]

    D --> D1[什么样的架构能<br/>最大化企业创新?]
    D1 --> D2[降本增效的终极目标]

    style D fill:#9f9,stroke:#333,stroke-width:3px

4.2 核心理解框架¶

云原生 ≠ 固定的技术栈组合

云原生 = 一系列理念和技术的持续演进

graph LR
    A[企业需求] --> B[技术理念]
    B --> C[最佳实践]
    C --> D[概念整合]
    D --> E[云原生]

    B --> B1[弹性伸缩]
    B --> B2[面向失败设计]
    B --> B3[不可变基础设施]
    B --> B4[关注点分离]

    C --> C1[容器化]
    C --> C2[微服务]
    C --> C3[DevOps]
    C --> C4[持续交付]

4.3 概念演进的双重驱动力¶

内因: 技术驱动¶

graph TD
    A[企业高速发展] --> B[实际需求]
    B --> C[技术创新]
    C --> D[理念升级]
    D --> E[云原生内涵丰富]

    B --> B1[海量用户]
    B --> B2[快速迭代]
    B --> B3[服务不间断]
    B --> B4[流量突增]

    C --> C1[容器技术]
    C --> C2[编排技术]
    C --> C3[服务网格]
    C --> C4[可观测性]

外因: 商业驱动¶

graph TD
    A[云厂商] --> B[商业目的]
    B --> C[概念整合]
    C --> D[品牌营销]
    D --> E[云原生推广]

    B --> B1[推广自己的产品]
    B --> B2[建立技术标准]
    B --> B3[培育市场生态]

    C --> C1[统一话术]
    C --> C2[降低认知成本]
    C --> C3[便于传播]

重要认知: 概念的重新包装和营销,本身也代表了一种技术和生产力的进步

4.4 理解云原生的正确方式¶

❌ 错误方式:

死记硬背"云原生 = 容器 + 微服务 + DevOps + 持续交付"
停留在名词层面

✅ 正确方式:

理解云原生下面的概念
理解云原生概念下面概念的概念
理解这些概念如何因需求演进
理解这些概念如何站在前人肩膀上

示例: 面向失败设计的演进

云经常故障 
  ↓
面向失败编程(Design for Failure)
  ↓
抽象为"反脆弱"(Anti-Fragile)
  ↓
实践方法"混沌工程"(Chaos Engineering)

4.5 云原生的终极定义¶

云原生 = 能够帮助企业最大化应用创新、提升效率、降低成本的一系列技术理念和最佳实践的集合

推论:

未来一切企业内部基础架构都将基于云原生架构
能够帮企业提升效率降低成本的新技术,自然会被云原生概念吸纳
一个企业能够优秀地提升效率降低成本,就可以称之为云原生企业

学习云原生的本质:

学习运维知识 = 学习云原生
学习研发效能 = 学习云原生  
学习架构知识 = 学习云原生
学习技术运营 = 学习云原生

五、云原生的商业因素¶

5.1 云原生与云厂商绑定的矛盾¶

有趣的现象: 云原生最初与"云绑定"相关

2009-2010年的观点:

"Native Cloud Application意味着更小的可移植性"

早期困境:

graph LR
    A[企业上A云] --> B[使用A云专有服务]
    B --> C[被A云锁定]
    C --> D[供应商C出现]
    D --> E[通过C产品支持A云和B云]
    E --> F[被C供应商锁定]

    style C fill:#f66
    style F fill:#f66

用户顾虑: 上云 = 云绑定

5.2 商业驱动的概念推广¶

案例1: 2009年首次提出者¶

文章内容:

提出Native Cloud Application概念
探讨什么样的应用能用好云

文章结尾:

"为了帮助你们开发Native Cloud Application,我们推出了Native Cloud应用开发平台"

真相: 推广自己的产品

案例2: 2010年Paul的Cloud Native¶

内容:

提出Cloud Native概念
批判传统PaaS被云厂商绑定

结论:

"你需要一个不绑定云厂商的PaaS,那就是我们公司的Cloud Native PaaS"

套路: 制造焦虑 → 提供解决方案(自己的产品)

案例3: 2015年Cloud Foundry基金会¶

背景: Cloud Foundry是最有影响力的PaaS平台之一

2015年成立基金会:

宣布自己是Cloud Native平台

为什么用Cloud Native标签?

原文关键观点:

行业厌倦了"敏捷"这个词(吹太多牛了)
企业想拥抱云,但反感PaaS(之前被伤过)
需要一个新名词,表达同样的意思,但让用户觉得很酷

套路: 换个包装,避开负面印象

5.3 CNCF与云原生¶

关键人物: CNCF TOC(技术监督委员会)成员的观点

观点:

"CNCF是Google击败AWS的利器。Google希望用户在各环境中运行Kubernetes,这样用户就能更好地迁移到Google云上。"

"为什么搞CNCF?因为Google希望让企业相信这是可信且中立的。"

注意: 这是网上公开观点,不代表本人或公司立场

5.4 云原生的立场性总结¶

graph TD
    A[云厂商] --> B[实际技术问题]
    A --> C[商业目的]

    B --> B1[如何提升效能]
    B --> B2[如何提升弹性]
    B --> B3[如何降低成本]

    C --> C1[推广自己产品]
    C --> C2[建立技术标准]
    C --> C3[培育生态体系]

    B1 --> D[基于各自立场]
    B2 --> D
    B3 --> D
    C1 --> D
    C2 --> D
    C3 --> D

    D --> E[对云原生进行解读]
    E --> F[都是各自的观点]

客观认识:

云厂商的解读立足于实际问题(提升效能、弹性、降本)
但总是基于自己的立场和商业目的
这并不意味着云原生没有价值
概念的包装本身也是一种创新

六、腾讯内部云原生实践¶

6.1 云原生技术采纳时间线¶

graph LR
    A[2012年] --> B[基于LXC构建PaaS平台]
    B --> C[2015年]
    C --> D[使用Docker,推出盖亚平台]
    D --> E[2016年]
    E --> F[K8s未成熟就大规模使用于游戏业务]
    F --> G[2017年]
    G --> H[国内首家推出基于K8s的公有云容器服务]
    H --> I[2019年]
    I --> J[内部所有自研业务全量运行在K8s之上]

6.2 为什么要技术统一?¶

腾讯的技术特点:

历史上技术统一性不强
2019年前各BG各自构建研发运维体系
各自构建资源管理体系

变革的驱动力:

graph TD
    A[产业发展深化] --> B[必须提升研发效率]
    A --> C[必须提升资源效率]

    B --> D[消除重复建设]
    C --> D

    D --> E[技术栈统一]
    E --> F[选择云原生和K8s]

6.3 为什么选择Kubernetes?¶

K8s的核心优势:

graph TD
    A[Kubernetes] --> B[类似操作系统内核]

    B --> C[标准化]
    B --> D[开源]
    B --> E[开放]
    B --> F[可扩展]

    C --> G[统一接口和规范]
    D --> G
    E --> G
    F --> G

    G --> H[任何企业都能定制]
    H --> I[达成自己的效果]

6.4 技术架构统一后的效果¶

架构图:

graph TD
    A[应用流水线] --> B[各BG定制PaaS平台]
    B --> C[腾讯云统一容器平台]
    C --> D[统一资源调度]

    B --> B1[业务1 PaaS]
    B --> B2[业务2 PaaS]
    B --> B3[业务N PaaS]

    D --> D1[资源池1]
    D --> D2[资源池2]
    D --> D3[资源池N]

6.5 量化收益¶

指标	数据	说明
集群规模	数千万核心	运行在容器平台上
资源利用率	10%+ → 40%+	IDC主机 → 容器平台
核心集群	60%	最高资源利用率
成本降低	⅓	资源利用率提升3倍

关键洞察:

仅从资源成本考虑,通过K8s和云原生技术,就能让资源利用率提升3倍,让服务器和资源成本降低为原来的三分之一。这是一个非常可怕的效果。

6.6 实践总结¶

技术层面:

K8s提供统一的容器编排能力
各BG在统一平台上定制自己的PaaS
统一调度大幅提升资源利用率

组织层面:

消除各BG重复建设
统一技术栈降低协作成本
研发效率显著提升

商业价值:

资源成本降低66%
研发效率提升
快速响应业务需求

七、总结与建议¶

7.1 核心理解¶

1. 云原生不是固定概念¶

graph LR
    A[云原生] -.-> B[容器]
    A -.-> C[微服务]
    A -.-> D[DevOps]
    A -.-> E[持续交付]

    A ==> F[持续演进的理念体系]
    F ==> G[最大化企业创新]
    F ==> H[提升效率]
    F ==> I[降低成本]

    style A fill:#9f9
    style F fill:#f96

2. 云原生的本质¶

云原生 = 从IDC到云,再到超越云的架构演进过程中,企业探索出的最大化降本增效的技术理念和最佳实践的集合

演进路径:

字面意义: 应用运行在云上
架构探索: 什么特征能用好云
效能目标: 什么架构能最大化降本增效

3. 理解的层次¶

graph TD
    A[表层: 背诵名词] --> B[中层: 理解技术]
    B --> C[深层: 理解演进]
    C --> D[本质: 理解规律]

    A --> A1[云原生=容器+微服务+...]
    B --> B1[每个技术的原理和价值]
    C --> C1[为什么会产生这些技术]
    D --> D1[指导未来实践]

    style D fill:#9f9,stroke:#333,stroke-width:3px

7.2 学习建议¶

针对不同岗位¶

资源运维:

学习如何用云原生技术提升资源利用率
学习容器调度、资源管理
落地标准化、自动化

应用运维:

学习应用如何弹性伸缩
学习微服务架构
学习可观测性实践
践行SRE理念

研发工程师:

学习服务治理
学习微服务开发
学习持续交付
学习可观测性

应届生:

学习技术: Kubernetes、Docker、Service Mesh等
学习理念: DevOps、反脆弱、不可变基础设施、敏捷、研发效能
在工作中践行这些技术和理念

转型路径¶

graph TD
    A[当前岗位] --> B[识别目标]
    B --> C[学习相关技术]
    B --> D[学习相关理念]
    C --> E[在当前工作中践行]
    D --> E
    E --> F[扩宽边界]
    F --> G[成为云原生工程师]

    C --> C1[容器/K8s/Service Mesh]
    D --> D1[DevOps/SRE/可观测性]

核心原则:

站在当前岗位拥抱新技术和理念
在工作中运用和打磨
持续扩宽知识边界
不局限于"云原生"三个字

7.3 思维方式建议¶

1. 不要被表面解释蒙蔽¶

graph LR
    A[看到一个概念] --> B[不只看定义]
    B --> C[探究演进过程]
    C --> D[理解本质规律]
    D --> E[指导实践]

2. 从历史中寻找答案¶

概念是如何产生的?
为什么会产生这样的概念?
概念如何演进的?
谁在推动概念演进?为什么?

3. 关注本质而非名词¶

错误: "云原生就是容器+微服务+DevOps+持续交付"

正确:

为什么需要容器?(资源弹性)
为什么需要微服务?(架构演进)
为什么需要DevOps?(协作效率)
为什么需要持续交付?(快速迭代)
这些技术如何组合发挥价值?

7.4 未来展望¶

1. 云原生必然是未来¶

判断依据:

云原生 = 最大化降本增效的技术集合
新的能提升效率的技术会被云原生吸纳
企业必然追求效率和成本优化
因此,未来一定是云原生的未来

2. 云原生是持续演进的¶

graph LR
    A[当前云原生] --> B[新技术出现]
    B --> C[新理念提出]
    C --> D[云原生概念扩展]
    D --> E[未来云原生]

    B --> B1[AI/ML]
    B --> B2[Serverless]
    B --> B3[边缘计算]
    B --> B4[WebAssembly]

3. 学习云原生 = 终身学习¶

学习云原生 ≠ 学会某几个技术
学习云原生 = 持续学习新技术、新理念、新实践
学习云原生 = 持续提升架构能力和工程能力
学习云原生 = 每个技术人员的必经之路

7.5 最后的话¶

"云原生这三个字本身没有那么重要。重要的是:

理解为什么人们会提出云原生

理解云原生下面概念的组成是怎么来的

理解这些概念本身之前又是怎么演进的

理解这个过程对我们未来技术发展的启发

我们不要被事物表面的解释去蒙蔽,要从演进中、本质中、规律中去探究它,然后通过这样的学习,最后指导我们未来的实践。"

Q&A精选¶

Q: 应用运维想转型云原生方向有什么路径?

A: 云原生没有固定答案,它由很多子概念组成。关键是:

如果做资源运维: 学习如何用云原生技术提升资源利用率
如果做应用运维: 学习弹性伸缩、微服务架构、可观测性
关键是在当前岗位践行新技术和理念(如SRE、容器化、不可变基础设施)
扩宽边界,自然就成为云原生工程师

Q: 应届生该从哪些方面学习云原生技术?

A:

技术层面: K8s、Docker、Service Mesh等
理念层面: DevOps、反脆弱、不可变基础设施、敏捷、研发效能
在工作中践行这些技术和理念
持续学习就是在学习云原生

Q: Java开发如何学习云原生?

A:

深入学习服务治理
学习微服务架构
学习可观测性
这些就是云原生在应用层的体现

Q: 学习云原生对跳槽大厂有帮助吗?

A: 有两类团队:

云原生技术服务平台团队(如云产品团队)
需要对K8s、Docker等技术理解非常深刻
需要维护和提供云服务
云原生技术应用团队(业务团队)
不需要过度纠结K8s/Docker底层
更关注微服务、DevOps、CI/CD的应用
关注敏捷实践的落地

根据目标团队类型调整学习重点。