云原生是什么

1. 云原生是什么

云原生是面向"云"而设计的应用, 因此技术部分依赖于传统云计算的 3 层概念, 基础设施即服务 (IaaS)、平台即服务 (PaaS) 和软件即服务 (SaaS)。

例如, 敏捷的不可变基础设施交付类似于 IaaS, 用来提供计算网络存储等基础资源, 这些资源是可编程且不可变的, 直接通过 API 可以对外提供服务; 有些应用通过 PaaS 服务本来就能组合成不同的业务能力, 不一定需要从头开始建设; 还有一些软件只需要"云"的资源就能直接运行起来为云用户提供服务, 即 SaaS 能力, 用户直接面对的就是原生的应用。

原生就是土生土长的意思, 我们在开始设计应用的时候就考虑到应用将来是运行云环境里面的, 要充分利用云资源的优点, 比如️云服务的弹性和分布式优势。

1.1. 微服务

微服务解决的是我们软件开发中一直追求的低耦合+高内聚, 记得有一次我们系统的接口出了问题, 结果影响了用户的前台操作, 于是黎叔拍案而起, 灵魂发问: "为啥这两个会互相影响? ! "

微服务可以解决这个问题, 微服务的本质是把一块大饼分成若干块低耦合的小饼, 比如一块小饼专门负责接收外部的数据, 一块小饼专门负责响应前台的操作, 小饼可以进一步拆分, 比如负责接收外部数据的小饼可以继续分成多块负责接收不同类型数据的小饼, 这样每个小饼出问题了, 其它小饼还能正常对外提供服务。

1.2. DevOps

DevOps 的意思就是开发和运维不再是分开的两个团队, 而是你中有我, 我中有你的一个团队。我们现在开发和运维已经是一个团队了, 但是运维方面的知识和经验还需要持续提高。

1.3. 持续交付

持续交付的意思就是在不影响用户使用服务的前提下频繁把新功能发布给用户使用, 要做到这点非常非常难。我们现在两周一个版本, 每次上线之后都会给不同的用户造成不同程度的影响。

1.4. 容器化

容器化的好处在于运维的时候不需要再关心每个服务所使用的技术栈了, 每个服务都被无差别地封装在容器里, 可以被无差别地管理和维护, 现在比较流行的工具是 docker 和 k8s。

所以你也可以简单地把云原生理解为: 云原生 = 微服务 + DevOps + 持续交付 + 容器化

2. 什么是云原生

技术的变革, 一定是思想先行, 云原生是一种构建和运行应用程序的方法, 是一套技术体系和方法论。云原生 (CloudNative) 是一个组合词, Cloud+Native。Cloud 表示应用程序位于云中, 而不是传统的数据中心; Native 表示应用程序从设计之初即考虑到云的环境, 原生为云而设计, 在云上以最佳姿势运行, 充分利用和发挥云平台的弹性+分布式优势。

2.1. 云原生的诞生

提到云原生, 不能不提"Pivotal"和"Matt Stine", 都与云原生的起源有关。

Pivotal 公司的 Matt Stine 于 2013 年首次提出云原生 (CloudNative) 的概念;

2015 年, 云原生刚推广时, Matt Stine 在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征: 12 因素、微服务、自敏捷架构、基于 API 协作、扛脆弱性;

2017 年, Matt Stine 在接受 InfoQ 采访时又改了口风, 将云原生架构归纳为模块化、可观察、可部署、可测试、可替换、可处理 6 特质;

Pivotal 最新官网对云原生概括为 4 个要点: DevOps+持续交付+微服务+容器。

• 微服务

微服务解决的是我们软件开发中一直追求的低耦合+高内聚, 记得有一次我们系统的接口出了问题, 结果影响了用户的前台操作, 于是黎叔拍案而起, 灵魂发问: "为啥这两个会互相影响? ! "

微服务可以解决这个问题, 微服务的本质是把一块大饼分成若干块低耦合的小饼, 比如一块小饼专门负责接收外部的数据, 一块小饼专门负责响应前台的操作, 小饼可以进一步拆分, 比如负责接收外部数据的小饼可以继续分成多块负责接收不同类型数据的小饼, 这样每个小饼出问题了, 其它小饼还能正常对外提供服务。

• DevOps

DevOps 的意思就是开发和运维不再是分开的两个团队, 而是你中有我, 我中有你的一个团队。我们现在开发和运维已经是一个团队了, 但是运维方面的知识和经验还需要持续提高。

• 持续交付

持续交付的意思就是在不影响用户使用服务的前提下频繁把新功能发布给用户使用, 要做到这点非常非常难。我们现在两周一个版本, 每次上线之后都会给不同的用户造成不同程度的影响。

• 容器化

容器化的好处在于运维的时候不需要再关心每个服务所使用的技术栈了, 每个服务都被无差别地封装在容器里, 可以被无差别地管理和维护, 现在比较流行的工具是 docker 和 k8s。

2.2. 云原生基金会

云原生计算基金会 (Cloud Native ComputingFoundation, CNCF) 成立与 2015 年 12 月 11 日, 由谷歌与 Linux 基金会联合创办, 成立这个非盈利组织的初衷为推广孵化和标准化云原生相关的技术:

1. 推动云原生计算可持续发展;
2. 帮助云原生技术开发人员快速地构建出色的产品。

CNCF 成立最初只有十多家创始成员, 包含谷歌、IBM、Red Hat、VMware……经过几年的发展, 目前 CNCF 已经有超过 300 个会员, 涵盖国内外的知名 IT 厂商, 包括微软、亚马逊、苹果、阿里巴巴、华为等, 发展地十分迅速。

起初 CNCF 对云原生 (Cloud Native) 的定义包含以下三个方面:

1. 应用容器化
2. 面向微服务架构
3. 应用支持容器的编排调度

到了 2018 年, 随着近几年来云原生生态的不断壮大, 所有主流云计算供应商都加入了该基金会, 且从 Cloud Native Landscape 中可以看出云原生有意蚕食原先非云原生应用的部分。CNCF 基金会中的会员以及容纳的项目越来越多, 该定义已经限制了云原生生态的发展, CNCF 为云原生进行了重新定位。

云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中, 构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式 API。

这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段, 云原生技术使工程师能够轻松地对系统作出频繁和可预测的重大变更。

2.3. 主要区别: 云原生与传统企业应用

云原生应用	传统的企业应用
可预测。云原生应用符合旨在通过可预测行为最大限度提高弹性的框架或“合同”。云平台中使用的高度自动化的容器驱动的基础架构推动着软件编写方式的发展。第一次作为 12 因素应用记录的 12 个原则就是阐释此类“合同”的良好示例。	不可预测。传统应用的架构或开发方式使其无法实现在云原生平台上运行的所有优势。此类应用通常构建时间更长，大批量发布，只能逐渐扩展，并且会发生更多的单点故障。
操作系统抽象化。云原生应用架构要求开发人员使用平台作为一种方法，从底层基础架构依赖关系中抽象出来，从而实现应用的简单迁移和扩展。实现云原生应用架构最有效的抽象方法是提供一个形式化的平台。Tanzu 非常适用于在谷歌云端平台 、微软 Azure 或亚马逊云服务等基于云的基础架构上运行。	依赖操作系统。传统的应用架构允许开发人员在应用和底层操作系统、硬件、存储和支持服务之间建立紧密的依赖关系。这些依赖关系使应用在新基础架构间的迁移和扩展变得复杂且充满风险，与云模型相背而驰。
合适的容量。云原生应用平台可自动进行基础架构调配和配置，根据应用的日常需求在部署时动态分配和重新分配资源。基于云原生运行时的构建方式可优化应用生命周期管理，包括扩展以满足需求、资源利用率、可用资源编排，以及从故障中恢复，最大程度减少停机时间。	过多容量。传统 IT 会为应用设计专用的自定义基础架构解决方案，这延迟了应用的部署。由于基于最坏情况估算容量，解决方案通常容量过大，同时几乎没有能力继续扩展以满足需求。
协作。云原生可协助 DevOps，从而在开发和运营职能部门之间建立密切协作，将完成的应用代码快速顺畅地转入生产。	孤立。传统 IT 将完成的应用代码从开发人员“隔墙”交接到运营，然后由运营人员在生产中运行此代码。企业的内部问题之严重以至于无暇顾及客户，导致内部冲突产生，交付缓慢折中，员工士气低落。
持续交付。IT 团队可以在单个软件更新准备就绪后立即将其发布出去。快速发布软件的企业可获得更紧密的反馈循环，并能更有效地响应客户需求。持续交付最适用于其他相关方法，包括测试驱动型开发和持续集成。	瀑布式开发。IT 团队定期发布软件，通常间隔几周或几个月，事实上，当代码构建至发布版本时，该版本的许多组件已提前准备就绪，并且除了人工发布工具之外没有依赖关系。如果客户需要的功能被延迟发布，那企业将会错失赢得客户和增加收入的机会。
独立。微服务架构将应用分解成小型松散耦合的独立运行的服务。这些服务映射到更小的独立开发团队，可以频繁进行独立的更新、扩展和故障转移/重新启动操作，而不影响其他服务。	依赖。一体化架构将许多分散的服务捆绑在一个部署包中，使服务之间出现不必要的依赖关系，导致开发和部署过程丧失敏捷性。
自动化可扩展性。大规模基础架构自动化可消除因人为错误造成的停机。计算机自动化无需面对此类挑战，可以在任何规模的部署中始终如一地应用同一组规则。云原生还超越了基于以虚拟化为导向的传统编排而构建的专用自动化。全面的云原生架构包括适用于团队的自动化和编排，而不要求他们将自动化作为自定义方法来编写。换句话说，自动化可轻松构建和运行易于管理的应用。	手动扩展。手动基础架构包括人工运营人员，他们负责手动构建和管理服务器、网络及存储配置。由于复杂程度较高，运营人员无法快速地大规模正确诊断问题，并且很容易执行错误实施。手动构建的自动化方法可能会将人为错误的硬编码到基础架构中。
快速恢复。容器运行时和编排程序可在虚拟机上提供动态的高密度虚拟化覆盖，与托管微服务非常匹配。编排可动态管理容器在虚拟机群集间的放置，以便在发生故障时提供弹性扩展和恢复/重新启动功能。	恢复缓慢。基于虚拟机的基础架构对于基于微服务的应用来说是一个缓慢而低效的基础，因为单个虚拟机启动或关闭的速度很慢，甚至在向其部署应用代码之前就存在很大的开销。