转载

使用Spring Boot和Docker构建微服务架构第一篇微服务架构和容器化概述

【编者的话】本篇是《使用Spring Boot和Docker构建微服务架构》系列四部曲的第一篇，本篇将会对我们谈及的微服务架构以及容器化概念作一个概述。原文作者为3Pillar环球旗下美国Adbanced技术集团的总监Dan Greene，Dan有十八年的软件设计和开发经验，包括在电子商务、B2B集成、空间分析、SOA架构、大数据以及云计算等领域的软件产品架构经验，他是AWS认证解决方案架构师，在3Pillar之前先后就职于Oracle、ChoicePoint和Booz Allen Hamilton。Dan毕业于乔治●华盛顿大学，他也是一个父亲、业余木工爱好者，还参加过包括国际障碍大赛这样的障碍赛跑。

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

随着越来越多的产品利用可重用的基于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

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

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