【云计算】Leveraging microservices architecture by using Docker technology

在这里插入图片描述

利用Docker技术利用微服务架构

摘要

微服务体系结构并不是一种炒作，有一段时间，它开始引起组织的注意，这些组织希望通过在产品的所有生命周期中最大化自动化来提高生产力效果，从而缩短软件产品的上市时间。然而，微服务架构方法也引入了许多新的复杂性，并要求应用程序开发人员具有一定的成熟度，以便自信地应用架构风格。Docker是一种颠覆性的技术，它改变了应用程序的开发和分发方式。Docker有很多优点，非常适合实现微服务架构。在本文中，我们将以一个实际的工作模型为例，讨论Docker如何有效地帮助利用微服务体系结构。

关键字

micoservices; docker; devops; automation

1. 介绍

到目前为止，构建软件应用程序的一种常见方法是单一方法，其中一个部署单元有几个职责，在某些情况下，它主要完成所有工作。整体式方法对于小规模团队和项目仍然是很好的，但是当可扩展性、灵活性和其他要求，如快速开发、上市时间短、更广泛的团队协作等，对实现业务竞争力变得越来越重要时，整体式方法开始成为一个很大的障碍。
随着代码库越来越大，越来越复杂，越来越多的人对其进行更改，在频繁响应用户或业务模型的根本更改需求时，对应用程序进行更改要困难得多。整体方式的紧密耦合模型在本质上需要不断的努力来协调，以使任何必须有更新，从而减慢应用程序的发布周期，并进一步加剧其脆弱性。
微服务体系结构方法是一种解决整体性问题的方法。尽管理论上它应该解决大多数在单元方法中出现的问题，但是微服务也有一个很长的缺点列表，它强调开发人员需要在自动化和敏捷性方面有一定的成熟度，以便能够利用它的优势。Docker领先的集装箱化技术确实在许多用例中加速了微服务架构的应用。

2. 微服务架构

微服务是小型的自治服务，它们协同工作以满足业务需求。本节将讨论微服务体系结构中的一些基本概念和特性。

A. 小而集中

尽管“小”不是描述微服务的一个很好的度量标准，但我们可以用它来强调微服务的一个最重要的特性，即每个服务都是细粒度的、高内聚性的，专注于履行细粒度的职责。
在企业环境中，微服务的设计应该考虑到面向业务的驱动程序。这意味着产生的服务不应该模仿组织、技术或通信边界。相反，它们应该围绕特定的业务领域建模。
从开发的角度来看，每个服务都应该被视为一个独立的应用程序，有自己的源代码存储库和交付管道。

B. 松耦合

松耦合是微服务的一个基本特征。每个微服务需要根据需要进行部署，而无需与其他服务所有者进行协调。如果您有两个服务，并且总是在一个大型部署中将这两个东西放在一起，这可能是一个迹象，其中两个应该只是一个东西，而且还需要针对当前的服务分解做进一步的工作。松耦合使部署更加频繁和快速，最终提高了应用程序对用户需求的响应能力。

C. 编程语言中立

微服务需要使用开发人员最熟悉的技术来构建。开发团队不应该被使用的任何编程语言所支配，这意味着微服务体系结构在使用对任务和执行任务的人员最有意义的技术方面充分利用了自由。这使得充分利用团队所拥有的最佳技术和技能变得更加容易。
由于微服务与编程语言无关，因此它们之间的通信也通过与语言无关的应用程序编程接口（API）进行，通常是基于HTTP的资源API，如REST。下面的图1描述了一个例子，在这个例子中，可以使用各种语言和技术来构建一个典型的使用微服务方法的在线购物系统。这些服务是使用不同的编程语言和开发框架（如Java、PHP或Node.js）开发的。每个服务甚至都有自己的数据存储类型，其中Catalog服务使用Cloudant，Order服务使用SQL数据库等等。
在这里插入图片描述

D. 有界上下文

有界上下文封装单个域的详细信息，如数据模型、域模型等。它还定义了与其他有界积分点的积分。在微服务体系结构中，有一个定义良好的绑定上下文是至关重要的。这意味着域之间明确定义的边界越多，我们就越能够对服务的设计和大小进行有效的推理。有时我们有在这些边界之间共享的模型，以及只需要存在于每个边界区域内的模型。

E. 构建微服务体系结构的挑战

另一方面，除了一长串优点外，微服务架构风格还引入了一些需要解决的挑战，才能产生效益。

1）故障隔离

失败会发生，这只是时间问题，当它们确实发生在特定的服务上时，它们最好快速失败。快速的失败会导致更好的理解和解决问题。此外，我们还需要一个分而治之的concur模型，在这个模型中，我们可以将事情分成更小的部分，并使用或创建快速工具，以支持许多微小更改的连续交付，这样开发人员就可以一次更改一件事件，如果它中断了，我们知道这是唯一中断的事情。
故障设计是成功构建基于微服务系统的重要要求。

2）可观测性

构建微服务体系结构需要一种方法来可视化系统中每个服务的运行状况，以便快速定位和响应发生的任何问题。这还包括一个全面的日志记录机制，以记录、存储和搜索，以便更好地分析日志。它的挑战性远远超过了仅仅是大量的项目要添加到展望。对于所有快速移动的部分，观测设计需要有一定的意义，数据被可视化，以提供有用的信息作为分析的输入。

3）自动化要求

利用自动化的文化是列表中最重要和最具挑战性的项目。服务的数量和它们之间的关系的爆炸式增长将在某个时刻发生，可能很快，如果没有自动化的方法就无法处理。

4）高度独立

基于微服务的系统的主要原则之一是使服务高度解耦。这意味着保持服务之间的独立性是至关重要的，这样每个服务都可以独立开发、部署，而不会相互影响。

5）测试

在构建微服务体系结构时，测试是最具挑战性的项目之一。运动部件越多，故障发生的几率就越大。如何确保测试足够全面，涵盖所有方面并不容易。随着新工具和新技术的不断引入，自动化测试已经有了长足的进步。然而，如何有效地测试系统的功能和非功能方面，尤其是在分布式模型中，仍然是一个挑战。由于它们之间有更多独立的组件和协作模式，微服务体系结构甚至为测试增加了一个新的复杂程度[1]。

6）可伸缩性

尽管构建微服务体系结构的一个重要动机是解决可伸缩性问题，但可伸缩性也是微服务体系结构本身面临的一个非常严峻的挑战。在某个时候，系统中创建的micoservices数量将会激增，更不用说每个micoservices都有不同的版本，因此，它们之间的连接数量激增，这增加了基于微服务的系统的复杂性，需要制定特殊的解决方案，如服务发现，以了解哪个服务在哪里运行，路由机制，以通过服务的api路由流量，更好的配置管理可以动态地进行配置并将更改应用于系统等等。

3. Docker

Docker是一个用于快速开发、发布和运行软件应用程序的开放平台。它的目的是通过使用一个轻量级容器虚拟化平台来帮助更快地交付应用程序，该平台由一组工具和工作流包围，这些工具和工作流帮助开发人员更轻松地部署和管理应用程序[2]。
我们可以通过将Docker容器与一艘集装箱船相关联，快速了解Docker容器，在该船上装载集装箱，然后将其装运和卸载到不同的位置。Docker容器基本上是创建应用程序的地方，将它们与所有必需的依赖组件放在一起，使应用程序能够在一个加固的盒子中运行，然后根据需要对其进行任何验证或严格测试，以确保质量。盒子的创建几乎可以在任何操作系统和基础设施上完成，包括云环境，特别是由于利用了统一系统和其他技术（稍后将讨论），所以速度非常快。
下面是关于Docker技术的更多详细信息。

A. Docker架构

Docker使用客户机-服务器架构。下面的图2演示了Docker与主要组件的体系结构概述，以及它们之间的交互方式。
Docker用户使用客户端组件中的一组Docker命令，通过在主机上运行的Docker deamon与Docker主机交互。Docker deamon则负责构建、运行和分发Docker容器，并将Docker镜像发布到特定的Docker注册表。Docker客户端可以与Docker deamon运行在同一个系统上，也可以运行在不同的系统上，然后与deamon远程交互。Docker客户端组件通过套接字或一组RESTful API与Docker deamon通信。有关每个组件的详细信息，请参阅以下部分。
在这里插入图片描述

B. Docker主要组件和概念

1）Docker镜像

镜像是只读模板，Docker的一个构建组件，Docker容器从中启动。每一个镜像都以一个基本镜像开始。然后根据需要在基础部分的基础上添加其他部分，以履行镜像的业务职责。例如，一个镜像可以包含一个最小的基本CentOS操作系统，然后是一个类似于Node.js节点引擎将被添加，最后您的web应用程序将安装在上面。
有了Docker，镜像可以在本地新建，也可以从其他人创建镜像的现有远程源存储库中下载、更新。如果我们深入研究，每个镜像都由几个层组成，Docker使用union文件系统将这些层组合成一个镜像。Union文件系统（UFS）是一种针对Linux、FreeBSD和NetBSD操作系统的文件系统服务，它为其他文件系统实现了Union挂载。它允许透明地覆盖单独文件系统（称为分支）的文件和目录，形成一个单一的一致的文件系统[2]
在Docker中使用UFS有助于加速容器化技术的可移植性和轻量级特性。例如，当在中间件或应用程序更新为新版本时更改镜像时，在生成新镜像时，代替替换整个镜像或从头重建，只添加或更新关联的新层。构建完成后，您只需要分发特定的更新层，从而使分发Docker映像更轻量级，从而更快、更简单。
Docker镜像的构建是通过一组简单的、描述性的步骤来完成的，这些步骤称为指令。它从一个名为Dockerfile的特定于Docker的文件开始，其中的指令以声明方式存储。触发构建请求时，Docker读取Dockerfile以执行指令，然后返回最终镜像。每条指令在生成的镜像中创建一个新层。下面的图3描述了一个典型Dockerfile中指令的外观示例。
在这里插入图片描述

2）Docker注册表

Docker镜像通常存储在名为Docker注册表的共享存储库中。注册表是您可以从Docker客户端下载镜像或将镜像上传到Docker客户端的一组命令的地方，它使镜像的分发变得容易，并且与Docker技术的其他部分一起，它们有助于创建一种全新的分发应用程序的方式，开发人员可以拥有这些应用程序。就像处理源代码管理一样。
Docker有一个名为Docker Hub的公共注册中心，它是现有镜像的大集合，可以使用。人们可以自由地创建新的镜像并将其添加到集合中，或者根据需要在运行interprise防火墙的私有存储库上共享它们。

3）Docker容器

Docker容器是一个独立和安全的环境，它包含运行应用程序所需的所有内容，通常包括共享操作系统（Docker容器不包括客操作系统，但与其他容器共享）、必要的中间件、特定于应用程序的用户添加的文件和其他元数据。Docker容器是从Docker镜像创建的，然后可以运行、启动、停止或通过很小的努力随意移除。镜像指示Docker运行哪个进程，以及启动容器时的各种其他必要配置元数据。Docker镜像是只读的，但是当Docker从镜像运行容器时，它会使用UFS在镜像的顶部添加一个读写层，然后应用程序可以在其中运行。

4. Docker非常适合微服务

正如前一节关于微服务体系结构的讨论中所提到的，该方法确实带来了一系列需要解决的挑战，如从开发到投入生产的更高层次的复杂性、自动化在各个方面的关键需求、故障隔离、测试挑战等等。幸运的是，Docker引入了一些关键特性和工具，可以帮助解决这些挑战。让我们讨论一些突出的问题。

A. 加速自动化

Docker容器自然非常适合微服务体系结构，因为每个容器都可以用作部署单元来粒度地包含服务。由于每个容器的创建和启动都可以通过设计编写脚本，并且随着时间的推移有大量可用的工具，Docker容器在软件开发生命周期的每一步都在加速自动化文化。

B. 加速独立

每个Docker容器都是一个独立的框，可以包含特定服务的运行时环境。随着Docker支持和采用的平台越来越多，该服务的开发团队可以独立地使用他们最熟悉的技术或语言、流程和工具来实现该服务。

C. 加速可移植性

Docker将应用程序及其所有依赖项放入一个容器中，该容器可在不同平台（包括Linux发行版和云）之间移植。应用程序的不同涉众（如开发人员、测试人员、管理员等）可以在虚拟机、本地笔记本电脑、裸机服务器或云上随意快速运行相同的应用程序。这特别有助于在微服务体系结构中对特定服务进行独立的独立测试。

D. 加快资源利用

尽管它不是作为一个原则明确地写下来的，但它是轻量级的，可移植性是成为一个微服务体系结构友好环境的潜在需求。
在Docker中，每个容器只由应用程序和应用程序需要能够运行的依赖项组成，理想情况下，不多也不少。然后，容器作为主机操作系统上的独立进程运行，与其他容器共享内核。因此，如果容器被放置在VM环境中，除了利用使用虚拟机带来的资源利用效益之外，容器化技术甚至使其更具可移植性和效率。
在裸机环境中，Docker容器的轻量级特性有助于创建和运行比虚拟机更多的实例，从而提高资源利用率。

E. 安全的

Docker提供的许多功能都允许开发人员在不同级别灵活地最大化代码的安全性。在构建代码时，开发人员可以自由地使用渗透测试工具来对构建周期的任何部分进行压力测试。由于构建Docker镜像的源在Docker build，distribution组件（如Dockerfile，Docker compose文件）中有明确的声明性描述，开发者可以更容易地处理镜像供应链，并且能够根据需要强制执行安全策略。此外，通过将不可变服务放入Docker容器中，可以轻松地增强这些服务的安全性。

5. 案例研究-工作模式

作为一个示例用例，我们的团队长期以来一直使用传统的整体模型来构建应用程序。我们了解我们在开发、部署和应用程序的每个版本中所需的额外工作，在每个版本中，开发人员和操作团队之间需要进行大量的会议和协调。
我们希望在每个项目之后都能做得更好，并决定在最新的应用程序版本中采用微服务体系结构原则。Docker是我们微服务架构采用步骤中的救星。让我们讨论一下到目前为止在我们的路线图中是如何做到的。

A. 解决方案体系结构概述

我们将讨论的案例研究基本上是一个解决方案，包括一个更新的工作流、流程和一个应用程序，它可以帮助创新部门之间进行内部收费活动的方式，这在企业环境中基本上是一个典型的内部成本覆盖。
下面的图4描述了进化系统的架构概述，其中基于微服务的方法得到了最大限度地使用Docker技术（包括Docker生态系统的工具）的支持。
在这里插入图片描述

B. 工作原理

案例研究中讨论的解决方案不仅是利用Docker技术，而且在软件开发中严格遵循敏捷方法论，享受像Waffle、Github、Slack等周边工具的好处。
该系统是这样设置的，每当开发人员将一组提交推送到专用于特定服务的共享源代码存储库时，将向系统的主要利益相关者（包括系统所有者、其他开发人员、测试人员等）和订阅该组的人员组发送通知。这种可视化有助于促进不同涉众之间的参与和协作，最大限度地提高开发人员在每一行代码中的个人责任意识，并在一定程度上隔离潜在的bug。
我们使用Github中的webhooks原理在Github外设置警报，以便它能够说出某个事件何时发生。因此，一旦对变更进行了评审（包括同行评审、通过不同渠道的讨论），并将其合并到主代码流中，就会触发一组针对变更运行的自动化测试。这是通过使用Travis作为一个测试框架来实现的，这样每当接收到向主流存储库的推送时，Travis就会运行包含在相关git项目中的任何测试，并判断它们是否通过。我们使用社区证明的测试工具，如jslint、伊斯坦布尔、mocha，来实现测试活动的自动化。为了进一步确保代码的质量，设置了一个高覆盖率测试，以确保开发的每一行代码都将被扫描和测试。
所有测试通过后，将触发存储库的生成。我们构建了一个名为webhooklistener的特殊组件，它是一个集成的、基于事件的实用程序，它从github监听已配置的webhook，然后执行一系列脚本操作，比如构建docker映像、将映像推送到注册表等。
然后将为该特定存储库的服务创建一个docker镜像，其中包括适当的版本控制机制，以便我们可以跟踪镜像中的代码级别以及稍后的最终docker容器。然后，该镜像将被推送到项目的专用Docker注册表中，以便为根据需要启动Docker容器的任何Docker请求做好准备。因此，webhooklistener组件所做的不仅仅是其名称中包含的内容，而是主要集中于构建Docker镜像并将其传递到适当的镜像注册表。
特殊chageback编排项目是存储不同环境的部署脚本的地方。我们使用Docker eco系统的Docker compose工具来声明性地检测容器，以便我们可以根据需要快速复制或设置新的运行环境。这一部分还涉及到一些手动操作，当需要将应用程序的新版本部署到特定服务器时，我们需要用相应容器的版本手动更新docker compose文件，然后将其推送到专用的Github存储库。这种推送将触发webhook负载，进而启动通过webhooklistener组件的新部署。
使用当前模型，我们还可以根据需要回滚到应用程序的任何版本，只需映射docker compose文件中在特定代码级别构建的相应版本的docker容器，然后将其推回到主流专用chageback orchestrate github存储库。

C. 改进需求

尽管案例研究中的当前模型在项目不同利益相关者的高度满意下运行良好，但它仍在向更自动化、可伸缩的设计发展，特别是在自动伸缩性和可观察性方面（特别是日志记录，mornitoring）这是我们的待办事项列表中的大项目，需要在下一个即将到来的可伸缩性挑战中完成。但对于任何应用微服务体系结构的意图来说，这也是非常典型的，因为只有不断地改进才能实现。