老司机谈DevOps 2.0：二

微服务

在持续部署中，我们早已经讲到了速度问题。这里的速度是指从产生新功能的想法到开发完成并部署生产的时间。我们当然希望能够提高速度，尽早投放到市场。如果某个新功能可以在几个小时或者几天的时间里就完成交付，而不是几周或者数月，那么企业也就能够更快的获得收益。提高速度有很多方法，例如，我们希望流程处理速度越快越好，这样才能在出现问题的时候尽快发回反馈，同时释放资源供队列中的其他任务使用。我们应当努力减少从检查代码到部署生产的时间，这就用到了微服务技术。为一个巨大的巨石应用运行整个流程，进行测试、打包和部署通常十分缓慢。另一方面，因为微服务很小，所以速度自然也就很快。单次测试的代码量很少，需要打包的代码也少，当然需要部署的代码也就很少。

如果不是出于速度的考虑，我们也不会采用微服务。本书后面会有一大章专门分析微服务。现在我们需要注意的是，今天我们在软件行业面临的商业竞争无非就是时间的竞争，因此微服务可能是我们能够使用的最佳的架构。

容器

在容器流行之前，微服务的部署工作十分困难。巨石应用相对来说比较容易处理，我们只要创建了一个构件（JAR、WAR、DLL等），将其部署在服务器上并确保所需的可执行文档和库（例如JDK文件）都已经准备好就可以了。整个过程基本上已经实现了标准化，需要考虑的东西很少。当然，一个微服务也同样十分简单，但当微服务的数量剧增，达到几十个，数百个甚至上千个的时候，事情就变得复杂了。这些微服务可能要使用不同的依赖（dependency）、不同的框架、不同的应用服务器等等。我们需要考虑的东西呈指数型爆炸增长。不论如何，我们选择微服务的原因之一就是因为它能够为任务选择最佳的工具。某项任务可能最好用GoLang编写，而另一项任务则最好用NodeJS；某项任务可能使用JDK7，而另一项可能需要使用JDK8。管理服务器的人员需要对所有微服务任务进行安装和维护，这很快就会使服务器变成杂乱的垃圾箱，也很快会让他疯掉的。那么以前的解决方案是什么呢？尽可能的标准化。规定后端只能使用JDK7，前端只能使用JSP。公共代码应当存放在共享库中等等。换句话说，人们解决与微服务部署相关问题所使用的方法，正是他们多年以来在开发、维护以及部署巨石应用中学到的方法。为了标准化，砍掉了创新，但这当然不能怪他们。唯一的方法就是不可变虚拟机，而这也仅仅只能解决一部分问题。直到容器开始流行并能够被大众所使用，Docker使得容器的使用更加简单，不用考虑复杂的过程，所有人都能够很轻易的使用容器。

什么是容器？容器的定义是“存放或输送某样东西的物品”。大部分人会把容器和海运集装箱联系起来，认为容器应当能够用来装货、存储并进行处理。你可以看到人们用各种方式在运输容器，最常见的就是海运。在较大的船厂，你可以找到成百上千的容器堆叠在一起。几乎所有货品的运输都是通过容器，而原因也十分简单，容器是标准化的。标准化的容器就意味着它们可以很容易的堆叠在一起，而且难以破坏。大部分进行装运的人并不清楚容器内部是什么，也没有人（除了客户）在乎。其实容器内部是什么无所谓，最重要的是我们知道从哪里提取容器，然后运到何处。各司其职，我们在知道如何在外部处理容器，而容器内部是什么也只有一开始装货的人知道了。

“软件”容器的理念也是一样的。它们是各自独立并且不可改变的镜像，能够提供所需的各种功能，并且大部分情况下只能通过其各自的API接口连接使用。软件容器的出现是为了使我们的软件能够在任何环境（几乎）都可靠的运行。不论这些软件容器在哪里运行（研发人员的笔记本、测试或生产服务器、数据中心等等），其运行结果都是保持不变的。终于，我们可以不再有以下这种对话。

质控：登入界面有个问题。

开发人员：在我电脑上好好的啊！

之所以容器能够解决这类的问题，就是因为无论容器的运行环境怎么变化，其运行结果都是相同的。

容器的这种能力来源于其自给自足和不可改变两大特性。传统的部署方式会将工件（artifact）放在现有的节点处，同时保证应用服务器、配置文件和依赖等其他东西都已经准备好。而容器本身就已经包含了软件所需的所有东西，各种镜像文件一开始就会堆叠到容器中，这样容器中就包含了包括库、应用服务器、配置文件、运行依赖（runtimedependency）和操作系统包在内的所有东西。到目前为止我们对容器的描述也都符合虚拟机的定义，那么容器和虚拟机有什么区别呢？

例如，一台服务器上正运行着5个虚拟机，除了虚拟机监控器（耗费的资源比lxc（linux container容器）还多），每个虚拟机上都有各自的操作系统。而如果是五个容器，那么这些容器就可以共享服务器的操作系统，甚至在适当的时候还可使用服务器的库和二进制文件。因此，容器的体量更小。但这样看来，和巨石应用的差别好像也不大，尤其是当一个应用占用整个服务器的时候。微服务就不一样了，考虑到我们会有数十个甚至上百个微服务部署在同一台服务器上，那么我们所得的资源利用率就大大的提高了。换句话说，一台物理服务器可支持的容器数量要多于虚拟机数量。

三个火枪手：持续部署、微服务和容器的协同效应

持续部署、微服务和容器之间相辅相成。它们就像三个火枪手一样，每个都身怀绝技，但只有当它们协同合作的时候，才会彰显出真正的力量。

持续部署能够自动化的不断为我们提供应用开发状态的反馈信息，同时自动的持续将应用部署到生产环境。这样一来就提高了我们交付的应用质量，并且缩短了投放市场的时间。

微服务使得我们更加自由的做出更优的决策、更快的研发、以及不久之后我们将会看到的更简便的服务扩展。

最后，容器的出现解决了许多部署中存在的问题，尤其解决了和微服务一同使用时出现的问题。由于容器的不可变性，系统的可靠性也得到了一定程度的提高。

持续部署、微服务和容器协同使用，我们可以做到更多。本书中我们将一同探索，寻找方法实现频繁快速部署、全自动化、零宕机时间、回滚能力、跨环境可靠性、简易扩展以及创建自愈型系统（在发生故障后能够快速恢复）等能力。每一种能力的实现都需要我们付出很多，那么我们最终是否能够实现所有能力呢？当然可以！目前存在的方法和工具已经可以为我们提供这些能力，我们只需要正确的将这些能力整合为一体。路漫漫其修远兮，吾将上下而求索。我们需要从源头开始，既然要创建一个系统，那么首先我们就需要讨论系统的架构。

学需致用，思需有为（知道还不够，你必须实践；想法还不够，你必须去做）。--歌德