微服務(wù)架構(gòu)的部署(共10頁(yè))

1、微服務(wù)架構(gòu)的部署本文從以下幾個(gè)方面簡(jiǎn)要說(shuō)明微服務(wù)架構(gòu)項(xiàng)目的實(shí)踐經(jīng)驗(yàn)：架構(gòu)選型、開發(fā)測(cè)試環(huán)境下的相關(guān)工具支持、人員分工及開發(fā)部署流程、相關(guān)設(shè)計(jì)及注意事項(xiàng)。最后，將根據(jù)實(shí)踐經(jīng)驗(yàn)討論提高微服架構(gòu)下的開發(fā)和運(yùn)維效率的切實(shí)需求，進(jìn)一步理清本項(xiàng)目所實(shí)現(xiàn)的容器服務(wù)管理平臺(tái)的完善性需求。本項(xiàng)目是一個(gè)企業(yè)級(jí)的容器服務(wù)管理平臺(tái)，該平臺(tái)的功能是基于容器實(shí)現(xiàn)的應(yīng)用運(yùn)行環(huán)境管理，以及應(yīng)用開發(fā)階段的持續(xù)集成和持續(xù)發(fā)布。簡(jiǎn)單的理解該平臺(tái)的核心功能之一就是管理復(fù)雜應(yīng)用的開發(fā)和運(yùn)維環(huán)境，提高微服務(wù)架構(gòu)下的開發(fā)和運(yùn)維效率。項(xiàng)目的開發(fā)背景如下：首先，該系統(tǒng)具有典型分布式應(yīng)用系統(tǒng)特征：該平臺(tái)所運(yùn)行的服務(wù)器配置不高，例如華為RH128

2、8這類低配置服務(wù)器，允許硬件失??；系統(tǒng)平臺(tái)要求可根據(jù)實(shí)際用戶數(shù)的規(guī)模進(jìn)行伸縮部署，保證硬件資源的合理利用；由于系統(tǒng)平臺(tái)之上需要運(yùn)行若干企業(yè)應(yīng)用的開發(fā)和運(yùn)行環(huán)境，可靠性是非常重要的，不允許單點(diǎn)失效。其次，本系統(tǒng)功能復(fù)雜，從架構(gòu)的角度需要將系統(tǒng)分成多個(gè)層次和若干個(gè)子系統(tǒng)。不同的層次、子系統(tǒng)根據(jù)具體情況需要采用不同的開發(fā)語(yǔ)言，由不同的開發(fā)小組完成。第三，項(xiàng)目組成員由幾個(gè)城市的異地團(tuán)隊(duì)協(xié)同開發(fā)，統(tǒng)一的開發(fā)環(huán)境和協(xié)同工具是必不可少的。針對(duì)上述項(xiàng)目背景的考慮，本項(xiàng)目選擇基于微服務(wù)架構(gòu)進(jìn)行項(xiàng)目開發(fā)。開發(fā)、測(cè)試、部署使用到的工具集“工欲善其事、必先利其器”，借助適合的流程和相關(guān)工具集，才能提高微服務(wù)架構(gòu)下的應(yīng)

3、用開發(fā)效率。本項(xiàng)目利用DevOPs流程并選用一套相關(guān)工具集實(shí)現(xiàn)應(yīng)用開發(fā)管理，提高開發(fā)、測(cè)試、部署的效率。代碼庫(kù)：本項(xiàng)目使用分布式代碼庫(kù)Gitlab，它的功能不限于代碼倉(cāng)庫(kù)，還包括reviews(代碼審查), issue tracking(問(wèn)題跟蹤)、wiki等功能，是代碼管理和異地團(tuán)隊(duì)溝通、協(xié)作工具的首選。Docker鏡像倉(cāng)庫(kù)、Docker：本項(xiàng)目用容器貫穿整個(gè)軟件開發(fā)流程，以容器作為應(yīng)用發(fā)布的載體，應(yīng)用的開發(fā)環(huán)境和測(cè)試發(fā)版環(huán)境都運(yùn)行在Docker容器中。對(duì)于復(fù)雜的開發(fā)和運(yùn)維環(huán)境管理Docker具有先天的優(yōu)勢(shì)，目前國(guó)內(nèi)外的互聯(lián)網(wǎng)公司有大多數(shù)都已經(jīng)將Docker應(yīng)用到了他們的開發(fā)或者生產(chǎn)環(huán)境中了

4、。K8s：本項(xiàng)目采用Kubernates作為容器調(diào)度管理的基礎(chǔ)環(huán)境，開發(fā)環(huán)境、測(cè)試環(huán)境的Docker容器都由K8s負(fù)責(zé)調(diào)度管理。Jenkins：快速的部署發(fā)布離不開老牌持續(xù)集成明星Jenkins，本項(xiàng)目通過(guò)Jenkins任務(wù)構(gòu)建代碼、將應(yīng)用打包成Docker鏡像，最終發(fā)布到K8s環(huán)境中將容器運(yùn)行起來(lái)。Shell腳本：編寫Shell腳本將項(xiàng)目打分支、發(fā)布應(yīng)用等開發(fā)階段的配置管理工作自動(dòng)化，降低運(yùn)維門檻、提高配置管理和運(yùn)維的效率。WIKI：Gitlib上的WIKI功能相對(duì)簡(jiǎn)陋，因此項(xiàng)目組選擇dokuwiki作為異地團(tuán)隊(duì)協(xié)作和溝通的工具,團(tuán)隊(duì)成員可以將設(shè)計(jì)文檔、知識(shí)分享文檔、公告信息等信息可以更新到

5、wiki上，便與協(xié)同開發(fā)。禪道：為了便于開發(fā)計(jì)劃、開發(fā)任務(wù)和bug關(guān)聯(lián)起來(lái)，本項(xiàng)目使用禪道進(jìn)行開發(fā)任務(wù)和bug管理。人員分工及開發(fā)流程微服務(wù)架構(gòu)應(yīng)用的開發(fā)、部署的復(fù)雜度都是遠(yuǎn)大于單體式應(yīng)用的，靠運(yùn)維人員手工的配置管理顯然是難于應(yīng)付了。DevOps主張以自動(dòng)化任務(wù)處理方式實(shí)現(xiàn)軟件交付及基礎(chǔ)設(shè)施更新，可以說(shuō)是微服務(wù)架構(gòu)應(yīng)用開發(fā)和運(yùn)維的必要條件，本項(xiàng)目采用DevOps的理念的開發(fā)流程進(jìn)行開發(fā)。實(shí)現(xiàn)部署和運(yùn)維的自動(dòng)化需要工具，同時(shí)DevOps強(qiáng)調(diào)軟件開發(fā)者與其他IT員工及管理層間的協(xié)作與溝通，因此明確的人員分工和開發(fā)流程是與工具同樣重要的因素。通俗的說(shuō)，就是有了工具，大家要知道怎么使用工具，并且愿意使

6、用工具才能真正達(dá)到提高研發(fā)效率的目的。項(xiàng)目組的主要工作成員無(wú)非也是做開發(fā)、測(cè)試和系統(tǒng)管理三類工作，這里只說(shuō)明與傳統(tǒng)的企業(yè)應(yīng)用開發(fā)過(guò)程中三類人員所做的工作略有不同的工作內(nèi)容。開發(fā)人員：a) 開發(fā)者做開發(fā)設(shè)計(jì)，需要將涉及到接口部分設(shè)計(jì)更新到wiki上，供調(diào)用者評(píng)審和調(diào)用。b) 開發(fā)者除了編寫程序邏輯外，還需要注意編寫單元測(cè)試用例，因?yàn)榉植际綉?yīng)用聯(lián)調(diào)相對(duì)復(fù)雜，先做在編寫單服務(wù)時(shí)做好了測(cè)試再聯(lián)調(diào)能夠提高開發(fā)效率。c) 由于本項(xiàng)目是采用Docker容器作為發(fā)布載體的，開發(fā)者可能需要修改DockerFile模板里的部分參數(shù)，便于部署階段能將編譯后的代碼打包到鏡像中。相對(duì)于傳統(tǒng)的開發(fā)方式，這是對(duì)開發(fā)者額外的

7、要求。讓所有開發(fā)者懂Dockerfile似乎要求也有點(diǎn)高，其實(shí)每個(gè)子項(xiàng)目中的DockerFile及腳本一般是在搭建項(xiàng)目框架時(shí)，主要系統(tǒng)配置管理員編寫的好的模板，若開發(fā)人員不懂相關(guān)技術(shù)，也可以跟配置管理員溝通需求，由配置管理員修改相關(guān)文件。測(cè)試人員：測(cè)試人員的工作沒(méi)有什么特別，只是需要注意除了每個(gè)Sprint階段的測(cè)試外，還需要配合開發(fā)人員持續(xù)集成的測(cè)試；系統(tǒng)配置管理人員：一般DevOps的開發(fā)方式是依賴于云基礎(chǔ)平臺(tái)以及自動(dòng)化發(fā)布工具的，因此相對(duì)于傳統(tǒng)開發(fā)方式，對(duì)系統(tǒng)配置管理者的技術(shù)要求會(huì)比較低。但是，我們的項(xiàng)目開發(fā)目的就是構(gòu)建一個(gè)能支撐DevOps流程的平臺(tái)，其開發(fā)本身還不具備相應(yīng)的平臺(tái)基礎(chǔ)。

8、因此，我們項(xiàng)目最初的系統(tǒng)配置管理工作是由架構(gòu)師來(lái)做的，主要需要做如下這些事：a) 部署運(yùn)行項(xiàng)目組開發(fā)需要用到公共的服務(wù)組件、例如zookeeper注冊(cè)中心、Docker Registry鏡像倉(cāng)庫(kù)、數(shù)據(jù)庫(kù)等；b) 為子項(xiàng)目編寫在git上打分支的腳本，便于測(cè)試發(fā)版的時(shí)候打分支；c) 編寫各類型應(yīng)用發(fā)布部署成鏡像的Dockerfile；d) 制作或者在網(wǎng)上找到現(xiàn)成的開發(fā)所需環(huán)境的Docker鏡像，并且Push到項(xiàng)目開發(fā)使用的私有鏡像庫(kù)中；e) 編寫Shell腳本實(shí)現(xiàn)將子項(xiàng)目打包成Docker鏡像，并且Push到鏡像倉(cāng)庫(kù)中。f) 在Jenkins上配置自動(dòng)編譯或者部署任務(wù)，實(shí)現(xiàn)持續(xù)集成和部署。本文將對(duì)

9、項(xiàng)目的開發(fā)、部署聯(lián)調(diào)以及測(cè)試發(fā)版流程和規(guī)范做簡(jiǎn)要說(shuō)明，并提供項(xiàng)目各個(gè)階段使用到的部分自動(dòng)化腳本工具示例。圖 1 項(xiàng)目持續(xù)集成和部署流程代碼分支管理：如圖所示，在git上創(chuàng)建的每一個(gè)項(xiàng)目都需要至少建立develop和master兩個(gè)分支。開發(fā)人員只有權(quán)限把代碼提交到develop分支上，平時(shí)的持續(xù)集成和聯(lián)調(diào)都從develop分支上獲取代碼。 每個(gè)Sprint階段測(cè)試發(fā)版時(shí)，配置管理員從develop分支上創(chuàng)建一個(gè)用于測(cè)試的release分支。當(dāng)測(cè)試修改bug時(shí)，開發(fā)人員只把修改后的代碼提交到對(duì)應(yīng)的測(cè)試Release分支上。當(dāng)測(cè)試版本穩(wěn)定后，由配置管理員將代碼合并到Master分支中。自動(dòng)部署和發(fā)

10、布：項(xiàng)目借助于Shell腳本、Dockerfile、K8s配置文件和Jenkins任務(wù)實(shí)現(xiàn)了自動(dòng)化的持續(xù)集成和部署。配置管理員在項(xiàng)目目錄下編寫的腳本文件結(jié)構(gòu)如圖2所示。a) 創(chuàng)建分支的shell腳本，示例見附件1；#!/bin/bashif -z "$1" ; thencat <<EOFUsage:branch-release.sh <version>EOFexit 1fiDEPLOY_VERSION=$1RP_FILES=(subproject1/kube-rc.yaml subproject1/pom.xml subproject1/Makefi

11、le)if -z $(git branch -a | grep -e /$DEPLOY_VERSION$) ; then git branch $DEPLOY_VERSIONgit checkout $DEPLOY_VERSIONelsegit checkout $DEPLOY_VERSIONgit pullfi#替換k8s配置文件中環(huán)境指向,從開發(fā)切換到測(cè)試#替換掉pom.xml文件中的SNAPSHOT為release版本號(hào)#替換掉makefile中發(fā)布的鏡像Tag的latest為release版本號(hào)for f in $RP_FILES; dosed -i -e "s#g

12、" -e "s#<version>0.0.1-SNAPSHOT</version>#<version>$DEPLOY_VERSION-SNAPSHOT</version>#g" -e "s#latest#$DEPLOY_VERSION#g" $fdonegit commit -a -m "Create Branch $DEPLOY_VERSION"git push origin $DEPLOY_VERSIONb) Dockerfile示例文件，將Java dubbo服務(wù)發(fā)布為鏡

13、像為例，示例見附件2：FROM MAINTAINER zhangsanENV files.active="production"ENV JAVA_OPTS="-Xmx1024m"RUN mkdir -p /app COPY target/subproject1.war /app/COPY ./startup.sh /app/RUN chmod +x /app/startup.shWORKDIR /appCMD "./startup.sh"EXPOSE 8080c) Makefile文件： 包括編譯項(xiàng)目、將

14、項(xiàng)目打包成Docker鏡像、將鏡像Push到鏡像倉(cāng)庫(kù)、在K8s上創(chuàng)建ReplicationController、在K8s上創(chuàng)建service的命令腳本：IMAGE_PREFIX = COMPONENT = subproject1ifndef BUILD_TAG BUILD_TAG = latestendifIMAGE = $(IMAGE_PREFIX)$(COMPONENT):$(BUILD_TAG)ifndef KUBE_OPS KUBE_OPS = -server= -namespace=project1endifclean:mvn cleancompile: cleanmvn -U -D

15、skipTests=true -Dmaven.javadoc.skip=true package#將當(dāng)前程序打包成Docker鏡像build: docker build -t $(IMAGE) .#將當(dāng)前鏡像Push到鏡像倉(cāng)庫(kù)push: docker push $(IMAGE)run: docker run -rm -it -e files.active=application -p 8080:8080 $(IMAGE)#部署RelicationControllerdeploy:kubectl create -f kube-rc.yaml $(

16、KUBE_OPS)redeploy:kubectl replace -f kube-rc.yaml $(KUBE_OPS)undeploy:kubectl delete -f kube-rc.yaml $(KUBE_OPS)#創(chuàng)建servicedeploy-svc:kubectl create -f kube-svc.yaml $(KUBE_OPS)undeploy-svc:kubectl delete -f kube-svc.yaml $(KUBE_OPS)d) K8s部署配置文件，創(chuàng)建ReplicationController、創(chuàng)建service示例見附件4：#創(chuàng)建ReplicationC

17、ontrollerapiVersion: v1kind: ReplicationControllermetadata: name: subproject1spec: replicas: 1 selector: name: subproject1 template: metadata: labels: name: subproject1 spec: containers: - name: subproject1 image: imagePullPolicy: Always env: - name: DUBBO_REGISTRY_ADDRESS value: "kube:/zookeep

18、er:2181" - name: DUBBO_REGISTRY_REGISTER value: "true" ports: - containerPort: 8888#創(chuàng)建ServiceapiVersion: v1kind: Servicemetadata: name: subproject1 labels: component: subproject1spec: ports: - port: 8888 nodePort: 16888 selector: name: svc-subproject1 type: NodePore) 配置管理員在Jenkins上配置自

19、動(dòng)或手動(dòng)觸發(fā)的任務(wù)，在jenkins任務(wù)中配置shell腳本，可實(shí)現(xiàn)應(yīng)用的一鍵部署，示例見附件5。#!/bin/bash -eIMAGE=make compileif $build = "true" ; then echo "docker build -t $IMAGE" docker build -t $IMAGE . echo "docker push $IMAGE" docker push $IMAGEfiif $undeploy = "true" ; thenmake undeployfiif $deplo

20、y = "true" ; thenmake deployfiif $deploysvc = "true" ; thenmake deploy-svcfi具體的過(guò)程說(shuō)如下：i. 從Git上拉取代碼，編譯、發(fā)布項(xiàng)目；ii. 將編譯好的程序包，打包成Docker鏡像；iii. 將打包好的Docker鏡像Push到鏡像倉(cāng)庫(kù)；iv. Jenkins執(zhí)行Shell腳本命令，從鏡像倉(cāng)庫(kù)拉取鏡像在K8s環(huán)境中創(chuàng)建pod和RC，將應(yīng)用程序及其運(yùn)行環(huán)境所在的容器在K8s平臺(tái)上運(yùn)行起來(lái)。測(cè)試與發(fā)版：從圖中可以看到，項(xiàng)目的開發(fā)環(huán)境和測(cè)試環(huán)境是相互隔離的兩套環(huán)境。a) 部署在開發(fā)

21、環(huán)境的應(yīng)用代碼，來(lái)自develop分支，對(duì)應(yīng)的Docker鏡像Tag用latest，供開發(fā)人員調(diào)試、以及測(cè)試人員隨時(shí)協(xié)助做集成測(cè)試；b) 部署在測(cè)是環(huán)境的應(yīng)用代碼，來(lái)自每到一個(gè)Sprint階段發(fā)版測(cè)試時(shí)配置管理員從develop分支中打出的測(cè)試發(fā)版分支，分支名對(duì)應(yīng)的版本號(hào)不同，相應(yīng)的Docker鏡像的tag也會(huì)隨是版本號(hào)改變。測(cè)試環(huán)境中部署的應(yīng)用主要用于測(cè)試驗(yàn)證。部署聯(lián)調(diào)：項(xiàng)目分為四層：前端UI、WEB層有若干個(gè)web應(yīng)用、Service層包括若干個(gè)分布式服務(wù)、基礎(chǔ)底層。這里簡(jiǎn)要說(shuō)明一下各層之間的調(diào)試方式：a) 前端和Web層聯(lián)調(diào)：前端開發(fā)人員本地啟動(dòng)一個(gè)Nginx，配置nginx.conf文件將localhost代理指向web server的地址，即可在本地調(diào)試與動(dòng)態(tài)Web端的交互。b) WEB層與服務(wù)層聯(lián)調(diào)、服務(wù)層之間聯(lián)調(diào)、服務(wù)層與基礎(chǔ)層聯(lián)調(diào)，分為兩種方式：本地調(diào)試：部署一個(gè)專用的zookeeper注冊(cè)中心，開發(fā)者可以把本機(jī)地址注冊(cè)到注冊(cè)中心，供相關(guān)人員臨時(shí)調(diào)用服務(wù)調(diào)試。集成環(huán)境調(diào)試：提交代碼觸發(fā)Jenkins任務(wù)，將服務(wù)打包成容器鏡像，部署到K8s上在完整的系統(tǒng)運(yùn)行環(huán)境中聯(lián)合調(diào)試。具體的集成環(huán)境編排依賴于k8s完成。微服務(wù)的分層和服務(wù)交互設(shè)計(jì)關(guān)于微服架構(gòu)的利弊以及設(shè)計(jì)原則有很多著名的文章有介紹，例如