15、微服务部署：从镜像到主机映射的全面指南

微服务部署：从镜像到主机映射的全面指南

1. 镜像作为制品

在软件开发中，我们可以创建包含依赖项的虚拟机镜像，以此加快反馈速度。更进一步，我们可以将服务直接嵌入镜像，采用以镜像作为服务制品的模式。当启动镜像时，服务就能立即运行。Netflix 采用将自身服务打包为 AWS AMIs 的模式，原因就在于此模式能实现极快的启动速度。

这些虚拟机镜像和特定于操作系统的软件包一样，是一种很好的抽象机制，它能屏蔽创建服务所使用的技术栈差异。我们无需关心运行在镜像上的服务是用 Ruby 还是 Java 编写，也不用在意它使用的是 gem 还是 JAR 文件，只要服务能正常运行即可。因此，我们可以将精力集中在自动化创建和部署这些镜像上，同时，这也是实现“不可变服务器”这一部署概念的绝佳方式。

2. 不可变服务器

将所有配置存储在版本控制系统中，我们期望能按需自动重现服务乃至整个环境。然而，部署完成后，如果有人登录服务器并独立于版本控制系统进行更改，就会出现“配置漂移”问题，即版本控制系统中的代码与运行主机的配置不再一致。

为避免这一问题，我们要确保运行中的服务器不做任何更改。任何更改，无论多小，都需通过构建管道来创建新机器。虽然不使用基于镜像的部署也能实现这一模式，但这也是将镜像作为制品的合理延伸。例如，在创建镜像时，我们可以禁用 SSH，防止他人登录服务器进行更改。

不过，之前提到的关于周期时间的注意事项依然适用，并且我们要确保存储在服务器上的重要数据有其他存储方式。尽管存在这些复杂性，但采用不可变服务器模式能使部署更直接，环境更易于理解。

3. 环境

软件在持续交付（CD）管道的各个