Question

本章主要内容

• 理解为什么 DevOps 运动对微服务至关重要
• 配置 EagleEye 服务使用的核心亚马逊基础设施
• 手动将 EagleEye 服务部署到亚马逊的 EC2 容器服务中
• 为服务设计构建和部署管道
• 从持续集成转向持续部署
• 将基础设施视为代码
• 构建不可变的服务器
• 在部署中测试
• 将应用程序部署到云

本书已经接近结尾，但我们的微服务旅程还没有走到终点。尽管本书的大部分内容都集中在使用 Spring Cloud 技术设计、构建和实施基于 Spring 的微服务上，但我们还没有谈到如何构建和部署微服务。创建构建和部署管道似乎是一项普通的任务，但实际上它是微服务架构中最重要的部分之一。

为什么这么说呢？请记住，微服务架构的一个主要优点是，微服务是可以快速构建、修改和部署到独立生产环境中的小型代码单元。服务的小规模意味着新的特性（和关键的 bug 修复）可以以很高的速度交付。速度是这里的关键词，因为速度意味着新特性或修复 bug 与部署服务之间可以平滑过渡，致使部署的交付周期应该是几分钟而不是几天。

为了实现这一点，用于构建和部署代码的机制应该是具有下列特征的。

• 自动的 ——在构建代码时，构建和部署过程不应该有人为干预，特别是在级别较低的环境中。构建软件、配置机器镜像以及部署服务的过程应该是自动的，并且应该通过将代码提交到源代码存储库的行为来启动。
• 可重复的 ——用来构建和部署软件的过程应该是可重复的，以便每次构建和部署启动时都会发生同样的事情。过程中的可变性常常是难以跟踪和解决的微小 bug 的根源。
• 完整的 ——部署的软件制品的成果应该是一个完整的虚拟机或容器镜像（Docker），其中包含该服务的“完整的”运行时环境。这是开发人员对待基础设施的一个重要转变。机器镜像的供应需要通过脚本实现完全自动化，并且这个脚本与服务源代码一起处于源代码控制之下。
• 在微服务环境中，这种职责通常从运维团队转移到拥有该服务的开发团队。请记住，微服务开发的核心原则之一是将服务的全部运维责任推给开发人员。
• 不可变的 ——包含服务的机器镜像一旦构建，在镜像部署完后，镜像的运行时配置就不应该被触碰或更改。如果需要进行更改，则需要在源控制下的脚本中进行配置，并且服务和基础设施需要再次经历构建过程。

运行时配置（垃圾回收设置、使用的 Spring profile）的更改应该作为环境变量传递给镜像，而应用程序配置应该与容器隔离（Spring Cloud Config）。

构建一个健壮的、通用的构建部署管道是一项非常重要的工作，并且通常是针对服务将要运行的运行时环境专门设计的。这项工作通常涉及一个专门的 DevOps（开发人员运维）工程师团队，他们的唯一工作就是使构建过程通用化，以便每个团队都可以构建自己的微服务，而不必为自己重复发明整个构建过程。但是，Spring 是一个开发框架，它并没有为实现构建和部署管道提供大量功能。

在本章中，我们将看到如何使用众多非 Spring 工具来实现构建和部署管道。我们将利用为本书所构建的一套微服务，完成以下几件事。

（1）将一直使用的 Maven 构建脚本集成到一个名为 Travis CI 的持续集成/部署云工具中。

（2）为每个服务构建不可变的 Docker 镜像，并将这些镜像推送到一个集中式存储库中。

（3）使用亚马逊的 EC2 容器服务（EC2 Container Service，ECS）将整套微服务部署到亚马逊云上。

（4）运行平台测试，测试服务是否正常工作。

我想以最终目标开始我们的讨论，那就是一组部署到 AWS 弹性容器服务（Elastic Container Service，ECS）上的服务。在深入了解如何实现构建和部署管道的所有细节之前，我们先了解一下 EagleEye 服务将如何在亚马逊云中运行。然后，我们再讨论如何手动将 EagleEye 服务部署到 AWS 云。一旦完成这一步，我们将自动化整个过程。