微服務(wù)架構(gòu)的部署

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

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

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

4、r應(yīng)用到了他們的開發(fā)或者生產(chǎn)環(huán)境中了。K8s：本項目采用 Kubernates作為容器調(diào)度管理的基礎(chǔ)環(huán)境，開發(fā)環(huán)境、測試環(huán)境的 Docker容器都 由K8s負(fù)責(zé)調(diào)度管理。Jenkins :快速的部署發(fā)布離不開老牌持續(xù)集成明星Jenkins ,本項目通過Jenkins任務(wù)構(gòu)建代碼、將應(yīng)用打包成 Docker鏡像，最終發(fā)布到 K8s環(huán)境中將容器運行起來。Shell腳本：編寫Shell腳本將項目打分支、發(fā)布應(yīng)用等開發(fā)階段的配置管理工作自動化，降低運維 門檻、提高配置管理和運維的效率。WIKI ： Gitlib 上的 WIKI功能相對簡陋，因此項目組選擇dokuwiki作為異地團(tuán)隊協(xié)作和溝通的工具團(tuán)隊

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

6、的因素。通俗的說，就是有了工具，大家要知道怎么使用工具，并且愿意使用工具 才能真正達(dá)到提高研發(fā)效率的目的。項目組的主要工作成員無非也是做開發(fā)、測試和系統(tǒng)管理三類工作，這里只說明與傳統(tǒng)的企業(yè)應(yīng)用開 發(fā)過程中三類人員所做的工作略有不同的工作內(nèi)容。開發(fā)人員：a）開發(fā)者做開發(fā)設(shè)計，需要將涉及到接口部分設(shè)計更新到wiki上，供調(diào)用者評審和調(diào)用。b）開發(fā)者除了編寫程序邏輯外，還需要注意編寫單元測試用例，因為分布式應(yīng)用聯(lián)調(diào)相對復(fù)雜，先 做在編寫單服務(wù)時做好了測試再聯(lián)調(diào)能夠提高開發(fā)效率。c）由于本項目是采用 Docker容器作為發(fā)布載體的，開發(fā)者可能需要修改DockerFile 模板里的部分參數(shù)，便于部署階段

7、能將編譯后的代碼打包到鏡像中。相對于傳統(tǒng)的開發(fā)方式，這是對開發(fā)者額外的要求。讓所有開發(fā)者懂 Dockerfile 似乎要求也有點高，其實每個子項目中的 DockerFile 及腳本一般是在搭建項 目框架時，主要系統(tǒng)配置管理員編寫的好的模板，若開發(fā)人員不懂相關(guān)技術(shù)，也可以跟配置管理員溝通需 求，由配置管理員修改相關(guān)文件。測試人員：測試人員的工作沒有什么特別，只是需要注意除了每個Sprint階段的測試外，還需要配合開發(fā)人員持續(xù)集成的測試；系統(tǒng)配置管理人員：一般DevOps的開發(fā)方式是依賴于云基礎(chǔ)平臺以及自動化發(fā)布工具的，因此相對于傳統(tǒng)開發(fā)方式，對系統(tǒng)配置管理者的技術(shù)要求會比較低。但是，我們的項目開

8、發(fā)目的就是構(gòu)建一個能支 撐DevOps流程的平臺，其開發(fā)本身還不具備相應(yīng)的平臺基礎(chǔ)。因此，我們項目最初的系統(tǒng)配置管理工作 是由架構(gòu)師來做的，主要需要做如下這些事：a）部署運行項目組開發(fā)需要用到公共的服務(wù)組件、例如 zookeeper注冊中心、Docker Registry鏡像 倉庫、數(shù)據(jù)庫等；b）為子項目編寫在 git上打分支的腳本，便于測試發(fā)版的時候打分支；c）編寫各類型應(yīng)用發(fā)布部署成鏡像的Dockerfiled）制作或者在網(wǎng)上找到現(xiàn)成的開發(fā)所需環(huán)境的Docker鏡像，并且Push到項目開發(fā)使用的私有鏡像庫中；e）編寫Shell腳本實現(xiàn)將子項目打包成Docker鏡像，并且 Push到鏡像倉庫

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

10、上。當(dāng)測試版本穩(wěn)定后，由配置管理員將代碼合并到 Master分支中。自動部署和發(fā)布：項目借助于 Shell腳本、Dockerfile 、K8s配置文件和Jenkins任務(wù)實現(xiàn)了自動化的持續(xù)集成和部署。配置管理員在項目目錄下編寫的腳本文件結(jié)構(gòu)如圖2所示。a）創(chuàng)建分支的shell腳本，示例見附件 1；#!/bin/bashif -z $1 ; thencat EOFUsage:EOFexit 1fiDEPLOY_VERSION=$1RP_FILES=(subproject1/ subprojectl/ subprojectl/Makefile)if -z $(git branch -a | gre

11、p -e /$DEPLOY_VERSION$) ; thengit commit -a -m Create Branch $DEPLOY_VERSIONgit push origin $DEPLOY_VERSIONDockerfile示例文件，將 Java dubbo服務(wù)發(fā)布為鏡像為例，示例見附件2：MAINTAINER zhangsanRUN mkdir -p /app ?COPY target/ /app/COPY ./ /app/RUN chmod +x /app/WORKDIR /appCMD ./EXPOSE 8080Makefile 文件：包括編譯項目、將項目打包成Docker鏡像

12、、將鏡像 Push到鏡像倉庫、在K8s上創(chuàng)建 ReplicationController 、在 K8s上創(chuàng)建service 的命令腳本：clean:mvn clean#各當(dāng)前程序打包成 Docker鏡像build: ?docker build -t $(IMAGE).#1各當(dāng)前鏡像Push到鏡像倉庫push: ?docker push $(IMAGE)run:redeploy:kubectl replace -f $(KUBE_OPS)undeploy:kubectl delete -f $(KUBE_OPS)船J建 servicedeploy-svc:kubectl create -f $(

13、KUBE_OPS)undeploy-svc:kubectl delete -f $(KUBE_OPS)K8s部署配置文件，創(chuàng)建 ReplicationController 、創(chuàng)建service 示例見附件4：#創(chuàng)建 Service apiVersion: v1 kind: Service metadata:name: subproject1 labels:component: subproject1 spec:ports:-port: 8888 nodePort: 16888 selector:name: svc-subproject1 type: NodePore)配置管理員在 Jenkin

14、s上配置自動或手動觸發(fā)的任務(wù)，在 jenkins任務(wù)中配置shell腳本，可實 現(xiàn)應(yīng)用的一鍵部署，示例見附件5。具體的過程說如下:.從Git上拉取代碼，編譯、發(fā)布項目；將編譯好的程序包，打包成 Docker鏡像；將打包好的Docker鏡彳象Push到鏡像倉庫；Jenkins 執(zhí)行Shell腳本命令，從鏡像倉庫拉取鏡像在K8s環(huán)境中創(chuàng)建pod和RG將應(yīng)用程序及其運行環(huán)境所在的容器在K8s平臺上運行起來。測試與發(fā)版:從圖中可以看到，項目的開發(fā)環(huán)境和測試環(huán)境是相互隔離的兩套環(huán)境。a）部署在開發(fā)環(huán)境的應(yīng)用代碼，來自 develop分支，對應(yīng)的Docker鏡彳象Tag用latest ,供開發(fā)人員 調(diào)試、

15、以及測試人員隨時協(xié)助做集成測試；b）部署在測是環(huán)境的應(yīng)用代碼，來自每到一個 Sprint階段發(fā)版測試時配置管理員從develop分支中打出的測試發(fā)版分支，分支名對應(yīng)的版本號不同，相應(yīng)的 Docker鏡像的tag也會隨是版本號改變。測試 環(huán)境中部署的應(yīng)用主要用于測試驗證。部署聯(lián)調(diào):項目分為四層：前端 UI、WEB!有若干個web應(yīng)用、Service層包括若干個分布式服務(wù)、基礎(chǔ)底層。這里簡要說明一下各層之間的調(diào)試方式：a）前端和 Web層聯(lián)調(diào)：前端開發(fā)人員本地啟動一個Nginx，配置文件將localhost 代理指向web server的地址，即可在本地調(diào)試與動態(tài)Web端的交互。b） WEB層與服

16、務(wù)層聯(lián)調(diào)、服務(wù)層之間聯(lián)調(diào)、服務(wù)層與基礎(chǔ)層聯(lián)調(diào)，分為兩種方式：本地調(diào)試：部署一個專用的 zookeeper注冊中心，開發(fā)者可以把本機(jī)地址注冊到注冊中心，供相關(guān)人 員臨時調(diào)用服務(wù)調(diào)試。集成環(huán)境調(diào)試：提交代碼觸發(fā)Jenkins任務(wù)，將服務(wù)打包成容器鏡像，部署到K8s上在完整的系統(tǒng)運行環(huán)境中聯(lián)合調(diào)試。具體的集成環(huán)境編排依賴于k8s完成。微服務(wù)的分層和服務(wù)交互設(shè)計和來自 DZone community 社區(qū)的關(guān)于微服架構(gòu)的利弊以及設(shè)計原則有很多著名的文章有介紹，例如MarinFowler的博文Microservices:a definition of this new architectural ter

17、mMicroservices in Practice: From Architecture to Deployment在 InfoQ 等技術(shù)網(wǎng)站都有中文翻譯,本文就不對概念和設(shè)計原則做過多贅述。本小節(jié)主要是說明關(guān)于項目的邏輯分層結(jié)構(gòu)和服務(wù)交互方面的設(shè) 計。本項目遵守以下微服務(wù)架構(gòu)的主要基本原則，但是也會根據(jù)具體項目情況有所保留。單一責(zé)任原則（Single Responsibility Principle, SRP保證微服務(wù)設(shè)計能支持服務(wù)的敏捷/獨立地開發(fā)和部署。圖2分層結(jié)構(gòu)及通信機(jī)制架構(gòu)分層設(shè)計如圖2所示，項目的架構(gòu)是分為四層：靜態(tài) UI層、動態(tài) WEB!、業(yè)務(wù)服務(wù)層、基礎(chǔ)業(yè)務(wù)層。i.靜態(tài)UI層，直接面向用戶的操作展示界面，包括靜態(tài) UI設(shè)計和JS交互代碼，主要采用 Angulars 框架；ii.動態(tài)WEB!是