云原生的起源：探索云原生的诞生背景和原因

本文主要包括以下内容：

1、云原生的最早萌芽

2、云原生诞生的背景

3、云原生的技术框架

4、云原生的文化框架

5、云原生的本质

一

云原生最早的萌芽

如果想弄清楚云原生，必须了解云原生诞生的过程，以及为什么云原生概念被提出。

云原生能被检索到的最早文章是2010年Paul Fremantle（保罗 佛里曼特尔）的一篇博客，在这篇博客里他主要提出“要使系统在云上正常运行，必须以云编写系统”

这是行业思想领袖在云计算的触动下，开始洞察基于云计算的应用应该是什么样子，或是云计算本身应该是什么样子。

Paul Fremantle在博客里描述云原生的样子，比如分布式的、松散的、自服务的、持续部署与测试的。这也是云原生思想的最初描述，如何编写一种和云一样的系统应用，即云原生是为了能构建一种符合云计算特性的标准来指导云应用或云的编写部署和运行。

二

云原生诞生的背景

2013年Pivotal公司的Matt Stine(马特斯汀)正式提出CloudNative概念，并在推特上持续推广云原生理念。

2015年4月正式出版发行《迁移到云原生应用架构》一书

这本书很薄，也被Jimmy Song翻译为中文，共计50页，在这本书里，Matt Stine详细描述了云原生崛起的原因，而这些原因也正是云原生诞生的理由。

这里对Matt Stine做个简单介绍：

Matt Stine 20年的IT经验，2019年前在pivotal公司做全球架构首席技术管，2019年后任摩根大通首席技术办公室软件工程执行董事。他专注于精益/敏捷软件开发方法论，比如DevOps、体系结构原理、模式和实践、编程规范，以期寻找完美的技术帮助企业开发满意的软件。

在Matt Stine这本的第一章中Matt Stine 敏锐的发现Square、Uber、Netflix、Airbnb和特斯拉这样的公司快速崛起成为颠覆者，他们都有一个共同的特征：

快速创新、持续可用的服务、弹性可扩展的Web、以移动为核心的用户体验。

支持这些特征的IT技术便是云原生应用架构，通过云，任何能够按需、自主弹性提供和释放计算、网络和存储资源的计算环境。

这也是那些初创公司能够如此具有破坏性的核心原因之一。

由此可见并不是Matt Stine发明了云原生，而是云原生本身就已经出现并应用，只是他敏锐地觉察并通过归纳这些初创公司的快速崛起的IT因素，得出云原生的一组技术体系。

云原生技术体系的特点是：迅速、安全、弹性扩展以及移动应用和客户多样性，这也是云原生技术从解决实际问题归纳的特点。

迅速：传统企业，准备环境和部署新版本通常以天、周、月来计算。所以他们的试错成本高，无法向互联网公司每天成百上千次的发布来纠错试错。而云基础设施的弹性和自服务的特性天生就适应这种工作方式，CI/CD更是让云如虎添翼

安全：云原生架构应该能够在快速变动的需求、稳定性、可用性和耐久性之间寻求平衡。传统企业在软件开发过程中，花费大量的时间和精力在预防错误，尽可能详细的文档、漫长的回归测试，尽管如此依旧不能够杜绝缺陷的产生。

云原生可以提供运行监控，系统健康报告，业务自动测量数据等，各类可视化框架及工具，实现检测与标准情况的偏差。

功能丰富的指标、监控、警报、数据可视化框架和工具是所有云原生应用程序体系结构的核心。

同时云原生架构应该是微服务化的，微服务化可以做到很好的故障隔离，不会出现单体架构故障灾难

通过软件断路器可以防止出现错误的组件将错误传递给他所依赖的组件而造成级联故障。同时云原生架构还必须具有优雅的回退行为，比如回路断开的时候提供一组默认的产品推荐等。

云原生架构还要具有自动恢复能力

弹性扩展：

云原生基础设施不是垂直扩展来处理更多的需求或提升性能，而是使用大量便宜服务器水平扩展应用实例，同时云原生架构能够支持水平扩展的快速部署。另外可以通过将大型服务器虚拟化成几个较小的服务器来改善大型服务器的资源利用率。

同时云供应商由虚拟化向容器化发生转变，也是对资源利用率提升及应用部署更便捷，最大限度地提升对需求变化的响应速度。

移动应用和客户多样性：

2014年1月，美国移动设备占互联网使用量的55%，移动APP开发发爆发，原本传统的IT应用面临巨大的挑战，比如从前客户去银行、ATM机取钱，办理业务，银行系统压力固定、可预测，也可以控制。按时移动终端时代的来临，每个人手里都有一个终端，随时可以连接银行系统，这就导致原有银行系统固定的服务器，固定的性能，固定的流量完全无法控制，原有系统架构无法满足这种需求，而云原生就可以，天然适应。

另外移动终端系统差异巨大，不同厂商不同OS，这对移动应用程序开发带来了种种限制和场景，增加了开发人员的负担，而云原生可以通过如API网管之类的设计模式来支持移动优先开发的概念，API网关将服务聚合负担转移回服务器端。

三

云原生的技术框架

玛特斯汀通过对云原生应该具有的优点描述，结合对云的理解，给出了云原生架构的定义。但事实上这里的定义和我们传统说的概念及定义有些差距，在玛特斯汀的《迁移到云原生应用架构》书中并没有明确的描述云原生定义，而是通过一组技术和一种文化共同构成原生。

云原生的一组技术：

12要素：

一系列云原生应用架构的模式集合，相比不合符这些特征的传统应用开发，具有这些特征的应用更适合云化，请注意12要素提出早于云原生。

微服务：

与单体应用想对应，细分领域还有serverless、FaaS等

自服务敏捷架构：通过该平台实现部署和运营，同时IaaS能够通过API创建虚拟服务器实例、网络、存储等，确保团队根据敏捷原则开发和运行服务，从而实现速度、安全和规划化

基于API的协作：

在云原生应用程序架构中，服务之间的唯一互动模式是通过已发福的版本化的API，这些API通常具有JSON序列化的HTTP REST风格，在不破坏现有api协议前提下可以部署新的功能，而不用与其他团队进行同步，也可以通过API实现与基础设施平台的交互等等

抗脆弱性：

抗脆弱性并不是技术上的脆弱性相反，比如弹性、健壮等，而是像人体免疫系统一样，在收到压力时变得更强的质量系统。抗脆弱性就是随着速度和规模扩大，系统的压力随之增加，系统的响应能力和安全性也随之提高。

这个概念在2015年被广泛接受，虽然很粗糙但是被业界认为云原生的特点如强调十二要素、微服务、API协作等都体现了云原生的显著特点

五

云原生的文化框架

云原生的一种文化：

企业IT采用云原生架构所需要变革不是技术性的，而是企业文化和组织的变革，围绕消除造成浪费的结构、流程和活动。他包括DevOps、持续集成、持续交付等

DevOps：

技能集中化转变为跨职能团队，通过自动化流程来使得软件开发、构建、测试、发布更加迅速和可靠。这些特征正是云原生所需要的。而云原生基于容器和微服务架构，让开发更聚焦业务的思想反过来又促进了DevOps的流行。

持续交付：发行时间表和流程的权利下方

自治：决策权力下放。业务能力团队可以自主决定设计、流程和发布时间表的跨职能团队；平台运营团队，为跨职能团队提供他们所需要运行平台。

在技术文化上也是分散自治的，比如微服务、容器化等

五

云原生的本质

在云原生诞生的云背景及初期，云原生并不是一种确切的技术，只是根据云的特点，提出基于云的应用应该具备什么样的技术理念，而这些技术理念比较粗糙，无法确切指导实践。

总之在云原生诞生初期，云原生而是为了适应云而兴起的以云为基础的云应用开发或云开发思想。他是一组适应云应用及云开发的技术集合和组织文化集合。

参考文献：

1、《前移到云原生架构》Matt Stine

2、《云原生架构进阶实践》王玉平

3、《云原生模式》科尼利亚 戴维斯

4、阿里云开发者社区文章

5、腾讯云原生

6、知乎云原生话题

声明：

文章内容和知识均来自已出版发行书本及网上公开授权信息，不涉及任何公司私有知识产权和信息安全，请勿对号入座。