SFKP • 计算机百科丨云原生才是「吞噬世界」的那条大鱼...

过去的一全年里，云原生（Cloud Native）无疑是云计算领域最热的热点。但一年过去了，到如今位置仍然不多有人能说清到底什么是云原生，网上的科普也都是写的云里雾里，看完仍然是似懂非懂...

这期的「SFKP • 计算机百科」，咱们就来尝试着理清云原生的概念、特性以及应用场景，帮助你得出心中「云原生」的定义。

云原生的概念

名词解析：云原生 Cloud Native

Cloud Native 翻译为云原生，是 Matt Stine 提出的一个概念，它是一个思想的集合，包括 DevOps、持续交付、微服务、敏捷基础设施、康威定律等，以及根据商业能力对公司进行重组。Cloud Native既包含技术也包含管理，能够说是一系列Cloud技术、企业管理方法的集合。（Via.百度百科）

「云原生」这个词其实也不是没爹没娘的孩子，最先由 Pivotal（一家位于美国加州的计算机软件公司）在 2013 年提出。2015 年，这家公司的 Matt Stine 在《迁移到云原生架构》一书中定义了符合云原生架构的几个特征：12 因素、微服务、自敏捷架构、基于 API 协做、扛脆弱性；

到了 2017 年，Matt Stine 在接受媒体采访的时候又将云原生架构概括为模块化、可观察、可部署、可测试、可替换、可处理这六项特质；

而 Pivotal 最新官网对云原生归纳为4个要点：DevOps+持续交付+微服务+容器。

2015 年，云原生计算基金会（CNCF）成立，他们最初把云原生定义为：容器化封装 + 自动化管理 + 面向微服务；

到了2018年，CNCF又更新了云原生的定义，把服务网格（Service Mesh）和声明式 API 给加了进来，变成了如今的版本：不可变基础设施、容器、服务网格、微服务、声明式 API。

可见，云原生的概念确实是在不断变化的，而且哪怕都是权威机构，对于云原生的概念和定义也是有所区别的。

但这些其实并不重要，因素在不断变化，根本缘由是实现云原生的方式在不断变化。上面提到的这些因素都是实现云原生的方式，但有了他们也未必就必定是云原生，没有他们不必定就不能实现云原生。

又可是，既然咱们在讨论什么是云原生，那就只能基于现阶段的发展状况来分析。综合各权威机构和组织的说法，微服务、容器、DevOps 和持续交付这四个因素是必不可少的，咱们今天就着重分析一下这四项：

1. 微服务

微服务 (Microservices) 是一种软件架构风格，它是以专一于单一责任与功能的小型功能区块 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关的 API 集相互通讯。

几乎每一个云原生的定义都包含微服务，微服务的核心方法是切割，从而解决咱们软件开发中一直追求的低耦合 + 高内聚的问题，也让将来的系统变动具备弹性。

2. 容器

容器化为微服务提供实施保障，起到应用隔离做用。优点是每一个服务都被无差异地封装在容器里，能够被无差异地管理和维护。如今比较流行的工具是 Docker 和 Kubernetes。

Docker 是一个开源项目，让应用程序部署在软件货柜下的工做能够自动化进行，借此在 Linux 操做系统上，提供一个额外的软件抽象层，以及操做系统层虚拟化的自动管理机制。Docker 也是目前应用最为普遍的容器引擎，在思科谷歌等公司的基础设施中大量使用。

而 Kubernetes 是由谷歌创建的，它是一个容许自动化部署、管理和伸缩容器的工具，而且提供了一些强大的功能，例如容器之间的负载均衡，重启失败的容器以及编排容器使用的存储。

容器为云原生应用程序增长了更多优点。使用容器能够将微服务及其所需的全部配置、依赖关系和环境变量移动到全新的服务器节点上，而无需从新配置环境，这样就实现了强大的可移植性。

3. DevOps

DevOps (Development 和 Operations 的组合词) 是一种重视软件开发人员和 IT 运维技术人员之间沟通合做的文化、运动或惯例。透过自动化「软件交付」和「架构变动」的流程，来使得构建、测试、发布软件可以更加地快捷、频繁和可靠。

DevOps 的出现是因为软件行业日益清晰地认识到，为了按时交付软件产品和服务，开发部门和运维部门必须紧密合做。

当企业或者项目有良好的沟通效率，才能够有更大的生产力。DevOps 的引入能对产品交付、测试、功能开发和维护（包括──曾经罕见但现在已家常便饭的──“热补丁”）起到意义深远的影响。

4. 持续交付

持续交付（英语：Continuous delivery，缩写为 CD），是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件能够稳定、持续的保持在随时能够释出的情况。它的目标在于让软件的建置、测试与释出变得更快以及更频繁。这种方式能够减小软件开发的成本与时间，减小风险。

持续交付的常见体现就是在不影响用户使用服务的前提下，频繁把新功能发布给用户使用。

要作到这点很是很是难，通常的要求是作到不误时开发、不停机更新，这就要求开发版本和稳定版本并存，须要不少流程和工具支撑。

有时候，持续交付也与持续部署混淆。持续部署意味着全部的变动都会被自动部署到生产环境中。持续交付意味着全部的变动均可以被部署到生产环境中，可是出于业务考虑，能够选择不部署。

若是要实施持续部署，必须先实施持续交付。

云原生和本地部署的区别

了解了云原生的概念，咱们再来看看云原生和本地部署的区别。

真正的云化不只仅是基础设施和平台的变化，应用也须要作出改变，在架构设计、开发方式、部署维护等各个阶段和方面都基于云的特色，从新设计，从而建设全新的云化的应用，即云原生应用。

这里，咱们引用阿里巴巴高级技术专家酱油（花名）发表的一篇文章中的分析：

1. 本地部署的传统应用每每采用 C/C++、企业级 Java 编写，而云原生应用则须要用以网络为中心的 Go、Node.js 等新兴语言编写。
2. 本地部署的传统应用可能须要停机更新，而云原生应用应该始终是最新的，须要支持频繁变动，持续交付，蓝绿部署。
3. 本地部署的传统应用没法动态扩展，每每须要冗余资源以抵抗流量高峰，而云原生应用利用云的弹性自动伸缩，经过共享降本增效。
4. 本地部署的传统应用对网络资源，好比 IP、端口等有依赖，甚至是硬编码，而云原生应用对网络和存储都没有这种限制。
5. 本地部署的传统应用一般人肉部署手工运维，而云原生应用这一切都是自动化的。
6. 本地部署的传统应用一般依赖系统环境，而云原生应用不会硬链接到任何系统环境，而是依赖抽象的基础架构，从而得到良好移植性。
7. 本地部署的传统应用有些是单体（巨石）应用，或者强依赖，而基于微服务架构的云原生应用，纵向划分服务，模块化更合理。

可见，要转向云原生应用须要以新的云原生方法开展工做，也就是咱们在概念中提到的：微服务、容器、DevOps 和持续交付等。

「吞噬世界」的云原生

这个图你们必定熟悉又陌生。

2011 年，马克·安德森说：“软件正在吞噬世界”；三年后 Jonathan Bryce 又补充说：“世界的一切源于开源”；再以后，业内广泛认同“云计算已改变了天空的颜色”；但如今云计算概念又被清晰细分，“云原生”才是那条最大的鱼。

既然云原生这么好，咱们要不要立刻切换到云原生架构？

我以为既然云原生的核心是应用，那么实际的应用就要更加的慎重。须要考虑企业的实际需求，目前的架构是否影响了业务发展？推倒重建的代价是否可以承受的住？

这些都是须要考虑的问题。

去年灵雀云进行过一次生态调研。在国内排名 TOP100 的 IT 方案商（ISV）中，约有 60~70% 在企业在接触云原生概念，但若是将调研范围扩大到TOP300，这一认知比例反而大幅度降低。说明规模越大的企业越须要云原生的能力来服务更多的客户、提供更优质的服务。

小规模企业虽然更加灵活，但一方面是需求不那么强烈，另外一方面云原生仍然在不断的迭代变化，这个变更对他们来讲夹杂着不少的风险。

但数字化运营已经成为企业发展的必然选择，而云原生技术与数据中台正是实现数字化运营所必须的创新技术与方法论。但大部分企业在数字化转型的过程当中，平白付出了努力与时间，但由于对云原生与数据中台技术方法论了解匮乏，加之没有好的平台与体系来深刻了解而走了很多弯路。

云原生是企业发展的一剂良药，可是药三分毒，仍是得慎重啊~

-END-

部分资料来源：

1.Picotal 官网：https://pivotal.io/cloud-native 阿里技术：《同志，云原生了解一下？》《2020 云原生 7 大趋势预测》
2.twt社区：《“云原生”究竟是什么？“云原生”的应用价值是什么？》
3.Virtusa 执行副总裁 Senthil Ravindran：《为什么云原生在吞噬世界 ？》
4.张戈bp：《“云原生”才是那条最大的鱼》