Question

从 10.3 节中介绍的通用架构中可以看到，在构建/部署管道背后有许多活动部件。由于本书的目的是“在实战中”向读者介绍知识，我们将详细介绍为 EagleEye 服务实现构建/部署管道的细节。图 10-16 列出了要用来实现这一管道的不同技术。

图 10-16 EagleEye 构建中使用的技术

（1） GitHub ——GitHub 是我们的源代码控制库。本书的所有应用程序代码都在 GitHub 中。选择 GitHub 作为源代码控制库出于两个原因：首先，我不想管理和维护自己的 Git 源代码管理服务器；其次，GitHub 提供了各种各样的 Web 钩子和强大的基于 REST 的 API，用于将 GitHub 集成到构建过程中。

（2） Travis CI ——Travis CI 是我用于构建和部署 EagleEye 微服务，并提供 Docker 镜像的持续集成引擎。Travis CI 是一个基于云的、基于文件的 CI 引擎，它易于建立，并且与 GitHub 和 Docker 有着很强的集成能力。虽然 Travis CI 不像 Jenkins 这样的 CI 引擎功能那么全面，但对我们的使用来说已经足够了。10.5 节和 10.6 节将介绍如何使用 GitHub 和 Travis CI。

（3） Maven/Spotify Docke 插件 ——虽然我们使用 vanilla Maven 编译、测试和打包 Java 代码，但我们使用的一个关键 Maven 插件是 Spotify 的 Docker 插件，这个插件允许我们从 Maven 内部启动 Docker 构建的创建。

（4） Docker ——我选择 Docker 作为容器平台出于两个原因。首先，Docker 在多个云服务提供商之间是可移植的。我可以采用相同的 Docker 容器，并以最少的工作将其部署到 AWS、Azure 或 Cloud Foundry。其次，Docker 是轻量级的。在本书结束时，读者将会构建并部署大约 10 个 Docker 容器（包括数据库服务器、消息传递平台和搜索引擎）。在本地桌面上部署相同数量的虚拟机将是很困难的，因为每个镜像的规模大，并且需要的运行速度高。Docker、Maven 和 Spotify 的创建和配置将不在本章中讨论，而是留在附录 A 中介绍。

（5） Docker Hub ——构建完服务并创建了 Docker 镜像之后，需要使用唯一的标识符对 Docker 镜像进行标记，并将它推送到中央存储库。对于 Docker 镜像存储库，我选择使用 Docker Hub，即 Docker 公司的公共镜像存储库。

（6） Python ——为了编写在部署 Docker 镜像之前执行的平台测试，我选择了 Python 作为编写平台测试的工具。我坚信在工作中应使用合适的工具。坦率地说，我认为 Python 是一种非常棒的编程语言，特别是对于编写基于 REST 的测试用例。

（7） Amazon 的 EC2 容器服务（ECS） ——我们的微服务的最终目标是将 Docker 实例部署到亚马逊的 Docker 平台。我选择亚马逊作为我的云平台，因为它是迄今为止最成熟的云提供商，它能让 Docker 服务的部署变得十分简单。

等等，你说 Python 什么

读者可能会觉得奇怪，我用 Python 编写平台测试，而不是用 Java。我是故意这么做的。Python（就像 Groovy 一样）是编写基于 REST 的测试用例的绝妙脚本语言。我坚信在工作中应使用合适的工具。对采用微服务的组织来说，我所见过的最大的思想转变之一是，选择语言的职责应该在开发团队中。我在太多的组织中目睹过对标准的教条式拥护（“我们的企业标准是 Java……，所有的代码都必须用 Java 编写”）。因此，当 10 行的 Groovy 或 Python 脚本就可以完成这个工作时，我目睹过开发团队跳过这一选择，转而编写了一大堆 Java 代码。

我选择 Python 的第二个原因是，与单元测试和集成测试不同，平台测试是真正的“黑盒”测试，开发人员的行为就像在真实环境中运行的实际 API 的消费者。单元测试运行最低级别的代码，运行时不应该有任何外部依赖。集成测试上升了一个级别，它负责测试 API，但是需要 stub 或 mock 关键的外部依赖项（如对其他服务的调用、数据库调用等）。平台测试应该是真正独立于底层基础设施的测试。