微服务架构之「 容器技术 」

Posted 2023-03-16

参考技术A 现在一聊到容器技术，大家就默认是指 Docker 了。但事实上，在 Docker 出现之前，PaaS社区早就有容器技术了，以 Cloud Foundry、OpenShift 为代表的就是当时的主流。

那为啥最终还是 Docker 火起来了呢？

因为传统的PaaS技术虽然也可以一键将本地应用部署到云上，并且也是采用隔离环境（容器）的形式去部署，但是其兼容性非常的不好。因为其主要原理就是将本地应用程序和启停脚本一同打包，然后上传到云服务器上，然后再在云服务器里通过脚本启动这个应用程序。

这样的做法，看起来很理想。但是在实际情况下，由于本地与云端的环境差异，导致上传到云端的应用经常各种报错、运行不起来，需要各种修改配置和参数来做兼容。甚至在项目迭代过程中不同的版本代码都需要重新去做适配，非常耗费精力。

然而 Docker 却通过一个小创新完美的解决了这个问题。在 Docker 的方案中，它不仅打包了本地应用程序，而且还将本地环境（操作系统的一部分）也打包了，组成一个叫做「 Docker镜像 」的文件包。所以这个「 Docker镜像 」就包含了应用运行所需的全部依赖，我们可以直接基于这个「 Docker镜像 」在本地进行开发与测试，完成之后，再直接将这个「 Docker镜像 」一键上传到云端运行即可。

Docker 实现了本地与云端的环境完全一致，做到了真正的一次开发随处运行。

一、容器到底是什么？

容器到底是什么呢？也许对于容器不太了解，但我们对虚拟机熟悉啊，那么我们就先来看一下容器与虚拟机的对比区别：

上图的左侧是虚拟机的原理，右侧是Docker容器的原理。

虚拟机是在宿主机上基于 Hypervisor 软件虚拟出一套操作系统所需的硬件设备，再在这些虚拟硬件上安装操作系统 Guest OS，然后不同的应用程序就可以运行在不同的 Guest OS 上，应用之间也就相互独立、资源隔离了，但是由于需要 Hypervisor 来创建虚拟机，且每个虚拟机里需要完整的运行一套操作系统 Guest OS，因此这个方式会带来很多额外资源的开销。

而 Docker容器 中却没有 Hypervisor 这一层，虽然它需要在宿主机中运行 Docker Engine，但它的原理却完全不同于 Hypervisor，它并没有虚拟出硬件设备，更没有独立部署全套的操作系统 Guest OS。

Docker容器没有那么复杂的实现原理，它其实就是一个普通进程而已，只不过它是一种经过特殊处理过的普通进程。

我们启动容器的时候（docker run …），Docker Engine 只不过是启动了一个进程，这个进程就运行着我们容器里的应用。但 Docker Engine 对这个进程做了一些特殊处理，通过这些特殊处理之后，这个进程所看到的外部环境就不再是宿主机的那个环境了（它看不到宿主机中的其它进程了，以为自己是当前操作系统唯一一个进程），并且 Docker Engine 还对这个进程所使用得资源进行了限制，防止它对宿主机资源的无限使用。

那 Docker Engine 具体是做了哪些特殊处理才有这么神奇的效果呢？

二、容器是如何做到资源隔离和限制的？

Docker容器对这个进程的隔离主要采用2个技术点：

弄清楚了这两个技术点对理解容器的原理非常重要，它们是容器技术的核心。

下面来详细解释一下：

三、容器的镜像是什么？

一个基础的容器镜像其实就是一个 rootfs，它包含操作系统的文件系统（文件和目录），但并不包含操作系统的内核。

rootfs 是在容器里根目录上挂载的一个全新的文件系统，此文件系统与宿主机的文件系统无关，是一个完全独立的，用于给容器进行提供环境的文件系统。

对于一个Docker容器而言，需要基于 pivot_root 指令，将容器内的系统根目录切换到rootfs上，这样，有了这个 rootfs，容器就能够为进程构建出一个完整的文件系统，且实现了与宿主机的环境隔离，也正是有了rootfs，才能实现基于容器的本地应用与云端应用运行环境的一致。

另外，为了方便镜像的复用，Docker 在镜像中引入了层（Layer）的概念，可以将不同的镜像一层一层的迭在一起。这样，如果我们要做一个新的镜像，就可以基于之前已经做好的某个镜像的基础上继续做。

如上图，这个例子中最底层是操作系统引导，往上一层就是基础镜像层（Linux的文件系统），再往上就是我们需要的各种应用镜像，Docker 会把这些镜像联合挂载在一个挂载点上，这些镜像层都是只读的。只有最上面的容器层是可读可写的。

这种分层的方案其实是基于 联合文件系统UnionFS（Union File System）的技术实现的。它可以将不同的目录全部挂载在同一个目录下。举个例子，假如有文件夹 test1 和 test2 ，这两个文件夹里面的文件 有相同的，也有不同的。然后我们可以采用联合挂载的方式，将这两个文件夹挂载到 test3 上，那么 test3 目录里就有了 test1 和 test2 的所有文件（相同的文件有去重，不同的文件都保留）。

这个原理应用在Docker镜像中，比如有2个同学，同学A已经做好了一个基于Linux的Java环境的镜像，同学S想搭建一个Java Web环境，那么他就不必再去做Java环境的镜像了，可以直接基于同学A的镜像在上面增加Tomcat后生成新镜像即可。

以上，就是对微服务架构之「 容器技术 」的一些思考。

码字不易啊，喜欢的话不妨转发朋友，或点击文章右下角的“在看”吧。

技术雷达之微服务架构｜洞见

最近几年，微服务架构异军突起，与容器技术相辅相成，成为架构设计领域热议的话题。而作为ThoughtWorks出品的一份关于技术趋势的报告，在技术社区也一直有着非常好的口碑。本篇文章就试图结合技术雷达与微服务架构，以往期技术雷达中微服务架构的演变来审视一下这个新兴架构的整个发展过程。

相信大家了解微服务架构或者听说微服务架构也都是近两年的事情，从Google Trends的搜索数据统计上看，微服务架构确实也是从2014年才逐渐兴起，到目前呈现出一个爆发的趋势。

但技术雷达在2012年的3月份就已经提及了微服务架构相关的内容，在当时，其所处的状态还是评估（Assess）阶段，这就说明技术雷达早在2012年初的时候就已经成功捕获到微服务架构这个新的技术架构。

（微服务2012年第一次出现在技术雷达上）

   

到底什么才是微服务架构

Martin Fowler在那篇著名的描述微服务架构的文章中第一次定义了微服务架构并阐述了其九大特性。而我一开始接触微服务架构的时候也觉得这好像不是一个新的概念，很早之前就有RPC和SOA这种面向服务的分布式架构，又冒出一个新的微服务架构，他们到底有什么区别？

看到Martin Fowler的定义以后，才慢慢清楚他们的区别，在Martin Fowler的定义中有几个关键字可以让我们甄别一个分布式架构是传统的面向服务架构还是新的微服务架构：每个服务是不是跑在独立的进程中？是不是采用轻量级的通讯机制？是不是可以做到独立的部署？

（微服务架构的定义）

时间来到了2012年的10月份，在这期的技术雷达中，微服务架构已经从评估（Assess）阶段被移到实验（Trial）阶段。什么叫实验阶段？ThoughtWorks内部有一个解释，就是这项技术已经可以运用在实际项目中，但你仍要控制风险，也就是说此项技术已经可以在风险比较低的项目中使用了。

一个项目要能被移到试验的阶段，还有一个必须要满足的条件，就是必须在ThoughtWorks自己的项目中已经开始实际使用。幸运的是，我当时所在的项目也是在2012年10月份左右开始采用微服务架构的，结果也是非常好的。我们在3个月完成一个新的应用并成功上线，当时客户评价很高。 

   

实际体验下来，微服务架构对我们究竟有哪些好处？这几点是我体会到的：

• 首先是组件化，作为一个软件开发人员，我们一直都有一个梦想，就是希望有朝一日可以把一堆组件像乐高一样通过直接拼装的方式快速构建我们的应用。无论是最早基于拖拽的方式构建应用，还是现在大热的前端组件化，我们一直都在试图寻找一种更好的组件化方式，微服务架构也是其中之一。

  但构建软件本身仍是一个非常复杂的过程，微服务架构为我们提供了一种组件化的可能，但直到现在还不好说它能不能达到我们作为整体组件化的目标，但是至少从实际体验来看，它确实能给我们带来组件化的很多好处。

• 然后是弹性架构，在2015年11月期中推荐了亚马逊的弹性计算平台，如果我们的系统是由按业务划分的服务构成，结合容器技术和云平台我们就可以构建一个极具弹性的架构。通过云平台实时的监控，一旦发现资源紧张，立刻就可以通过云平台和容器技术自动瞬间扩展出成百上千的服务资源，在高峰过去之后又可以立即把所有的服务注销掉，释放资源，整个过程完全是自动化的。

• 去中心化和快速响应也是微服务架构给我们带来的好处。在单体架构下，会非常依赖于项目一开始时对于技术选择，一旦选择了一个技术栈，那么之后几年都被绑定在了这样一个技术栈下，很难应对变化。微服务架构则给我们提供了一个更细粒度使用技术的可能，在不同的服务里可以使用完全不同的技术栈，不同的语言、框架甚至数据库，真正做到用最适合的技术解决最适合的问题，从而让我们可以更加敏捷地响应需求和市场的变化，增加了竞争力。

（微服务架构的好处）

   

从2012年10月份一直到2014年的7月份，在这个时间段有大量与微服务架构相关的工具、技术和框架出现在技术雷达上。包含了很多领域：语言、测试，框架、CI、CD、持续交付，安全等等。

从2012年的3月份微服务架构第一次出现在技术雷达上一直到2014年7月份，虽然微服务架构已经有了比较大的发展，技术雷达上也已经推荐了大量相关的内容，但在当时社区中谈论微服务架构的声音并不多，这也体现出了技术雷达的前瞻性。

（技术雷达上微服务架构相关项目）

从2014年7月份开始微服务在社区就开始呈现出一种爆发的趋势，但在紧接着的2015年1月刊的技术雷达中却出现一个非常有意思的项目：Microservice Envy。通俗点儿讲就是“微服务红眼病”，或者说是“微服务你有我也要”。

这意味着在社区刚刚爆发，对于微服务架构踩下油门的时候，我们已经踩下了一脚刹车。但这并不是代表我们不看好微服务架构，而是认为需要认真思考我们是否真正需要以及何时以何种方式使用微服务架构，不能看别的人都在使用也盲目切换到微服务架构下。

这是因为微服务架构并不是免费的午餐，使用微服务架构是需要门槛和成本的。我们需要问自己：用微服务我们够“个”吗？或是说用微服务我们够“格”么？我们是否有这个能力和足够的资源驾驭这个新的架构？

Martin Fowler在他的《企业应用架构模式》中，就提到了分布式对象设计的第一原则：“设计分布式对象的第一个原则就是不要使用分布式对象”。因为分布式系统会给我们带来很大的挑战，让系统复杂度大幅增加的同时，我们还需要面对开发环境、测试、部署、运维、监控，一致性和事务等一系列的问题。

（Microservice Envy）

所以说，微服务架构虽然看起来非常美好，但是也是有很大附加成本的。通过下面这张图可以看到，横轴是时间轴，纵轴是生产力。

当软件的复杂度很低的时候，单体架构下的生产力是要高于微服务架构的，但随着复杂度的不断增加，无论是单体应用还是微服务应用的生产力都会下降，只是微服务架构的下降会相对缓慢一些。

这也容易理解，因为在微服务架构中，我们的系统是由很多的小的服务组成，每一个服务都很小，相对简单，技术栈也很独立。这样做局部的变更也会更加容易，随着系统复杂度的不断增加，微服务的优势也就慢慢地体现出来了。

   

那要如何应对呢？

为了追求生产力的最大化，一开始我们可以选择从一个单体架构开始，然后争取在微服务架构生产力超越单体架构的那个复杂度点切换到微服务架构上来，这样才能实现生产力的最大化。这就是Martin Fowler提出的单体应用优先原则（MonolithFirst），以单体架构开始，通过演进式设计逐渐重构到微服务架构。

（MonolithFirst）

为了保证从单体架构演进到微服务架构的重构过程安全可控，还需要有一套良好的质量守护机制。下图描述的就是Martin Fowler提出的微服务架构下的测试策略，我所在项目就是按照这种方式来划分和设计我们各种不同类型的测试，帮助我们在对于服务的抽取合并分离的重构过程中做到安全可控。

（Testing Strategies in a Microservice Architecture）

我们刚才提到了康威定律，康威定律说的是设计系统的组织产生的设计和架构等价于组织间的沟通结构。而康威定律还有一个逆定律：如果想改变一个设计架构方式，首先要改变组织结构。

我们经常发现推动技术架构的转型和演进很难，因为我们在调整技术架构的同时却忽略了组织结构也要对应做相应的调整以匹配技术架构的变化，当组织结构与技术架构不匹配的时候，就会相互拉扯，这些都是在当时的技术雷达中着重强调的。

   

截至目前，以上内容都还是在谈论2015年以前各期技术雷达里的内容。在这之后直到现在，技术雷达也还在持续地推荐微服务架构相关的内容。所以说踩下刹车并不是因为我们走错了路，只是走的太快了，需要时刻提醒自己不要盲目，要清楚微服务给我们带来了什么和有着什么样的挑战，最终解决我们的问题。

来到最新的几期技术雷达，微服务架构还在不断的演进，而且慢慢的与其他新兴的技术融合形成一整套的新的不同以往的构建软件的解决方案。

例如无服务器架构、对Docker的应用、对PaaS各种云的应用等，这些技术的发展，会不会对微服务架构的演进提供更多可能？是否可以为微服务架构早一天落地、改变我们的开发方式提供可能？让我们大家一起拭目以待。

---

- 相关阅读 -

点击［阅读原文］可到ThoughtWorks官网查看原文和后续文章内容&绿字部分。

本文版权属ThoughtWorks公司所有，如需转载请在后台留言联系。