过去的一整年里，云原生(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)，是一种软件工程手法，让软件产品的产出过程在一个短周期内完成，以保证软件可以稳定、持续的保持在随时可以释出的状况。它的目标在于让软件的建置、测试与释出变得更快以及更频繁。这种方式可以减少软件开发的成本与时间，减少风险。
持续交付的常见体现就是在不影响用户使用服务的前提下，频繁把新功能发布给用户使用。
要做到这点非常非常难，一般的要求是做到不误时开发、不停机更新，这就要求开发版本和稳定版本并存，需要很多流程和工具支撑。
有时候，持续交付也与持续部署混淆。持续部署意味着所有的变更都会被自动部署到生产环境中。持续交付意味着所有的变更都可以被部署到生产环境中，但是出于业务考虑，可以选择不部署。
如果要实施持续部署，必须先实施持续交付。
云原生和本地部署的区别
了解了云原生的概念，我们再来看看云原生和本地部署的区别。
真正的云化不仅仅是基础设施和平台的变化，应用也需要做出改变，在架构设计、开发方式、部署维护等各个阶段和方面都基于云的特点，重新设计，从而建设全新的云化的应用，即云原生应用。
这里，我们引用阿里巴巴高级技术专家酱油(花名)发表的一篇文章中的分析：
- 本地部署的传统应用往往采用 C/C++、企业级 Java 编写，而云原生应用则需要用以网络为中心的 Go、Node.js 等新兴语言编写。
- 本地部署的传统应用可能需要停机更新，而云原生应用应该始终是最新的，需要支持频繁变更，持续交付，蓝绿部署。
- 本地部署的传统应用无法动态扩展，往往需要冗余资源以抵抗流量高峰，而云原生应用利用云的弹性自动伸缩，通过共享降本增效。
- 本地部署的传统应用对网络资源，比如 IP、端口等有依赖，甚至是硬编码，而云原生应用对网络和存储都没有这种限制。
- 本地部署的传统应用通常人肉部署手工运维，而云原生应用这一切都是自动化的。
- 本地部署的传统应用通常依赖系统环境，而云原生应用不会硬连接到任何系统环境，而是依赖抽象的基础架构，从而获得良好移植性。
- 本地部署的传统应用有些是单体(巨石)应用，或者强依赖，而基于微服务架构的云原生应用，纵向划分服务，模块化更合理。
可见，要转向云原生应用需要以新的云原生方法开展工作，也就是我们在概念中提到的：微服务、容器、DevOps 和持续交付等。
「吞噬世界」的云原生
这个图大家一定熟悉又陌生。
2011 年，马克·安德森说：“软件正在吞噬世界”;三年后 Jonathan Bryce 又补充说：“世界的一切源于开源”;再之后，业内普遍认同“云计算已改变了天空的颜色”;但现在云计算概念又被清晰细分，“云原生”才是那条最大的鱼。
既然云原生这么好，我们要不要马上切换到云原生架构?
我觉得既然云原生的核心是应用，那么实际的应用就要更加的慎重。需要考虑企业的实际需求，目前的架构是否影响了业务发展?推倒重建的代价是否能够承受的住?
这些都是需要考虑的问题。
去年灵雀云进行过一次生态调研。在国内排名 TOP100 的 IT 方案商(ISV)中，约有 60~70% 在企业在接触云原生概念，但如果将调研范围扩大到TOP300，这一认知比例反而大幅度下降。说明规模越大的企业越需要云原生的能力来服务更多的客户、提供更优质的服务。
小规模企业虽然更加灵活，但一方面是需求不那么强烈，另一方面云原生仍然在不断的迭代变化，这个变动对他们来说夹杂着很多的风险。
但数字化运营已经成为企业发展的必然选择，而云原生技术与数据中台正是实现数字化运营所必须的创新技术与方法论。但大部分企业在数字化转型的过程中，平白付出了努力与时间，但因为对云原生与数据中台技术方法论了解匮乏，加之没有好的平台与体系来深入了解而走了不少弯路。
云原生是企业发展的一剂良药，但是药三分毒，还是得慎重啊~
