如果在每台服务器上运行启动脚本，启动脚本会从Git代码库拉取代码，安装一些依赖项，然后启动应用。这种方式是可行的，但也存在一些缺陷：应用启动特别慢，因为每台服务器都要并行执行相同的代码拉取和构建步骤，无法保证每台服务器运行的是相同版本的服务。这就导致部署结果不可预测且很脆弱。
为了消除这些缺陷并从中获益，开发者需要构建一个服务工件（service artifact）。服务工件是服务中一个确定的、不可修改的软件包。如果开发者对同一个代码提交记录执行构建流程，会生成相同的工件。
大部分技术栈都提供某种部署工件（比如Java的JAR文件、.NET的DLL文件、Ruby的gem、Python的package）。这些工件的运行时特性可能各有不同。比如，开发者需要使用IIS服务器来运行.NET的Web服务，而JAR文件可以内嵌到Tomcat这样的服务进程中自动执行。
一般来说，自动化构建工具（如Jenkins或CircleCI）负责构建服务工件并将其推送到工件仓库。工件仓库可能是专门的工具（比如，Docker提供了存储镜像的registry），也可能是通用的文件存储工具。
摘取自 摩根·布鲁斯和保罗·A.佩雷拉的《微服务实战》
网友评论