云原生技术系列-应用部署运行模式变迁

前沿

云原生（Cloud Native）技术是当下非常热门的云计算技术，它在本质上属于应用部署运行模式在新时代发展下的最新形态，因此当我们试图了解这一最新形态之前，了解这一形态的历史发展变迁对于我们从整体上把握云计算的发展以及演变规律会带来一定的受益，甚至我们能够想象出下一个形态的特征甚至是雏形。

正文

应用部署运行模式整体上走过了如下的几个阶段：

• 物理机
• 虚拟化（容器化）
• 云原生

下文我们将分别对各个阶段逐一展开介绍。

物理机阶段

image.png

这种方式的缺陷很快就暴露出来了，买来的一台机器值部署和运行一种应用，机器的采购成本高而机器的资源使用率却不高。并且，随着公司发展规模变大，硬件的采购流程较长，针对业务需求变化的响应周期非常长。并且需要招聘专员维护，成本很高。

提了提高机器资源的利用率，可能有人想到了在一台机器上部署多个应用。那么，在同一个物理机下混部应用带来的问题呢？
【应用端口冲突】如果一个应用占用了 80 端口，那么所有其他的应用就都不能使用 80 端口了，在同一台物理机上面每一个端口都是唯一的，不能被重复使用
【应用依赖版本冲突】比如 Python、Nodejs、Perl、PHP 等等这些脚本语言都需要提前安装好脚本解析器才能运行。而在同一台物理机上面如果对而写软件维护多个版本是一件非常困难的事情，一旦出错就可能导致所有应用崩溃。
【资源隔离性差】不同应用使用的出资源不能不能有效的进行隔离，就容易相互影响。如果一个应用有 BUG 占光了内存会导致其他应用出问题。
【运维操作相互影响】一个应用的管理员误操作可能会导致本机器上面的所有应用崩溃

最后总结一下，在这一阶段，购买机器的公司本质上只是希望部署应用，却需要连带机器的采购、部署和运维成本都要进行投入。类似于商家需要用电，却需要自己购买发电机，购买燃料，专人维护，成本高、效率低，他们迫切地希望能够像使用水和电一样去使用计算、存储、网络资源，这个是时代的呼唤。

虚拟化阶段

时代在发展，时间慢慢来到了2001年，VMware公司在2001年发布了真丢服务器市场的虚拟化技术解决方案，这是一个划时代的突破，尝到甜头之后，不少公司也表示眼红，Xen公司在2003年，KVM公司在2007年相继发布了自己的虚拟化技术，最终形成了三足鼎立的格局。也进一步推进的虚拟机概念的普及，也拉开了云计算时代的序幕。

那么这里有必要说说什么是虚拟化技术。虚拟化技术简单的说就是通过拆分的方式，将计算资源充足的物理机划分为若干个虚拟机，以虚拟化的方式提供给用户去使用，每个虚拟机都独享各自的操作系统，相互隔离。

image.png

真正让虚拟化技术发扬光大的还要数亚马逊的AWS以及Google的GCE，他们将虚拟机技术服务化，提出了云计算的概念，并且开始布局IaaS市场，让企业能够实现按需自助购买和租用以VM为单位的计算资源，很多用户纷纷拥抱云计算，选择了AWS来按需采购自己所需的计算资源，不仅国外的企业，连中国的互联网公司想要打开国外市场，与其在人生地不熟的地方自建机房，不如选择上云AWS。

image.png

上面提到的都是商业化的闭源产品，真正让以VM为计算单元的云计算发扬光大的还是开源方案OpenStack，它的出现极大地推动了开源IaaS平台的快速发展，推动企业将自有的机房和数据中心改造为虚拟化平台，部署数据敏感、业务敏感的核心应用，国内不少有技术团队的企业都借助OpenStack这股东风实现了云计算转型，并且针对特定场景做一些方案优化，优先满足公司内部应用对于云计算资源的使用需求，能力有富余的也会尝试为其他公司提供公有云服务或者私有化部署的服务。

image.png

image.png

越来越多的应用迁移到了云端，应用上云成为一股不可逆转的趋势，但在这一过程中人们也发现了传统虚拟机的一些不足之处：

• 云服务商锁定：由于使用了某个云服务商提供的服务， 用户便难以将服务迁移到其他云服务提供商，跨云做应用的部署十分困难。
• 虚拟机额外消耗过重： 镜像过大，传输不便。
• 虚拟机启动速度慢：导致扩展没有预想中那么轻量和方便 。

时代在召唤一个更加轻量级的虚拟化解决方案。

容器化阶段

Docker 是一个开源的应用容器引擎，让开发者可以打包他们的应用以及依赖包到一个可移植的镜像中，然后发布到任何流行的 Linux]或Windows 机器上，也可以实现虚拟化。容器是完全使用沙箱机制，相互之间不会有任何接口。以Docker 为代表的容器技术的出现，让应用上云，在虚拟机技术之外，又多了一种选择。

image.png

云原生阶段

随着时代的发展变化，应用所面临的外部环境也在变化。 市场需求的迅速变化要求应用得有足够快的响应速度， 快速更新并部署上线， 并且保持线上业务的平滑升级过渡，同时还能在业务的峰谷之间自行伸缩适应， 这些状态让开发者不仅选择容器作为应用部署、运行的载体，还积极地采取了与容器这个应用载体天生匹配的微服务的架构，并且依靠容器调度编排引擎的帮助，以保持对外部响应的敏捷性。这种容器化的、 微服务结构的、需要结合容器管理编排引擎进行动态编排和资源占用优化的应用被赋予了一个新的名词，云原生应用。云原生逐渐成为一种应用云化开发、部署和运行的主流方式。

image.png

CNCF组织成立的核心在于精心选择应用上云的解决方案和相关组件：

• 容器调度管理编排引擎Kunerbetes
• 分布式应用网络存储监控系统prothemetus
• 微服务间的交互协议Severless
• 微服务间的服务治理，服务网络Serverlee Mesh

image.png

总结

从2000年开始，应用部署运行模式至今已经走过了三个主要的阶段，它们分别是应用直接构建和部署在物理机实体上的物理机阶段，应用运行在云操作系统为底座的虚拟机上的虚拟化阶段，应用部署在以docker为代表的容器内，由k8s作为底层的容器调度编排系统的云原生阶段。从中，我们可以看到，云计算技术的发展，让我们更加专注于应用本身的开发，将通用的底层能力逐步下沉，之前是一些操作系统级别的特性，现在连一些通用业务能力也在逐步下沉，我们普通的开发者距离像水、像电一样去使用云计算资源的梦想又近了一步，最新的一代技术之所以命名为云原生（Cloud Native），是因为相关一揽子技术更加贴近云计算的理念，是真正为云计算而诞生的技术。

image.png

后面的文章，我会介绍云原生相关的一揽子技术，有道是打蛇打七寸，那么多技术怎么学呢？有没有什么核心是可以把握的呢？我想从上面的分析中已经可以得出一二了：一个是新一代的应用运行沙箱环境技术Docker，一个是编排调度Docker的容器化操作系统K8S。