过去的一整年里，云原生(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，这一认知比例反而大幅度降落。阐明规模越大的企业越需要云原生的能力来服务更多的客户、供给更优质的服务。
小规模企业虽然更加机动，但一方面是需求不那么强烈，另一方面云原生仍然在不断的迭代变更，这个变动对他们来说夹杂着很多的风险。
但数字化运营已经成为企业发展的必定选择，而云原生技巧与数据中台正是实现数字化运营所一定要的创新技巧与方法论。但大部分企业在数字化转型的过程中，平白付出了努力与时间，但因为对云原生与数据中台技巧方法论懂得匮乏，加之没有好的平台与系统来深入懂得而走了不少弯路。
云原生是企业发展的一剂良药，但是药三分毒，还是得郑重啊~
以上就是小编收拾云原生才是吞噬世界的那条大鱼的相干内容，盼望可以对大家有所赞助！想要懂得更多关于这方面的内容，敬请关注桂哥网络！
?
