服务工件的类型

许多语言都有自己的打包机制，这种差异导致在处理由不同语言编写的服务时部署工作的复杂度增大。部署工具需要分别采用不同的方式来处理每种部署包提供的接口，这些包在服务器上运行或者结束服务。

好的工具能够弱化这种差异，但特定于技术的工件往往都工作在很低的抽象层次上。它们主要关注的是代码打包，而非应用程序层面更广泛的本质需求：1) 缺少运行时环境(开发者需要单独安装其他依赖项来运行服务)；2) 不能提供任何形式的资源管理或者资源隔离，这导致在一台主机上运行多个服务非常困难。

可以从3个角度来着手，操作系统软件包、服务器镜像或者容器，这3种不同服务工件类型的结构，如图所示。

1．操作系统软件包

可以使用目标操作系统的包格式，如Linux上的apt或者yum。这种方式可以将工件的安装过程标准化，且不管是什么内容。这是因为采用标准的操作系统工具来实现自动化安装。当启动一台新主机时，开发者可以拉取适当版本的服务包。此外，包还可以指定对其他包的依赖关系——例如，Rails应用可以指定依赖某些常见的Linux包，如libxml、libmagic或libssl。

但操作系统软件包方案有3个不足。

1）额外增加了对基础设施的需求：开发者需要创建和维护一个软件包仓库。

2）这些软件包通常与特定的操作系统高度耦合，导致在将软件包部署到不同的操作系统上时灵活性不足。

3）由于开发者仍然需要在主机环境中执行这些包，因此软件包并不适合在抽象级别上执行。

2．虚拟机镜像

在典型的虚拟环境中，可以选择虚拟机镜像作为部署工件。这样就不再需要将包拉取到一台普通机器上，而可以为每个待部署的服务版本创建一个镜像。标准的创建有4步。

1）为新镜像选择一个模板镜像作为基础；

2）根据模板镜像启动一台虚拟机；

3）将虚拟机配置成所期望的状态；

4）为新的虚拟机创建一个快照并将其保存为新的镜像模板。

这种方式构建出来的工件具有不可变性、可预测性，而且装备齐全自成一体，但也有如下不足。

1）镜像绑定在一个云服务提供商上。无法迁移到其他云服务提供商上，并且也无法在自己的机器上重新创建所部署的工件。

2）由于启动机器并创建快照需要很长时间，因此镜像构建过程通常都很慢。

3）难以采用单主机多服务的模式。

3．容器

不同于分发整个机器，像Docker或者rkt这样的容器化工具提供了一种更加轻量级的封装应用及其依赖的方式。可以在一台机器上运行多个容器，它们之间相互隔离，且具有比虚拟机更低的资源开销，因为这些容器共享同一套操作系统内核。容器还避免了每台虚拟机的硬盘虚拟化以及操作系统的开销。

除了充当一种打包机制，容器还提供了一套将应用执行相互隔离的运行环境，从而有效地简化了在一台机器上对不同容器执行的操作。这是最令人激动的，因为它在单台主机之上提供了非常明智的抽象。

不同于虚拟机镜像，容器镜像是可移植的，可以在任何支持容器运行环境的基础设施上运行容器。在需要将服务部署到多个不同环境的场景时，容器镜像可以简化部署工作。容器镜像同时还简化了本地开发的工作，在标准的开发机上运行多个容器要比构建和管理多个虚拟机容易得多。

摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》