如何将云计算与不同业务场景深度融合？如何让技术真正为企业服务？如何节省企业IT部署成本？在“云原生”到来之前，谁也不知道答案。什么是云原生？什么是云原生？对此众说纷纭，没有统一的定义。下面我们用CNCF大哥的定义来理解云原生。大哥？CNCF？CNCF，全称CloudNativeComputingFoundation，中文翻译为“云原生计算基金会”。CNCF成立于2015年12月11日，是Linux基金会下的一个基金会。CNCF致力于培育和维护供应商中立的开源生态系统，以推广云原生技术。CNCF是云原生领域最有影响力、最有影响力的组织。说起CNCF的故事，就不得不从Cgroups（控制组，controlgroups）说起，时间轴又回到了16年前。2004年Google开始使用容器技术，2006年发布了Cgroups，最初叫ProcessContainer（进程容器）。ProcessContainer的用途非常简单。它希望像虚拟化技术一样，为进程提供操作系统级的资源限制、优先级控制、资源审计能力和进程控制能力。带着这样的设计思路，ProcessContainer在2006年被谷歌工程师正式推出后，第二年就进入了Linux内核主干。因为在Linux内核中，容器（container）这个词有很多不同的含义，为了避免混淆，所以改名为ControlGroups，即Cgroups。2013年Docker项目正式发布，2014年K8s项目也正式发布。原因很容易理解，因为有了容器和Docker，就需要有一种方法来帮助大家方便、快捷、优雅地管理这些容器。这就是K8s项目的初衷。K8s是云原生的基石，后面会详细介绍。Google和Redhat发布K8s之后，这个项目的发展非常快。2015年，CNCFCloudNativeFoundation由谷歌、Redhat、微软等大型云计算厂商以及一些开源公司联合成立。CNCF成立时有22个创始成员，K8s成为第一个由CNCF托管的开源项目。之后CNCF发展迅速。截至2020年2月，官网数据显示，会员433家。那么CNCF是如何定义云原生的呢？翻译成中文：云原生技术使组织能够在公共云、私有云和混合云等新的动态环境中构建和运行可弹性扩展的应用程序。具有代表性的云原生技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术可以构建具有容错性、可管理性和可观察性的松散耦合系统。结合可靠的自动化，云原生技术使工程师可以轻松地对系统进行频繁且可预测的重大更改。云原生计算基金会（CNCF）致力于培育和维护供应商中立的开源生态系统，以推广云原生技术。我们通过将最前沿的模型大众化，使大众能够接触到这些创新。除了CNCF对云原生的定义，网上流传的另一个版本是Pivotal的MattStine在2013年首次提出云原生的概念；2015年云原生刚开始推广时，MattStine定义了符合云原生架构的几个特征：12个因素、微服务、自敏捷架构、基于API的协作、脆弱性。2017年，MattStine改变了语气，将云原生架构概括为6个特征：模块化、可观察、可部署、可测试、可替换、可处理；而Pivotal官网将云原生架构概括为四个要点：DevOps+持续交付+微服务+容器。云原生所需的能力和特性by：CNCF大使宋景超MattStine认为，云原生是思想的集合，包括DevOps、持续交付、微服务、敏捷基础设施，以及康威定律（ConwaysLaw）等。云原生包括技术（微服务、敏捷基础设施）和管理（DevOps、持续交付、康威定律、重组等）。云原生也可以说是一系列云技术和企业管理方式的集合。下面我们来跟进CNCF的官方定义。具有代表性的云原生技术包括容器、服务网格、微服务、不可变基础设施和声明式API。那么这些技术是什么？这些技术是如何联系起来的？云原生代表技术容器。一般来说，“容器”（LinuxContainer，LXC）就是“Linux容器”（当然微软也在做容器，只是不如linux成熟）。开源解决方案提供商RedHat官网给出的容器定义：ALinux?containerisaseriesofprocessesisolatedfromtheotherpartsofthesystem.运行这些过程所需的所有文件都由另一个映像提供，这意味着Linux容器是可移植的，并且从开发到测试再到生产是一致的。因此，容器可以比依赖复制传统测试环境的开发管道运行得更快。容器无处不在且易于使用，这使它们成为IT安全的重要组成部分。容器提供进程级别的隔离，可以将操作系统管理的资源划分为相互隔离的组，解决相互隔离组之间的资源使用冲突。比如应用程序（Application，APP）APP1只能在centos操作系统上运行，APP2只能在ubuntu操作系统上运行，在同一个操作系统上同时运行APP1和APP2会产生冲突，以及容器技术恰恰可以解决这一类问题。目前主流的容器技术有Docker、LXD、RKT。Docker说到容器，就不得不说Docker。2010年，几个大胡子青年在美国旧金山创办了一家名为“dotCloud”的公司。该公司主要提供基于PaaS的云计算技术服务。具体来说，与LXC相关的容器技术。LXC是Linux容器虚拟化技术（Linuxcontainer）。后来dotCloud对自己的容器技术进行了简化和标准化，并命名为——Docker。Docker项目发布的时候，无非就是LXC的一个用户。它创建和使用应用程序容器的逻辑与Warden等竞争对手没有根本区别。然而，我们现在也知道，真正让PaaS项目无所适从的，是Docker项目最强大的杀手锏：容器镜像。Docker项目直接将一个应用程序运行所需的完整环境，即整个操作系统的文件系统，通过容器镜像进行封装。这种思路也算是解决了长期以来困扰PaaS用户的一致性问题。做一个“一次发布，随处运行”的Docker镜像的意义，比做一个连开发测试环境都不能统一的Buildpack要好。太多了。Docker项目大大降低了容器技术的使用门槛。它是轻量级的、可移植的、虚拟化的和语言无关的。写好程序丢进镜像后，就可以部署到任何地方运行。开发、测试、生产环境完全统一。执行资源管理和虚拟化。Docker作为一个开源的应用容器引擎，是一个为开发者和系统管理员设计的用于构建、发布和运行分布式应用的平台。典型的Docker平台有Kubernetes、OpenshiftV3、Flynn、Deis等。Docker允许开发者将各种应用程序和依赖包打包到一个可移植的Docker容器中，以Docker容器作为资源切分和调度的基本单位，封装整个软件运行环境，然后发布到Linux机器上。Docker的设计原理如上图所示。按照Docker的设计，应用软件的交付过程就像海运，操作系统OS就像一艘货轮，而基于OS的每一个软件就像一个容器。用户可以通过标准化的方式自由组装运行环境，容器的内容可以由用户自定义，也可以由专业人士（开发人员或系统管理员）自定义，这样交付一个应用软件产品就相当于交付一个集合的标准化组件。一句话解释Docker？没有容器就没有全球化，Docker就是IT世界的容器。使用容器，你需要编排和管理容器的生命周期，你需要了解kubernetes。Kubernetes再来说说kubernetes，kubernetes曾经被誉为云原生的基石。K8s，全称Kubernetes。这个词来自希腊语，意思是舵手或航海家。K8s是它的缩写，将“ubernete”的8个字符替换为“8”字。K8s并不是一个全新的发明。是谷歌内部使用Borg改造而成的通用容器编排调度器。2014年6月开源，同年7月，微软、红帽、IBM、Docker等公司陆续加入K8s。2015年，谷歌将其捐赠给了Linux基金会下的云原生计算基金会（CNCF），K8s成为了CNCF的第一个项目。K8s的架构有点复杂，我们简单看一下。一个K8s系统通常被称为K8s集群（Cluster）。这个集群主要包括两部分：一个Master节点（主节点）和一组Node节点（计算节点）。列出一些特殊术语的解释。Master（主节点）：控制K8s节点的机器，也是创建作业任务的地方。节点：这些机器在K8s主节点的控制下执行分配的任务。Pod：作为一个整体部署到单个节点的一个或多个容器的集合。同一pod中的容器共享IP地址、进程间通信(IPC)、主机名和其他资源。Pod抽象了底层容器的网络和存储，使得容器在集群内的迁移更加容易。Replicationcontroller：控制一个pod在集群上运行的实例数。服务：将服务内容与特定的Pod分开。Kubernetes服务代理负责自动将服务请求分发到正确的Pod，无论Pod在集群中的哪个位置移动，甚至被替换。Kubelet：这个守护进程运行在每个worker节点上，负责获取容器列表，确保声明的容器已经启动并正常运行。kubectl：这是Kubernetes的命令行配置工具。了解了K8s的一些技术术语后，你对K8s就有了一个大概的了解。云可以为我们提供稳定易用的基础设施，但是业务上云却成了一个难题。K8s的出现，与其说是最初的容器编排解决方案，不如说是为了解决应用云化（即云原生应用）这个难题。CNCF托管的一系列项目致力于云原生应用全生命周期的管理，从部署平台、日志收集、ServiceMesh（服务网格）、服务发现、分布式跟踪、监控和安全，通过开源软件为我们提供一整套解决方案。Google通过对Kubernetes中的各种概念对象，如Pod、Deployment、Job、StatefulSet等进行抽象和简化，对云应用进行抽象和简化，形成一个通用的、可移植的云原生应用模型。Kubernetes作为云应用部署标准，直接针对业务应用，大大提高了云应用的可移植性，解决了云厂商锁定问题，让云应用在云之间无缝迁移，甚至可以用来管理混合云，成为企业IT云平台的新标准。微服务在介绍微服务的时候，首先要了解什么是微服务。顾名思义，必须从两个方面来理解微服务。什么是“微”，什么是“服务”。从狭义上讲，微服务是小而有名的。“2pizzateam”很好的解释了这个解释（2pizzateam最早是由亚马逊CEO贝佐斯提出的，意思是设计单一服务，所有参与者从设计、开发、测试、运维到allplus看起来像它只需要2个比萨饼）。所谓服务，必须与系统区分开来，服务于一个或一组相对较小、独立的功能单元，是用户能感知到的最小功能集合。传统的单体架构是以整个系统为单位部署的，而微服务是以各个独立组件（如用户服务、商品服务）为单位部署的。对于单个应用，如果发现某个业务的请求量非常大，无法独立扩展业务。只能复制整个单体应用，部署一个环境来实现集群。正是因为单体应用的缺陷，才有了微服务。微服务和单体应用的区别可以用MartinFowler的这张图来解释：图片左边是单体架构的集群，右边是微服务集群。这意味着什么？比如根据每个服务的吞吐量，支付服务需要部署20台机器，用户服务需要部署30台机器，商品服务只需要部署10台机器。这种灵活的部署只有微服务架构才有可能。近几年流行起来的Docker，为微服务架构提供了一个有效的容器。服务网格服务网格（ServiceMesh）是指用于处理服务间通信的基础设施层。最早由Buoyant（开发ServiceMesh项目Linkerd的公司）提出，并在内部使用。公司于2016年9月29日首次公开使用该术语。ServiceMesh一般用于微服务应用的可配置基础设施层（configurableinfrastructurelayer）。Istio（由谷歌、IBM、Lyft支持）是目前最广为人知的服务网格架构。Kubernetes（最初由Google设计并开源）是目前Istio唯一支持的容器组织框架。为什么ServiceMesh如此受欢迎？对于很多公司来说，Docker和Kubernetes等工具已经“解决了部署问题”，或者几乎解决了这个问题。但是他们还没有解决运行时问题，这就是服务网格的用武之地。部署问题的解决方案是什么？使用Docker和Kubernetes等功能可以显着减少部署的增量操作负担。使用这些工具，部署100个应用程序或服务的难度不再是部署单个应用程序的100倍。这是向前迈出的一大步，对于许多公司而言，它显着降低了采用微服务的成本。这不仅是因为Docker和Kubernetes提供了强大的抽象，还因为它们标准化了整个组织中打包和部署模式的过程。ServiceMesh的出现弥补了Kubernetes在微服务的连接、管理和监控方面的不足，为Kubernetes提供更好的应用和服务管理。因此，以ServiceMesh为代表的Istio一经推出，就被认为是可以与Kubernetes形成双剑合用效果的微服务管理利器，受到了业界的一致好评。不可变基础设施在传统的可变服务器基础设施中，服务器会不断更新和修改。使用此类基础架构的工程师和管理员可以通过SSH连接到他们的服务器，手动升级或降级软件包，逐个服务器调整配置文件，并将新代码直接部署到现有服务器。换句话说，这些服务器是可变的；它们可以在创建后更改。可变的基础设施往往会导致以下问题：一旦发生灾难，服务很难重建。继续过多的手动操作，缺乏文档，将使从标准初始化服务器重建等效服务变得困难。在服务运行过程中，服务器的不断修改，就像程序中变量变量值的变化引入的状态不一致的并发风险。这些对服务器的修改也会引入中间状态，导致不可预知的问题。不可变基础设施是另一种基础设施范例，其中服务器在部署后永远不会被修改。编程中的不可变变量（ImmutableVariable）在赋值完成后是不能改变的，只能创建新的来整体替换旧的。由于此属性，此变量可以在并发环境中安全使用。对于基础设施的不变性，最基本的意思是运行服务的服务器在部署后不会发生变化。不可变基础架构的好处包括基础架构中更高的一致性和可靠性，以及更简单、更可预测的部署过程。它可以减轻或完全防止可变基础架构中常见的问题，例如配置漂移和雪花服务器。然而，有效地使用它通常包括全面的部署自动化、云计算环境中的快速服务器配置，以及处理有状态或临时数据（如日志）的解决方案。声明式API声明式编程方式一直被工程师拿来与命令式编程方式进行比较。两者是完全不同的编程方式。我们最常接触到的其实是命令式编程，它需要我们描述为了达到某种效果或目标需要完成的指令。常见的编程语言Go、Ruby、C++其实都为开发者提供了命令式编程的方式。命令式和命令式是两种完全不同的编程风格：在命令式API中，我们可以直接发出命令让服务器执行，例如：“运行容器”、“停止容器”等；在声明式API中，我们声明了系统要执行的操作，系统会不断地朝着这个状态行驶。通俗地说，命令式编程就是第一人称，我做什么，我怎么做。操作系统最喜欢这种编程范式。操作系统几乎不需要“思考”，只要将代码一对一地翻译成指令即可。而声明式编程就像是“第二人称”，就是你做的。“产品经理”和“开发”之间是有关系的。“产品经理”只负责提出需求，并不关心“开发”是如何实现的。让我们总结一下上面提到的技术和工具。k8s是整个云原生的基石，云原生的整个生态都是建立在k8s之上的。容器（Container）是k8s的底层引擎；Docker是使用最广泛的容器工具；微服务是docker的好搭档；服务网格是微服务的辅助，是基于k8s构建的请求的扩展功能；不变的基础设施是现代运维的基石；声明式API是k8s的编码方式；云原生应用价值限于篇幅，简单列举三种云原生应用价值。1）快速迭代使用云原生应用程序开发意味着使用敏捷和可扩展的组件，例如以Kubernetes为代表的容器提供离散和可重用的功能，这些功能以描述良好的方式集成，甚至跨越多个云等技术边界，这允许交付团队使用重复的自动化和编排快速迭代。2）云原生方法的自动化部署远优于传统的面向虚拟化的业务流程，后者需要花费大量精力构建开发环境，以及软件交付过程中的其他不同环境。云原生架构具有自动化和组合能力，依赖于可靠的、经过验证和审计的已知良好流程的基础，交付非常敏捷，无需人工干预和重复执行。3）独立高效的云原生带来微服务架构。微服务基本上是一个可以独立发布的应用服务。因此，它可以作为一个独立的组件进行升级、灰度化或复用，对整个大型应用的影响很小，每项服务都可以由专门的机构独立完成，依赖方只要设置好输入输出端口就可以充分开发，甚至整个团队的组织架构也会更加精简，所以沟通成本是低，效率高。谈云原生就是谈云计算。不跟云计算比，就是耍流氓。第一波云计算浪潮是关于成本节约和业务敏捷性，尤其是在基础设施更便宜的情况下。许多企业倾向于使用微服务架构来开发应用程序。微服务开发速度快，职责单一，可以更快地被客户采用。同时，这些应用可以通过快速迭代演进，赢得客户的认可。云原生可以打通微服务开发、测试、部署、发布的全流程。为了迎合市场，云提供商提供了满足各种场景的API，例如用于定位的GoogleMaps和用于社交协作的身份验证平台。将所有这些API与企业业务的特性和功能混合在一起，使他们能够为客户构建独特的场景。所有这些集成都发生在API级别。这意味着移动应用程序和传统桌面应用程序都可以无缝集成。因此，使用云原生开发的应用程序具有很高的可扩展性。软件不能失败。传统的企业级开发方式需要专职人员监控和维护企业应用。在云原生架构下，底层服务或API都会部署到云端，相当于把繁重的运维工作转移给了云平台提供商。这意味着客户应用将得到更专业的呵护，同时节省运维成本。结语9年前，网景创始人马克·安德森说：“软件正在吞噬世界”；6年前，OpenStack基金会创始人JonathanBryce补充说：“世界上的一切都来自开源”；我同意“云计算改变了天空的颜色”；但近两年，云计算的概念被明显细分，“云原生”是最大的鱼。“大鱼”来了。我们能做的，不是墨守成规，而是拥抱“大鱼”。时代呼唤云原生，但云原生不是一蹴而就的，而是一个循序渐进的过程。拒绝云原生，理解云原生，拥抱云原生，追随云原生。
