付琳琳 鄒素雯

摘? ?要：隨著分布式系統(tǒng)和云計(jì)算的飛速發(fā)展，微服務(wù)和容器的應(yīng)用越來(lái)越廣泛，通過(guò)將微服務(wù)容器化實(shí)現(xiàn)自動(dòng)化部署和持續(xù)集成，從而簡(jiǎn)化部署和加快開(kāi)發(fā)也是企業(yè)應(yīng)用的研究重點(diǎn)。通過(guò)對(duì)微服務(wù)特性和容器核心技術(shù)的研究，給出了微服務(wù)容器化部署的理論支持，并對(duì)幾種常見(jiàn)的微服務(wù)部署模式進(jìn)行了比較，最后著重介紹了微服務(wù)容器化部署模式的一般流程和總體設(shè)計(jì)方案，包括微服務(wù)應(yīng)用的開(kāi)發(fā)、容器鏡像的構(gòu)建、管理和容器部署編排，并給出了微服務(wù)容器鏡像構(gòu)建的優(yōu)化方案，對(duì)企業(yè)的應(yīng)用開(kāi)發(fā)部署具有一定的理論參考價(jià)值。

關(guān)鍵詞：微服務(wù);容器;鏡像;微服務(wù)部署;鏡像優(yōu)化

中圖分類(lèi)號(hào)：TP399? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? 文獻(xiàn)標(biāo)識(shí)碼：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

隨著計(jì)算機(jī)技術(shù)的發(fā)展，軟件架構(gòu)從單體到微服務(wù)，從垂直到分布式，不斷的更新發(fā)展以適應(yīng)不斷龐大的業(yè)務(wù)需求。其中微服務(wù)架構(gòu)從提出到現(xiàn)在一直備受企業(yè)和開(kāi)發(fā)人員的關(guān)注，相關(guān)開(kāi)源項(xiàng)目的社區(qū)也極為活躍，如何更好的進(jìn)行微服務(wù)應(yīng)用的業(yè)務(wù)拆分，穩(wěn)定而快捷的服務(wù)通信，使整個(gè)項(xiàng)目開(kāi)發(fā)迭代快，穩(wěn)定高可用，部署維護(hù)成本低，一直都是開(kāi)發(fā)人員的研究重點(diǎn)，而容器等新的新技術(shù)產(chǎn)生，更是為微服務(wù)開(kāi)發(fā)、部署、維護(hù)等過(guò)程提供了新的思路。

1? ?微服務(wù)和容器

1.1? ?微服務(wù)概述

不同于單體應(yīng)用，微服務(wù)是一種將大型應(yīng)用系統(tǒng)進(jìn)行由大到小拆分的架構(gòu)風(fēng)格，根據(jù)業(yè)務(wù)功能將其拆分成多個(gè)相互獨(dú)立的小型服務(wù)模塊，各自擁有自己的數(shù)據(jù)存儲(chǔ)系統(tǒng)、開(kāi)發(fā)模式并獨(dú)自運(yùn)行，然后通過(guò)某些通信協(xié)議，如基于HTTP的RESTful API進(jìn)行服務(wù)間的通訊[1]。

微服務(wù)的理念至提出到現(xiàn)在發(fā)展迅速，Martin Fowler還總結(jié)出了微服務(wù)架構(gòu)的九大特性即服務(wù)組件化、按業(yè)務(wù)組織團(tuán)隊(duì)、做產(chǎn)品的態(tài)度、智能端點(diǎn)與啞管道、去中心化治理、去中心化管理數(shù)據(jù)、基礎(chǔ)設(shè)施自動(dòng)化、容錯(cuò)設(shè)計(jì)以及演進(jìn)式設(shè)計(jì)[2]。通過(guò)對(duì)微服務(wù)特性的分析，可以得到微服務(wù)具有開(kāi)發(fā)效率高，迭代周期短，擴(kuò)展能力強(qiáng)，維護(hù)成本低的優(yōu)點(diǎn)，但也帶來(lái)了分布式系統(tǒng)的通信和保持?jǐn)?shù)據(jù)庫(kù)一致性的復(fù)雜度，增加了測(cè)試部署運(yùn)維的開(kāi)銷(xiāo)。

1.2? ?容器概述

容器是一種集裝箱技術(shù)，通過(guò)將應(yīng)用“裝”起來(lái)實(shí)現(xiàn)應(yīng)用之間的相互隔離。Docker 是一個(gè)開(kāi)源的容器引擎，在 Linux 容器（Linux Containers，LXC）技術(shù)的基礎(chǔ)上，進(jìn)一步封裝了容器的一些操作接口提供給開(kāi)發(fā)者管理和使用容器[4]。從本質(zhì)上來(lái)說(shuō)，

Docker其實(shí)是運(yùn)行在宿主機(jī)上的進(jìn)程，其核心技術(shù)主要是控制組（Cgroups）和命名空間（Namespace）。

Cgroups技術(shù)用來(lái)制造約束，主要提供限制資源使用，優(yōu)先級(jí)控制，審計(jì)功能，掛起、恢復(fù)進(jìn)程等功能[5]。Namespace技術(shù)是使得每個(gè)容器在不同硬件資源的使用方面都有自己不同的命名空間，例如如下的一些資源：內(nèi)核、內(nèi)存、CPU、網(wǎng)絡(luò)、文件系統(tǒng)、進(jìn)程等[6]，使得進(jìn)程之間運(yùn)行互不干擾。這種技術(shù)解決了如何確保容器使用者資源的隔離問(wèn)題。

而這兩個(gè)技術(shù)提供的資源分配和監(jiān)控功能正好可以滿足微服務(wù)的獨(dú)立部署原則。綜上所述，容器技術(shù)，支持微服務(wù)的快速部署。

2? ?微服務(wù)部署模式

微服務(wù)的部署模式通?？煞譃閱沃鳈C(jī)多服務(wù)實(shí)例模式和每個(gè)主機(jī)一個(gè)實(shí)例模式[7]。

2.1? ?單主機(jī)多服務(wù)實(shí)例模式

單主機(jī)多服務(wù)實(shí)例模式是應(yīng)用程序部署的傳統(tǒng)方式，是指在一個(gè)或者多個(gè)物理主機(jī)或虛擬主機(jī)上運(yùn)行多個(gè)服務(wù)實(shí)例，每個(gè)服務(wù)實(shí)例運(yùn)行在主機(jī)的不同標(biāo)準(zhǔn)端口。其結(jié)構(gòu)圖如圖1所示，每個(gè)主機(jī)上有多個(gè)服務(wù)實(shí)例。

單主機(jī)多服務(wù)模式因?yàn)楣蚕矸?wù)器及其操作系統(tǒng)，資源使用率較高且部署啟動(dòng)較快，但服務(wù)實(shí)例之間的隔離性較差，且會(huì)導(dǎo)致因資源搶奪而服務(wù)崩潰的情況，同時(shí)對(duì)于不同技術(shù)語(yǔ)言開(kāi)發(fā)的微服務(wù)，環(huán)境信息的錯(cuò)綜復(fù)雜也會(huì)增加部署的錯(cuò)誤風(fēng)險(xiǎn)[8]。

2.2? ?一個(gè)主機(jī)一個(gè)服務(wù)實(shí)例模式

微服務(wù)部署的另一種方式是使用一個(gè)主機(jī)一個(gè)服務(wù)實(shí)例（Service Instance per Host）模式。這種模式又可以分為兩種不同形式：每個(gè)虛擬機(jī)一個(gè)服務(wù)實(shí)例模式和每個(gè)容器一個(gè)服務(wù)實(shí)例模式。

前者是將每個(gè)服務(wù)打包成一個(gè)虛擬機(jī)鏡像，通過(guò)啟動(dòng)鏡像創(chuàng)建一個(gè)VM虛擬機(jī)，作為一個(gè)服務(wù)實(shí)例，如Amazon EC2 AMI，這種模式也是Netflix部署視頻流服務(wù)的主要方式[9]。因?yàn)槊總€(gè)虛擬機(jī)擁有各自的CPU和內(nèi)存，所以這種模式很好的實(shí)現(xiàn)了服務(wù)間的資源隔離，并且其封裝技術(shù)，使部署變得更加簡(jiǎn)單，甚至可以上云實(shí)現(xiàn)負(fù)載均衡和自動(dòng)擴(kuò)縮的功能，從而使應(yīng)用的部署更加可靠。但這種方案資源的利用率較低。

后者則是將每個(gè)服務(wù)實(shí)例運(yùn)行在一個(gè)容器中，而容器作為輕量級(jí)應(yīng)用，鏡像構(gòu)建和運(yùn)行速度極快，甚至可以在一個(gè)物理或者虛擬機(jī)上運(yùn)行多個(gè)容器，在資源隔離和利用上優(yōu)于前兩種方式，并且可以使用容器集群管理工具類(lèi)進(jìn)行容器的管理，極大的簡(jiǎn)化了部署流程。

因此基于容器的部署模式是三種部署方式中相對(duì)最好的方式，下面則提出容器部署微服務(wù)的一般流程。

3? ?微服務(wù)容器化部署

3.1? ?微服務(wù)容器化部署整體流程

首先給出微服務(wù)容器化部署的一般方案設(shè)計(jì)，其流程圖如圖2所示。

主要分為微服務(wù)開(kāi)發(fā)、微服務(wù)容器鏡像構(gòu)建、微服務(wù)容器鏡像管理、微服務(wù)容器編排管理四個(gè)步驟。首先利用微服務(wù)框架，例如SpringCloud，進(jìn)行微服務(wù)應(yīng)用的開(kāi)發(fā)，通過(guò)框架自帶的組件機(jī)制進(jìn)行服務(wù)管理，保證應(yīng)用的高可用性。其次將每個(gè)微服務(wù)打包，構(gòu)建容器鏡像，鏡像可以推送到創(chuàng)建的私有鏡像倉(cāng)庫(kù)進(jìn)行鏡像的存儲(chǔ)管理，每次部署時(shí)只需從倉(cāng)庫(kù)拉取相關(guān)的鏡像，最后通過(guò)選擇合適的容器編排工具，將容器運(yùn)行到不同虛擬機(jī)或者物理機(jī)集群上，并對(duì)容器間的通信和容器的啟停進(jìn)行配置，使不同微服務(wù)的實(shí)例在容器中運(yùn)行并通信良好，并實(shí)時(shí)監(jiān)控容器集群的運(yùn)行狀態(tài)，從而保證整個(gè)應(yīng)用的正常運(yùn)行。

3.2? ?微服務(wù)容器化部署流程步驟

3.1給出了容器化部署微服務(wù)的整體流程設(shè)計(jì)，可大致分為微服務(wù)開(kāi)發(fā)、微服務(wù)容器鏡像構(gòu)建、微服務(wù)容器鏡像管理、微服務(wù)容器編排管理四個(gè)步驟。下面對(duì)此四個(gè)步驟進(jìn)行具體的研究分析，并給出相應(yīng)的技術(shù)方案。

3.2.1? ?微服務(wù)應(yīng)用開(kāi)發(fā)

隨著企業(yè)和開(kāi)發(fā)者對(duì)微服務(wù)的不斷研究，微服務(wù)開(kāi)發(fā)框架層出不窮，如SpringCloud，Dubbo等，其豐富的配置管理、服務(wù)治理、斷路器、智能路由、微代理、控制總線、全局鎖、決策競(jìng)選、分布式回話和集群狀態(tài)管理等操作為構(gòu)建微服務(wù)系統(tǒng)提供了簡(jiǎn)單的開(kāi)發(fā)模式[3]。

企業(yè)或者個(gè)人進(jìn)行應(yīng)用開(kāi)發(fā)時(shí)，可以通過(guò)對(duì)待開(kāi)發(fā)應(yīng)用的分析研究，拆分業(yè)務(wù)服務(wù)，選擇合適的微服務(wù)框架進(jìn)行應(yīng)用開(kāi)發(fā)，充分利用其自帶的豐富組件，如服務(wù)注冊(cè)和發(fā)現(xiàn)、網(wǎng)關(guān)API、負(fù)載均衡、容錯(cuò)監(jiān)控或其他第三方管理插件，通過(guò)簡(jiǎn)單的配置實(shí)現(xiàn)微服務(wù)應(yīng)用的快速開(kāi)發(fā)和系統(tǒng)管理。

3.2.2? ?微服務(wù)容器鏡像構(gòu)建

鏡像構(gòu)建是將開(kāi)發(fā)的微服務(wù)生成可以運(yùn)行的容器鏡像。Docker中通常有兩種方法來(lái)構(gòu)建新鏡像。第一種是通過(guò)commit命令將一個(gè)正在運(yùn)行的容器提交為一個(gè)新鏡像，第二種為編寫(xiě)Dockerfile文件，接著使用build命令構(gòu)建一個(gè)容器鏡像。

容器鏡像實(shí)際上是類(lèi)似于文件系統(tǒng)的分層機(jī)構(gòu)，而從鏡像運(yùn)行容器，會(huì)在該鏡像頂部加載一個(gè)可讀寫(xiě)、初始值為空的文件系統(tǒng)，稱(chēng)為容器層[10]。當(dāng)容器內(nèi)發(fā)生變化時(shí)，這些變化都會(huì)標(biāo)記應(yīng)用到這一層，不影響下面已經(jīng)存在的層，比如在容器中刪除一個(gè)文件，也只是頂層標(biāo)記文件刪除，但文件其實(shí)依然存在并占用鏡像空間，而從容器構(gòu)建鏡像，即方法一，本質(zhì)上是把容器頂層固化，生成一個(gè)新的鏡像，因此每修改一次，鏡像就會(huì)多一層，鏡像體積就會(huì)增大。長(zhǎng)此以往，鏡像將變得越來(lái)越臃腫。而且當(dāng)此鏡像變化時(shí)，依賴(lài)此鏡像的子容器鏡像也要隨之重新構(gòu)建。若沒(méi)有編寫(xiě)自動(dòng)化構(gòu)建腳本，而是手工構(gòu)建的，那么不可避免存在許多重復(fù)的構(gòu)建工作。因此使用過(guò)程中，并不推薦使用第一種方法來(lái)構(gòu)建鏡像。

第二種通過(guò)Dockerfile來(lái)快速構(gòu)建自定義鏡像則用途廣泛，其中，Dockerfile是一個(gè)文本格式的配置文件，一般分為基礎(chǔ)鏡像信息、維護(hù)者信息、鏡像操作指令、容器啟動(dòng)時(shí)執(zhí)行指令這四個(gè)部分[11]。各部分常用指令如表1所示.

通過(guò)對(duì)上述四個(gè)部分進(jìn)行編寫(xiě)后，即完成了Dockerfile的編寫(xiě)，然后通過(guò)docker build命令創(chuàng)建鏡像。該命令的執(zhí)行過(guò)程是通過(guò)讀取指定路徑下的Dockerfile，然后將該路徑下的全部?jī)?nèi)容發(fā)送給Docker服務(wù)端，由服務(wù)端來(lái)創(chuàng)建鏡像[12]。

3.2.3? ?微服務(wù)容器鏡像優(yōu)化

由于微服務(wù)鏡像不僅包含微服務(wù)自身的開(kāi)發(fā)代碼，還包括代碼運(yùn)行和依賴(lài)的眾多環(huán)境信息，因此構(gòu)建的鏡像往往體積都很龐大，而過(guò)大的鏡像不僅占用資源空間且每次部署拉取鏡像時(shí)間都較長(zhǎng)，而精簡(jiǎn)的Docker鏡像可以減少構(gòu)建時(shí)間、減少磁盤(pán)使用量、減少下載時(shí)間、提高安全性以及提升部署效率等。因此下面提出幾種優(yōu)化方案來(lái)減小鏡像體積：

一、使用alpine版本的基礎(chǔ)鏡像

Alpine是包含了基本工具的輕量級(jí)Linux發(fā)行版，鏡像大小大概只有4～5M，很多語(yǔ)言和框架都有基于alpine制作的基礎(chǔ)鏡像。如Java的SpringBoot應(yīng)用，則有openjdk：8-jdk-alpine，openjdk：8-jre-alpine等。其中openjdk：8-jre是309MB，而openjdk：8-jre-alpine是107.8MB。可見(jiàn)鏡像大小幾乎縮減了一半多。

二、串聯(lián)Dockerfile中的操作指令

Dockerfile的每條指令都會(huì)產(chǎn)生一個(gè)文件層，因此我們可以通過(guò)運(yùn)算符&&和＼來(lái)實(shí)現(xiàn)指令的合并，最大化利用緩存減小鏡像體積。通過(guò)實(shí)驗(yàn)發(fā)現(xiàn)鏡像體積得到了有效的縮減。

3.2.4? ?微服務(wù)容器鏡像管理

至此，微服務(wù)容器鏡像已經(jīng)構(gòu)建成功，但往往一個(gè)完整的應(yīng)用系統(tǒng)包括不止一個(gè)微服務(wù)，即對(duì)應(yīng)著多個(gè)鏡像，因此還需要對(duì)構(gòu)建的容器鏡像進(jìn)行相應(yīng)的存儲(chǔ)管理。DockerHub是Docker官方認(rèn)證的DockerRegistry，上面不僅存放著許多常用的優(yōu)秀鏡像，還提供認(rèn)證、工作組結(jié)構(gòu)、工作流工具、構(gòu)建觸發(fā)器等工具來(lái)簡(jiǎn)化工作[13]。

因此，對(duì)于每一個(gè)為服務(wù)應(yīng)用，首先在Docker Hub 上創(chuàng)建相應(yīng)的私有倉(cāng)庫(kù)，然后將應(yīng)用下所有微服務(wù)構(gòu)建好的容器鏡像推送到倉(cāng)庫(kù)內(nèi)，進(jìn)行存儲(chǔ)和管理。同時(shí)可以隨時(shí)隨地拉取相應(yīng)的鏡像，搭建新的開(kāi)發(fā)、測(cè)試環(huán)境。

3.2.5? ?微服務(wù)容器編排

通常拉取鏡像進(jìn)行容器啟動(dòng)后，該微服務(wù)就會(huì)運(yùn)行到新創(chuàng)建的容器進(jìn)程中。由于應(yīng)用包括多個(gè)微服務(wù)容器，容器的啟動(dòng)順序、運(yùn)行容器間的通信，容器實(shí)例的運(yùn)行狀態(tài)都需要配置和管理，若都人工配置和操作，不免增加了許多部署人員和維護(hù)人員的工作量和復(fù)雜度，因此需要選用容器編排工具進(jìn)行容器的管理和調(diào)度。

隨著容器的應(yīng)用越來(lái)越多，容器編排和集群管理工具也層出不窮，如Docker Compose，DockerSwarm和Kubernetes。其中DockerCompose操作最容易，只需要編寫(xiě)一個(gè)文件，即docker-compose.yml，在此文件中定義應(yīng)用程序的服務(wù)、聲明好要啟動(dòng)的容器，配置一些參數(shù)，然后運(yùn)行docker-composeup指令便可，但是需要注意到，Docker-Compose只能管理當(dāng)前主機(jī)上的Docker，并不能跨主機(jī)去啟動(dòng)其他主機(jī)上的Docker容器[14]。

然而現(xiàn)在很多應(yīng)用服務(wù)，比如云應(yīng)用產(chǎn)品，往往都是多主機(jī)集群，這種情況Compose就不再適用，DockerSwarm和Kubernetes作為容器集群管理工具，就能發(fā)揮各自的特長(zhǎng)。其中Kubernetes是Google的一個(gè)開(kāi)源項(xiàng)目，基于其多年大規(guī)模容器管理技術(shù)，具有完備的集群管理能力，包括透明的服務(wù)注冊(cè)和發(fā)現(xiàn)機(jī)制、可擴(kuò)展的資源自動(dòng)調(diào)度機(jī)制、強(qiáng)大的故障發(fā)現(xiàn)和自我修復(fù)能力、多粒度的資源管理能力、負(fù)載均衡，涵蓋了包括開(kāi)發(fā)部署測(cè)試運(yùn)維監(jiān)控在內(nèi)的多個(gè)環(huán)節(jié)[15]。可實(shí)現(xiàn)大規(guī)模、分布式、高可用的 Docker 集群。

因此，要依據(jù)項(xiàng)目的大小和適用場(chǎng)景，選擇合適的容器管理工具，通過(guò)配置文件的編寫(xiě)，進(jìn)行微服務(wù)容器的部署和管理，使微服務(wù)實(shí)例正常運(yùn)行于各自的容器中并保持良好的交互，從而使整個(gè)系統(tǒng)應(yīng)用正常運(yùn)行，完成微服務(wù)的容器化部署。

4? ?結(jié)? ?論

容器化部署作為微服務(wù)的理想選擇，單個(gè)容器不需要托管一個(gè)完整的應(yīng)用，只需要托管應(yīng)用程序中的一部分--一個(gè)微服務(wù)。通過(guò)使用容器技術(shù)，部署多個(gè)微服務(wù)的工作將變得更為簡(jiǎn)便，簡(jiǎn)單的微服務(wù)部署可直接通過(guò) docker 命令即可實(shí)現(xiàn)，省掉了繁瑣的環(huán)境搭建、依賴(lài)管理等。對(duì)于大型應(yīng)用，也可利用各種編排工具實(shí)現(xiàn)一鍵部署。在服務(wù)隔離、升/降級(jí)等方面具有相當(dāng)?shù)膬?yōu)勢(shì)。在開(kāi)發(fā)階段，容器化也是 DevOps 的最佳搭檔，通過(guò)自動(dòng)化部署、持續(xù)集成等手段，可以有效降低集成成本，降低 bug 率。同時(shí)，也可保證始終有可用的版本，且各個(gè)版本都可測(cè)試，可追溯，可回滾。容器化部署微服務(wù)已經(jīng)在企業(yè)開(kāi)發(fā)部署應(yīng)用中扮演了重要的角色。

參考文獻(xiàn)

[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的微服務(wù)架構(gòu)設(shè)計(jì)[J].中國(guó)信息化，2018（03）：53—55.

[4]? ? 楊保華，戴玉劍，曹亞侖.Docker技術(shù)入門(mén)與實(shí)踐[M].北京：機(jī)械工業(yè)出版社，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]? ? 譚一鳴. 基于微服務(wù)架構(gòu)的平臺(tái)化服務(wù)框架的設(shè)計(jì)與實(shí)現(xiàn)[D]. 北京：北京交通大學(xué)，2017.

[8]? ? 劉輝軍，劉培鋒，邱鈺鋒，等. 基于開(kāi)源框架及容器技術(shù)的微服務(wù)架構(gòu)研究[J].電力信息與通信技術(shù)，2018，16（06）：90—94.

[9]? ? 劉鵬. 云計(jì)算[M]. 北京：電子工業(yè)出版社，2011.

[10]? 馬雄. 基于微服務(wù)架構(gòu)的系統(tǒng)設(shè)計(jì)與開(kāi)發(fā)[D]. 南京：南京郵電大學(xué)，2017.

[11]? 李紅健.微服務(wù)架構(gòu)和容器技術(shù)應(yīng)用分析[J]. 無(wú)線互聯(lián)科技，2018，15（08）：134—135.

[12]? 李蘇璇.基于微服務(wù)架構(gòu)的SaaS應(yīng)用構(gòu)建方法研究[D]. 廣州：華南理工大學(xué) 2016.

[13]? 周立. SpringCloud與Docker微服務(wù)架構(gòu)實(shí)戰(zhàn)[M].北京：電子工業(yè)出版社，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.