Spring Boot与Docker（二）：使用Spring Boot和Docker构建微服务架构

本篇是《使用Spring Boot和Docker构建微服务架构》系列的第二篇，本篇我们将会利用工具进行设置，深入探讨如何使用Docker工作，然后搭建我们的第一个容器。原文作者为3Pillar环球旗下美国Adbanced技术集团的总监Dan Greene，Dan有十八年的软件设计和开发经验，包括在电子商务、B2B集成、空间分析、SOA架构、大数据以及云计算等领域的软件产品架构经验，他是AWS认证解决方案架构师，在3Pillar之前先后就职于Oracle、ChoicePoint和Booz Allen Hamilton。Dan毕业于乔治·华盛顿大学，他也是一个父亲、业余木工爱好者，还参加过包括国际障碍大赛这样的障碍赛跑。介绍和工具在本篇中，我们将会构建第一篇中讨论的解决方案。我是在Mac上工作的，但是工具在Mac和PC上是相同的，所以在平台上的操作是99%相同的，我将不会回顾如何安装这些工具，而是直接从如何使用它们开始，你所需要的准备工作如下：Docker Toolbox：包含了VirtualBox（作用为创建虚拟机用来运行容器）、Docker Machine（在虚拟机内运行Docker容器）、Docker Kitematic（一个管理在Docker Machine里运行的容器的GUI）以及Docker Compose（多容器编排工具）
Git：我的GitHub链接在这儿，我在Windows上使用Git Extensions，在Mac上使用Source Tree，不过使用其他Git客户端包括命令行都是可以的。
Java 8 SDK：Java 8在JVM永久代（PermGen）方面有了改进，另外对于Streams API和Lambda的支持也是非常赞的。
构建工具的选择：让我们使用Gradle吧，我推荐使用SDKMan，正式名称为GVM来管理Gradle版本，如果你使用Windows工作，你可以使用Cygwin安装SDKMan或者SDKMan的Powershell命令行工具，或者Gravy也是可替代的选择。
IDE的选择：我们使用Spring Tool Suite（STS）来工作，在本文写作时最新的for Mac版本为3.7.0。
Rest工具：对于任何Web服务项目使用都非常方便，我是Chrome扩展工具Postman的粉丝，如果你擅长curl命令行，这个工具也是不错的。
uMongo或者Mongo GUI：文档型数据库完美匹配自足性的模型——对象进行自动检索，并且参考对象可以在微服务架构中通过ID来引用，这些ID可以很好地映射到文档存储中，另外地，MongoDB拥有运行很棒的“官方”Docker镜像。

我们对于源代码管理的第一个意见——似乎也是绝大多数的在线观点，就是每个微服务都应该有自己的版本库。微服务的一个基本理念就是跨服务之间不能共享代码。就我个人而言，这对我架构师的小心脏是个小小的打击，因为任何实用工具的重复代码的数量可能会比较多，以及缺乏一个单一、统一的领域模型给我有点心痛的感觉。我理解这个原则——自足性意味着自力更生。为了这篇博文，我把所有的代码都放到了一个单独的代码库，然而，每个微服务在根目录下都有它一个自己的目录。这样做是为了让我可以随着时间的推移展示分支的进展。在一个真实的解决方案中，你应该让每一个微服务都有它自己的不同的版本库，也许会有统一的版本库引用其它的子模块。总体思路因为我们要处理隔离的、可重用的组件，我们将做以下的映射：一个逻辑业务对象→一个微服务→一个Git版本库目录→一个Mongo集合因为业务对象可能由多个对象组成，任何我们认为可以作为其自身业务对象的子对象都可以划分为其自身的组件栈。更多有关Docker如何工作的信息，以及我们的第一个容器为了理解如何构建一个完整的基于Docker容器的产品解决方案，我们将需要深入研究容器是如何在宿主机（或者是虚拟机，正如我们的例子）里运行的，使用Docker通常是有三个阶段：镜像构建、镜像分发和容器部署。构建镜像——Dockerfile的世界为了构建镜像，你要写一系列的指令用来获取已有的镜像，接着对该镜像做些改变和配置。官方的Docker Hub Repository包含了许多的“官方”镜像以及数以千计的用户定制的镜像。如果其中的镜像不太符合你的需求，你可以创建一个定制的Dockerfile，用来在镜像上逐步添加一些内容，，比如安装系统软件包、复制文件或者公开一些网络端口，当我们构建微服务时，我们将会创建一个定制的Dockerfile，不过现在，我们将会利用一个标准镜像来启动一个MongoDB实例。容器联网当容器启动时，有一个它私有的网络，容器宿主机端口将外部网络通信转发到单个的容器端口上，特定的容器端口可以通过Dockerfile来决定公开，并且端口转发可以通过以下两种方式之一来进行：你可以显式地从宿主机映射端口到容器上，或者如果没有显式映射的话，Docker将映射已声明的容器端口到宿主机一个可用的临时端口上（通常的范围是从32768到61000）。当我们可以对整个解决方案显式地管理端口映射时，通常让Docker处理这一切是一个更加好的主意，并且可以通过Link机制公开端口信息到容器上，这方面将在我们构建我们的第一个微服务容器时有所涉及。启动MongoDB容器无论你是使用Kitematic还是Docker命令行，都可以非常简单的启动一个标准的容器。使用命令行的话，如果一切都安装正确，命令提示符将会包含以下三个关键的环境变量：DOCKER_HOST=tcp://192.168.99.100:2376DOCKER_MACHINE_NAME=defaultDOCKER_TLS_VERIFY=1DOCKER_CERT_PATH=/Users/[username]/.docker/machine/machines/default
这些是按照你的情况设置的（如果是在安装过程中打开的话，你可能需要重启终端或者命令提示符）。这些都是必要的，因为Docker不能直接运行在我的Mac笔记本上，而是跑在笔记本运行的虚拟机上。Docker客户端非常有效地将Docker命令从我的笔记本“代理”到虚拟机上，在我们启动容器前，让我们重温一下一部分Docker命令是非常有益的，在使用任何图形用户界面之前，了解命令行的东西总是很好的。Docker级别的命令：docker ps该命令将会列出所有运行的容器，显示的信息包括它们的ID、名字、基础镜像名字和端口映射信息等。docker build该命令用来定义一个镜像——通过处理Dockerfile来创建一个新的镜像，我们将用这个命令来构建我们的微服务镜像。docker pull[镜像名字]该命令从远程Repository拉取镜像并且存储在本地。docker run该命令将基于一个本地或者远程Repository（比如Docker Hub）启动一个容器，我们将会相当多地探究这个命令。docker push该命令推送一个构建好的镜像到一个Repository，通常是Docker Hub。容器特定的命令这些命令使用容器ID或者名字作为一个参数：docker status [容器名字/ID][容器名字/ID]这个命令将显示指定的每一个容器的当前负载，比如CPU占用率、内存使用率以及网络流量等。docker logs [-f][容器名字/ID]该命令显示容器的最新的日志，-f选项就好比Shell终端中的“tail -f”中的-f选项。docker inspect [容器名字/ID]该命令将容器的所有配置信息以JSON的格式转储出来显示。docker port [容器名字/ID]该命令显示容器与宿主机之间的所有端口映射信息。docker exec [-i][-t][容器名字/ID]该命令将在目标容器上执行一条命令（-i表明以交互方式运行，-t表明以伪TTY终端运行），这个命令常用来获得一个容器终端Shell：docker exec -it [容器名字/ID]sh一旦我们理解了这些参考材料，我们可以进入到下一步启动一个Mongo容器。命令非常简单：docker run -P -d —name mongo mongo解释如下：P选项告知Docker在临时端口范围里公开容器声明的任何端口
d选项告知以Daemon方式运行容器（比如在后台）
name选项给容器分配一个名字（名字必须在所有运行的容器实例中唯一，如果你不提供这个选项，将会获得一个随机的半友好的名字比如modest_poitras）
最后的mongo表明了使用哪一个镜像

Docker Hub镜像的定义采用了[所有者]/[镜像名字][:标签]的命名格式，如果没有指定所有者，那么使用的就是“官方”的Docker Hub镜像——这是预留给Docker官方给软件供应商的礼物也就是成为官方镜像，如果最后的标签部分省略的话，那么就会认为你需要获得的是最新版本的镜像。现在我们来尝试确认我们的Mongo实例已经启动并且运行了：docker exec -it mongo shmongo
MongoDB shell version: 3.0.6connecting to: testServer has startup warnings:2015-09-02T00:57:30.761+0000 I CONTROL [initandlisten]2015-09-02T00:57:30.761+0000 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/enabled is 'always'.2015-09-02T00:57:30.761+0000 I CONTROL [initandlisten] ** We suggest setting it to 'never'2015-09-02T00:57:30.761+0000 I CONTROL [initandlisten]2015-09-02T00:57:30.761+0000 I CONTROL [initandlisten] ** WARNING: /sys/kernel/mm/transparent_hugepage/defrag is 'always'.2015-09-02T00:57:30.761+0000 I CONTROL [initandlisten] ** We suggest setting it to 'never'2015-09-02T00:57:30.761+0000 I CONTROL [initandlisten]> use microserviceblogswitched to db microserviceblog> db.createCollection('testCollection'){ "ok" : 1 }
在容器内部，Mongo看起来正在运行，但是我们可以从外部获知吗？为了尝试这个，我们需要查看什么临时端口被映射到了Mongo的端口上，我们运行如下命令：docker ps
从下面我们可以看到（为了可读性省略了一些列）：CONTAINER ID IMAGE PORTS NAMES87192b65de95 mongo 0.0.0.0:32777->27017/tcp mongodb
我们可以看到宿主机端口32777映射到了容器端口27017上，然而，记住我们的容器是运行在虚拟机上的，所以我们必须回到我们的环境变量：$ echo $DOCKER_HOSTtcp://192.168.99.100:2376
我们应该可以通过如下的地址访问我们的Mongo容器的27017端口：192.168.99.100:32777，启动Mongo然后点击那个位置显示数据库可以外部访问：[图片上传中。。。（1）]
在这里结束第二篇吧，在本系列的第三篇中，我们将继续探讨，通过创建一个或两个微服务，管理它们的变化，然后运用持续集成以及产品部署技术进行工作。原文链接：BUILDING A MICROSERVICE ARCHITECTURE WITH SPRING BOOT AND DOCKER, PART II（翻译：胡震）