微信号:dockerone

介绍:最专业的Docker文章,最权威的Docker新闻.关注容器生态圈的发展.

使用Spring Boot和Docker构建微服务架构

2015-12-15 07:37 胡震 译


本文是《使用Spring Boot和Docker构建微服务架构》系列四部曲的前两篇,对微服务架构以及容器化概念作一个概述,利用工具进行设置,深入探讨如何使用Docker工作,然后搭建我们的第一个容器。

有关微服务的所有那些喧闹到底是什么?

随着越来越多的产品利用可重用的基于Rest的服务构建,人们很快发现把业务功能拆分成为可重用的服务是非常有效的,但同时也带来了一个风险。每次更新服务,您必须重新测试与它一起部署的每一个服务,即使您有信心认为代码更改不会影响其他服务,您永远无法真正确保这一点,因为这些服务会不可避免地共享代码、数据和其他组件。

随着容器化的兴起,你可以在一个完全隔离的环境中非常高效地运行代码,把它们两个组合在一起将会允许在细粒度可扩展性和版本控制方面的产品架构优化,不过付出的代价是增加了复杂性和一些重复的代码。

容器化是不是仅仅只是新的虚拟化?

答案是不完全是。容器和虚拟机具有一些相似性,它们都是通过一个控制进程管理的隔离环境(分别是容器管理器和虚拟机监控程序),但两者之间的主要区别是,对于每一个虚拟机,运行的是一个完整的组件堆栈——从操作系统到应用服务器,以及仿真的虚拟硬件包括网络组件、CPU和内存。

对于容器来讲,它们运行在更为完全隔离的沙盒中,出现在每个容器里的仅仅是操作系统的最小内核,共享了底层系统的资源。容器化的最大优势在于对于相同的硬件占用空间更小,可以比虚拟机运行更多的实例。容器也有一些关键的限制:最大的一个是容器只能运行在基于Linux的操作系统上面(内核隔离是Linux的特定技术)。

与这一限制相关的就是Docker——目前最流行的容器服务提供系统——不能直接运行在Mac或者Windows系统上,因为它们不是Linux,替代方案就是为了运行Docker,你需要使用VirtualBox启动一个Linux虚拟机,接着在虚拟机里运行Docker。幸运的是,它绝大多数是由Docker ToolBox来管理的(原名Boot2Docker)。

Docker已经获得了众多的支持,以至于容器镜像的公共Repository——Docker Hub,拥有超过了136,000个公共镜像。其中许多是由个人创建的,一些扩展自“官方”镜像然后按照他们自己的需求做了定制,但是其它的都是从“基础”镜像做了完整的平台配置定制化。我们将利用这些“基础”和“官方”镜像开始我们的研究之旅。

所以我们已经谈论了微服务和容器化,但是Spring Boot在哪个部分起作用呢?

我选择使用Java来构建我自己的微服务,具体地说就是Spring Boot框架。选择它主要是因为我熟悉Spring、易于开发的Rest服务Controller、业务服务以及数据存储,还可以很容易地引入Scala的Akka/Play编程模型。微服务架构的其中一个最为人称道的优势就是服务的完全独立,所以不需要也不应该关心每一个服务采用什么语言或平台构建。

就我个人而言,我认为多语言的维护成本要比获得的弹性收益更大,但也有适用的用例,比如在一个大组织内的一个部门已经选择了不同的技术栈为“标准”的情况下。另外一个可能的场景就是如果你决定从一个语言/平台转换到另外一个——你可以每次迁移一个微服务,提供相同的终端Web服务接口。我们努力的目标如下:

  • 一个从开始设置微服务和Docker到如何结束的指南。

  • 了解围绕微服务架构的诸多组件的作出的不同决定的利弊——从源代码控制到服务版本化,以及其中的一切。

  • 分析“纯粹”的微服务信仰,并且看它们如何应用到一个“现实世界”的场景。

  • 看Docker是如何面对喧嚣,以及为专业开发运行Docker什么是必需的。

  • 利用一系列的微服务构建一个完整的解决方案,每一个微服务都有它自己的容器,一个在自身容器托管的持久化层,还有容器集群。

  • 其它有价值的内容。

我将模拟的业务场景是一家软件开发公司的员工任务分配和识别系统,包含了以下任务:

  • 员工登录进系统

  • 员工看到要求的任务列表,比如写一篇关于新兴技术的博文、参加一个会议、举行一次Code Review

  • 员工向他们的经理提交这些任务的完成批准

  • 员工获得完成任务的“打分”

  • 员工依据“打分”可以获得奖励,比如公司礼物、与CEO一对一的免费午餐等等。

介绍和工具

我是在Mac上工作的,但是工具在Mac和PC上是相同的,所以在平台上的操作是99%相同的,我将不会回顾如何安装这些工具,而是直接从如何使用它们开始,你所需要的准备工作如下:

  • Docker Toolbox:包含了VirtualBox(作用为创建虚拟机用来运行容器)、Docker Machine(在虚拟机内运行Docker容器)、Docker Kitematic(一个管理在Docker Machine里运行的容器的GUI)以及Docker Compose(多容器编排工具)

  • Git:我的GitHub链接在这儿(https://github.com/ThreePillarGlobal/microservice-blog),我在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:2376
DOCKER_MACHINE_NAME=default
DOCKER_TLS_VERIFY=1
DOCKER_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 sh

mongo

MongoDB shell version: 3.0.6
connecting to: test
Server 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 microserviceblog
switched to db microserviceblog
> db.createCollection('testCollection')
{ "ok" : 1 }

在容器内部,Mongo看起来正在运行,但是我们可以从外部获知吗?为了尝试这个,我们需要查看什么临时端口被映射到了Mongo的端口上,我们运行如下命令:

docker ps

从下面我们可以看到(为了可读性省略了一些列):

CONTAINER ID        IMAGE                PORTS                      NAMES
87192b65de95        mongo                0.0.0.0:32777->27017/tcp   mongodb

我们可以看到宿主机端口32777映射到了容器端口27017上,然而,记住我们的容器是运行在虚拟机上的,所以我们必须回到我们的环境变量:

$ echo $DOCKER_HOST
tcp://192.168.99.100:2376

我们应该可以通过如下的地址访问我们的Mongo容器的27017端口:
192.168.99.100:32777,启动Mongo然后点击那个位置显示数据库可以外部访问:


本文为翻译文章,阅读原文,请点击左下角阅读原文链接。


 
Docker 更多文章 Docker热点一周汇总 Docker容器的日志集中化处理 基于线程与基于事件的并发编程之争 Docker网络管理的未来 10x系列之Clay.io的架构
猜您喜欢 Android单元测试(六):Dagger2上篇-依赖注入的困境 想做Web开发,就学JavaScript 拍照怎么搜题?(下) python VS matlab 关于 “混圈子” 和 “群交流”