微服务容器化部署的研究

作者：付琳琳 邹素雯

来源：《计算技术与自动化》2019年第04期

摘; ;要：随着分布式系统和云计算的飞速发展，微服务和容器的应用越来越广泛，通过将微服务容器化实现自动化部署和持续集成，从而简化部署和加快开发也是企业应用的研究重点。通过对微服务特性和容器核心技术的研究，给出了微服务容器化部署的理论支持，并对几种常见的微服务部署模式进行了比较，最后着重介绍了微服务容器化部署模式的一般流程和总体设计方案，包括微服务应用的开发、容器镜像的构建、管理和容器部署编排，并给出了微服务容器镜像构建的优化方案，对企业的应用开发部署具有一定的理论参考价值。 关键词：微服务;容器;镜像;微服务部署;镜像优化

中图分类号：TP399; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; ; 文献標识码：A Research on Container Deployment of Microservices FU Lin-lin1？覮，ZOU Su-wen2

（1. Wuhan Research Institude of Posts and Telecommunications，Wuhan ，Hubei 430074，China;

2. Wuhan Fiberhome Information Integration Technology Company Limited，Wuhan，Hubei 430074，China）

Abstract：With the development of distributed systems and cloud computing，the application of micro-services and containers is becoming more and more extensive.The automated deployment and continuous integration through microservices containerization to simplify deployment and accelerate development is also the focus of enterprise researches. Based on the research of the

characteristics of microservices and the core technology of docker，this paper gives the theoretical support for the container deployment of microservices，than compares several common microservices deployment patterns. Finally，the general process and overall design scheme of microservices container deployment mode are introduced，including the development of microservices application，the construction of container image，the management and the

arrangement of container deployment. And put forward some optimization scheme for microservices container image construction，which has certain theoretical reference value for enterprise application development deployment.

Key words：microservices;docker;image;deployment of microservices;image optimization 随着计算机技术的发展，软件架构从单体到微服务，从垂直到分布式，不断的更新发展以适应不断庞大的业务需求。其中微服务架构从提出到现在一直备受企业和开发人员的关注，相关开源项目的社区也极为活跃，如何更好的进行微服务应用的业务拆分，稳定而快捷的服务

通信，使整个项目开发迭代快，稳定高可用，部署维护成本低，一直都是开发人员的研究重点，而容器等新的新技术产生，更是为微服务开发、部署、维护等过程提供了新的思路。 1; ;微服务和容器 1.1; ;微服务概述

不同于单体应用，微服务是一种将大型应用系统进行由大到小拆分的架构风格，根据业务功能将其拆分成多个相互独立的小型服务模块，各自拥有自己的数据存储系统、开发模式并独自运行，然后通过某些通信协议，如基于HTTP的RESTful API进行服务间的通讯[1]。 微服务的理念至提出到现在发展迅速，Martin Fowler还总结出了微服务架构的九大特性即服务组件化、按业务组织团队、做产品的态度、智能端点与哑管道、去中心化治理、去中心化管理数据、基础设施自动化、容错设计以及演进式设计[2]。通过对微服务特性的分析，可以得到微服务具有开发效率高，迭代周期短，扩展能力强，维护成本低的优点，但也带来了分布式系统的通信和保持数据库一致性的复杂度，增加了测试部署运维的开销。 1.2; ;容器概述

容器是一种集装箱技术，通过将应用“装”起来实现应用之间的相互隔离。Docker 是一个开源的容器引擎，在 Linux 容器（Linux Containers，LXC）技术的基础上，进一步封装了容器的一些操作接口提供给开发者管理和使用容器[4]。从本质上来说，

Docker其实是运行在宿主机上的进程，其核心技术主要是控制组（Cgroups）和命名空间（Namespace）。

Cgroups技术用来制造约束，主要提供限制资源使用，优先级控制，审计功能，挂起、恢复进程等功能[5]。Namespace技术是使得每个容器在不同硬件资源的使用方面都有自己不同的命名空间，例如如下的一些资源：内核、内存、CPU、网络、文件系统、进程等[6]，使得进程之间运行互不干扰。这种技术解决了如何确保容器使用者资源的隔离问题。

而这两个技术提供的资源分配和监控功能正好可以满足微服务的独立部署原则。综上所述，容器技术，支持微服务的快速部署。 2; ;微服务部署模式

微服务的部署模式通常可分为单主机多服务实例模式和每个主机一个实例模式[7]。 2.1; ;单主机多服务实例模式

单主机多服务实例模式是应用程序部署的传统方式，是指在一个或者多个物理主机或虚拟主机上运行多个服务实例，每个服务实例运行在主机的不同标准端口。其结构图如图1所示，每个主机上有多个服务实例。

单主机多服务模式因为共享服务器及其操作系统，资源使用率较高且部署启动较快，但服务实例之间的隔离性较差，且会导致因资源抢夺而服务崩溃的情况，同时对于不同技术语言开发的微服务，环境信息的错综复杂也会增加部署的错误风险[8]。 2.2; ;一个主机一个服务实例模式

微服务部署的另一种方式是使用一个主机一个服务实例（Service Instance per Host）模式。这种模式又可以分为两种不同形式：每个虚拟机一个服务实例模式和每个容器一个服务实例模式。

前者是將每个服务打包成一个虚拟机镜像，通过启动镜像创建一个VM虚拟机，作为一个服务实例，如Amazon EC2 AMI，这种模式也是Netflix部署视频流服务的主要方式[9]。因为每个虚拟机拥有各自的CPU和内存，所以这种模式很好的实现了服务间的资源隔离，并且其封装技术，使部署变得更加简单，甚至可以上云实现负载均衡和自动扩缩的功能，从而使应用的部署更加可靠。但这种方案资源的利用率较低。

后者则是将每个服务实例运行在一个容器中，而容器作为轻量级应用，镜像构建和运行速度极快，甚至可以在一个物理或者虚拟机上运行多个容器，在资源隔离和利用上优于前两种方式，并且可以使用容器集群管理工具类进行容器的管理，极大的简化了部署流程。 因此基于容器的部署模式是三种部署方式中相对最好的方式，下面则提出容器部署微服务的一般流程。

3; ;微服务容器化部署

3.1; ;微服务容器化部署整体流程

首先给出微服务容器化部署的一般方案设计，其流程图如图2所示。

主要分为微服务开发、微服务容器镜像构建、微服务容器镜像管理、微服务容器编排管理四个步骤。首先利用微服务框架，例如SpringCloud，进行微服务应用的开发，通过框架自带的组件机制进行服务管理，保证应用的高可用性。其次将每个微服务打包，构建容器镜像，镜像可以推送到创建的私有镜像仓库进行镜像的存储管理，每次部署时只需从仓库拉取相关的镜像，最后通过选择合适的容器编排工具，将容器运行到不同虚拟机或者物理机集群上，并对容

器间的通信和容器的启停进行配置，使不同微服务的实例在容器中运行并通信良好，并实时监控容器集群的运行状态，从而保证整个应用的正常运行。 3.2; ;微服务容器化部署流程步骤

3.1给出了容器化部署微服务的整体流程设计，可大致分为微服务开发、微服务容器镜像构建、微服务容器镜像管理、微服务容器编排管理四个步骤。下面对此四个步骤进行具体的研究分析，并给出相应的技术方案。 3.2.1; ;微服务应用开发

随着企业和开发者对微服务的不断研究，微服务开发框架层出不穷，如SpringCloud，Dubbo等，其丰富的配置管理、服务治理、断路器、智能路由、微代理、控制总线、全局锁、决策竞选、分布式回话和集群状态管理等操作为构建微服务系统提供了简单的开发模式[3]。 企业或者个人进行应用开发时，可以通过对待开发应用的分析研究，拆分业务服务，选择合适的微服务框架进行应用开发，充分利用其自带的丰富组件，如服务注册和发现、网关API、负载均衡、容错监控或其他第三方管理插件，通过简单的配置实现微服务应用的快速开发和系统管理。

3.2.2; ;微服务容器镜像构建

镜像构建是将开发的微服务生成可以运行的容器镜像。Docker中通常有两种方法来构建新镜像。第一种是通过commit命令将一个正在运行的容器提交为一个新镜像，第二种为编写Dockerfile文件，接着使用build命令构建一个容器镜像。

容器镜像实际上是类似于文件系统的分层机构，而从镜像运行容器，会在该镜像顶部加载一个可读写、初始值为空的文件系统，称为容器层[10]。当容器内发生变化时，这些变化都会标记应用到这一层，不影响下面已经存在的层，比如在容器中删除一个文件，也只是顶层标记文件删除，但文件其实依然存在并占用镜像空间，而从容器构建镜像，即方法一，本质上是把容器顶层固化，生成一个新的镜像，因此每修改一次，镜像就会多一层，镜像体积就会增大。长此以往，镜像将变得越来越臃肿。而且当此镜像变化时，依赖此镜像的子容器镜像也要随之重新构建。若没有编写自动化构建脚本，而是手工构建的，那么不可避免存在许多重复的构建工作。因此使用过程中，并不推荐使用第一种方法来构建镜像。

第二種通过Dockerfile来快速构建自定义镜像则用途广泛，其中，Dockerfile是一个文本格式的配置文件，一般分为基础镜像信息、维护者信息、镜像操作指令、容器启动时执行指令这四个部分[11]。各部分常用指令如表1所示.

通过对上述四个部分进行编写后，即完成了Dockerfile的编写，然后通过docker build命令创建镜像。该命令的执行过程是通过读取指定路径下的Dockerfile，然后将该路径下的全部内容发送给Docker服务端，由服务端来创建镜像[12]。 3.2.3; ;微服务容器镜像优化

由于微服务镜像不仅包含微服务自身的开发代码，还包括代码运行和依赖的众多环境信息，因此构建的镜像往往体积都很庞大，而过大的镜像不仅占用资源空间且每次部署拉取镜像时间都较长，而精简的Docker镜像可以减少构建时间、减少磁盘使用量、减少下载时间、提高安全性以及提升部署效率等。因此下面提出几种优化方案来减小镜像体积： 一、使用alpine版本的基础镜像

Alpine是包含了基本工具的轻量级Linux发行版，镜像大小大概只有4～5M，很多语言和框架都有基于alpine制作的基础镜像。如Java的SpringBoot应用，则有openjdk：8-jdk-alpine，openjdk：8-jre-alpine等。其中openjdk：8-jre是309MB，而openjdk：8-jre-alpine是107.8MB。可见镜像大小几乎缩减了一半多。 二、串联Dockerfile中的操作指令

Dockerfile的每条指令都会产生一个文件层，因此我们可以通过运算符&&和＼来实现指令的合并，最大化利用缓存减小镜像体积。通过实验发现镜像体积得到了有效的缩减。 3.2.4; ;微服务容器镜像管理

至此，微服务容器镜像已经构建成功，但往往一个完整的应用系统包括不止一个微服务，即对应着多个镜像，因此还需要对构建的容器镜像进行相应的存储管理。DockerHub是Docker官方认证的DockerRegistry，上面不仅存放着许多常用的优秀镜像，还提供认证、工作组结构、工作流工具、构建触发器等工具来简化工作[13]。

因此，对于每一个为服务应用，首先在Docker Hub 上创建相应的私有仓库，然后将应用下所有微服务构建好的容器镜像推送到仓库内，进行存储和管理。同时可以随时随地拉取相应的镜像，搭建新的开发、测试环境。 3.2.5; ;微服务容器编排

通常拉取镜像进行容器启动后，该微服务就会运行到新创建的容器进程中。由于应用包括多个微服务容器，容器的启动顺序、运行容器间的通信，容器实例的运行状态都需要配置和管理，若都人工配置和操作，不免增加了许多部署人员和维护人员的工作量和复杂度，因此需要选用容器编排工具进行容器的管理和调度。

随着容器的应用越来越多，容器编排和集群管理工具也层出不穷，如Docker Compose，DockerSwarm和Kubernetes。其中DockerCompose操作最容易，只需要编写一个文件，即docker-compose.yml，在此文件中定义应用程序的服务、声明好要启动的容器，配置一些参数，然后运行docker-composeup指令便可，但是需要注意到，Docker-Compose只能管理当前主机上的Docker，并不能跨主机去启动其他主机上的Docker容器[14]。

然而现在很多应用服务，比如云应用产品，往往都是多主机集群，这种情况Compose就不再适用，DockerSwarm和Kubernetes作为容器集群管理工具，就能发挥各自的特长。其中Kubernetes是Google的一个开源项目，基于其多年大规模容器管理技术，具有完备的集群管理能力，包括透明的服务注册和发现机制、可扩展的资源自动调度机制、强大的故障发现和自我修复能力、多粒度的资源管理能力、负载均衡，涵盖了包括开发部署测试运维监控在内的多个环节[15]。可实现大规模、分布式、高可用的 Docker 集群。

因此，要依据项目的大小和适用场景，选择合适的容器管理工具，通过配置文件的编写，进行微服务容器的部署和管理，使微服务实例正常运行于各自的容器中并保持良好的交互，从而使整个系统应用正常运行，完成微服务的容器化部署。 4; ;结; ;论

容器化部署作为微服务的理想选择，单个容器不需要托管一个完整的应用，只需要托管应用程序中的一部分--一个微服务。通过使用容器技术，部署多个微服务的工作将变得更为简便，简单的微服务部署可直接通过 docker 命令即可实现，省掉了繁琐的环境搭建、依赖管理等。对于大型应用，也可利用各种编排工具实现一键部署。在服务隔离、升/降级等方面具有相当的优势。在开发阶段，容器化也是 DevOps 的最佳搭档，通过自动化部署、持续集成等手段，可以有效降低集成成本，降低 bug 率。同时，也可保证始终有可用的版本，且各个版本都可测试，可追溯，可回滚。容器化部署微服务已经在企业开发部署应用中扮演了重要的角色。 参考文献

[1]; ; FOWLER M.Microservice[EB/OL]. http：//martinfowler.com/articles/microservices.html，2014.

[2]; ; YU Y. A microservice based reference architecture model in the context of enterprise architecture[A]. Proceedings of 2016 IEEE Advanced Information Management，Communicates，Electronic and Automation Control Conference（IMCEC 2016）[C]. IEEE Beijing Section、Global Union Academy of Science and Technology、Chongqing Global Union Academy of Science and Technology，2016：5.

[3]; ; 王方旭.基于Spring Cloud和Docker的微服務架构设计[J].中国信息化，2018（03）：53—55.

[4]; ; 杨保华，戴玉剑，曹亚仑.Docker技术入门与实践[M].北京：机械工业出版社，2014. [5]; ;Redhat. Introduction to control groups[EB/OL].https：

//access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/ Resource_Management_Guide/ch01.html，2016.

[6]; ;Linux.Namespace[EB/OL]. http：//man7.org/linux/man—pages/man7/namespaces.7.html，2016.

[7]; ; 谭一鸣. 基于微服务架构的平台化服务框架的设计与实现[D]. 北京：北京交通大学，2017.

[8]; ; 刘辉军，刘培锋，邱钰锋，等. 基于开源框架及容器技术的微服务架构研究[J].电力信息与通信技术，2018，16（06）：90—94.

[9]; ; 刘鹏. 云计算[M]. 北京：电子工业出版社，2011.

[10]; 马雄. 基于微服务架构的系统设计与开发[D]. 南京：南京邮电大学，2017.

[11]; 李红健.微服务架构和容器技术应用分析[J]. 无线互联科技，2018，15（08）：134—135.

[12]; 李苏璇.基于微服务架构的SaaS应用构建方法研究[D]. 广州：华南理工大学 2016. [13]; 周立. SpringCloud与Docker微服务架构实战[M].北京：电子工业出版社，2017. [14]; MARKUS L. Docker compose for the simple deployment of an integrated drug target screening platform[J]. Journal of Integrative Bioinformatics，2017，14（2）：98—102.