微服務架構(gòu)是近兩年興起的概念。在此之前，互聯(lián)網(wǎng)企業(yè)在生產(chǎn)環(huán)境的分布式系統(tǒng)中處理實際問題時就已經(jīng)實際使用了微服務架構(gòu)。例如最初的淘寶系統(tǒng)也是單體式應用，為了應對隨著用戶量增大而帶來的系統(tǒng)處理能力不足的問題，淘寶對其應用系統(tǒng)進行了一系列服務化拆分和改造，淘寶開源的Dubbo框架以及其企業(yè)內(nèi)部用的HSF框架都屬于微服務架構(gòu)的實現(xiàn)成果。

本文將從以下幾個方面簡要說明微服務架構(gòu)項目的實踐經(jīng)驗：架構(gòu)選型、開發(fā)測試環(huán)境下的相關工具支持、人員分工及開發(fā)部署流程、相關設計及注意事項。***，將根據(jù)實踐經(jīng)驗討論提高微服架構(gòu)下的開發(fā)和運維效率的切實需求，進一步理清本項目所實現(xiàn)的容器服務管理平臺的完善性需求。

項目背景及微服務架構(gòu)選型

本項目是一個企業(yè)級的容器服務管理平臺，該平臺的功能是基于容器實現(xiàn)的應用運行環(huán)境管理，以及應用開發(fā)階段的持續(xù)集成和持續(xù)發(fā)布。簡單的理解該平臺的核心功能之一就是管理復雜應用的開發(fā)和運維環(huán)境，提高微服務架構(gòu)下的開發(fā)和運維效率。項目的開發(fā)背景如下：

首先，該系統(tǒng)具有典型分布式應用系統(tǒng)特征：

該平臺所運行的服務器配置不高，例如華為RH1288這類低配置服務器，允許硬件失??；

系統(tǒng)平臺要求可根據(jù)實際用戶數(shù)的規(guī)模進行伸縮部署，保證硬件資源的合理利用；

由于系統(tǒng)平臺之上需要運行若干企業(yè)應用的開發(fā)和運行環(huán)境，可靠性是非常重要的，不允許單點失效。

其次，本系統(tǒng)功能復雜，從架構(gòu)的角度需要將系統(tǒng)分成多個層次和若干個子系統(tǒng)。不同的層次、子系統(tǒng)根據(jù)具體情況需要采用不同的開發(fā)語言，由不同的開發(fā)小組完成。

第三，項目組成員由幾個城市的異地團隊協(xié)同開發(fā)，統(tǒng)一的開發(fā)環(huán)境和協(xié)同工具是必不可少的。

針對上述項目背景的考慮，本項目選擇基于微服務架構(gòu)進行項目開發(fā)。

開發(fā)、測試、部署使用到的工具集

“工欲善其事、必先利其器”，借助適合的流程和相關工具集，才能提高微服務架構(gòu)下的應用開發(fā)效率。本項目利用DevOPs流程并選用一套相關工具集實現(xiàn)應用開發(fā)管理，提高開發(fā)、測試、部署的效率。

代碼庫：本項目使用分布式代碼庫Gitlab，它的功能不限于代碼倉庫，還包括reviews(代碼審查), issue tracking(問題跟蹤)、wiki等功能，是代碼管理和異地團隊溝通、協(xié)作工具的***。

Docker鏡像倉庫、Docker：本項目用容器貫穿整個軟件開發(fā)流程，以容器作為應用發(fā)布的載體，應用的開發(fā)環(huán)境和測試發(fā)版環(huán)境都運行在Docker容器中。對于復雜的開發(fā)和運維環(huán)境管理Docker具有先天的優(yōu)勢，目前國內(nèi)外的互聯(lián)網(wǎng)公司有大多數(shù)都已經(jīng)將Docker應用到了他們的開發(fā)或者生產(chǎn)環(huán)境中了。

K8s：本項目采用Kubernates作為容器調(diào)度管理的基礎環(huán)境，開發(fā)環(huán)境、測試環(huán)境的Docker容器都由K8s負責調(diào)度管理。

Jenkins：快速的部署發(fā)布離不開老牌持續(xù)集成明星Jenkins，本項目通過Jenkins任務構(gòu)建代碼、將應用打包成Docker鏡像，最終發(fā)布到K8s環(huán)境中將容器運行起來。

Shell腳本：編寫Shell腳本將項目打分支、發(fā)布應用等開發(fā)階段的配置管理工作自動化，降低運維門檻、提高配置管理和運維的效率。

WIKI：Gitlib上的WIKI功能相對簡陋，因此項目組選擇dokuwiki作為異地團隊協(xié)作和溝通的工具,團隊成員可以將設計文檔、知識分享文檔、公告信息等信息可以更新到wiki上，便與協(xié)同開發(fā)。

禪道：為了便于開發(fā)計劃、開發(fā)任務和bug關聯(lián)起來，本項目使用禪道進行開發(fā)任務和bug管理。

人員分工及開發(fā)流程

微服務架構(gòu)應用的開發(fā)、部署的復雜度都是遠大于單體式應用的，靠運維人員手工的配置管理顯然是難于應付了。DevOps主張以自動化任務處理方式實現(xiàn)軟件交付及基礎設施更新，可以說是微服務架構(gòu)應用開發(fā)和運維的必要條件，本項目采用DevOps的理念的開發(fā)流程進行開發(fā)。實現(xiàn)部署和運維的自動化需要工具，同時DevOps強調(diào)軟件開發(fā)者與其他IT員工及管理層間的協(xié)作與溝通，因此明確的人員分工和開發(fā)流程是與工具同樣重要的因素。通俗的說，就是有了工具，大家要知道怎么使用工具，并且愿意使用工具才能真正達到提高研發(fā)效率的目的。

項目組的主要工作成員無非也是做開發(fā)、測試和系統(tǒng)管理三類工作，這里只說明與傳統(tǒng)的企業(yè)應用開發(fā)過程中三類人員所做的工作略有不同的工作內(nèi)容。

開發(fā)人員：

a) 開發(fā)者做開發(fā)設計，需要將涉及到接口部分設計更新到wiki上，供調(diào)用者評審和調(diào)用。

b) 開發(fā)者除了編寫程序邏輯外，還需要注意編寫單元測試用例，因為分布式應用聯(lián)調(diào)相對復雜，先做在編寫單服務時做好了測試再聯(lián)調(diào)能夠提高開發(fā)效率。

c) 由于本項目是采用Docker容器作為發(fā)布載體的，開發(fā)者可能需要修改DockerFile模板里的部分參數(shù)，便于部署階段能將編譯后的代碼打包到鏡像中。相對于傳統(tǒng)的開發(fā)方式，這是對開發(fā)者額外的要求。讓所有開發(fā)者懂Dockerfile似乎要求也有點高，其實每個子項目中的DockerFile及腳本一般是在搭建項目框架時，主要系統(tǒng)配置管理員編寫的好的模板，若開發(fā)人員不懂相關技術，也可以跟配置管理員溝通需求，由配置管理員修改相關文件。

測試人員：測試人員的工作沒有什么特別，只是需要注意除了每個Sprint階段的測試外，還需要配合開發(fā)人員持續(xù)集成的測試；

系統(tǒng)配置管理人員：一般DevOps的開發(fā)方式是依賴于云基礎平臺以及自動化發(fā)布工具的，因此相對于傳統(tǒng)開發(fā)方式，對系統(tǒng)配置管理者的技術要求會比較低。但是，我們的項目開發(fā)目的就是構(gòu)建一個能支撐DevOps流程的平臺，其開發(fā)本身還不具備相應的平臺基礎。因此，我們項目最初的系統(tǒng)配置管理工作是由架構(gòu)師來做的，主要需要做如下這些事：

a) 部署運行項目組開發(fā)需要用到公共的服務組件、例如zookeeper注冊中心、Docker Registry鏡像倉庫、數(shù)據(jù)庫等；

b) 為子項目編寫在git上打分支的腳本，便于測試發(fā)版的時候打分支；

c) 編寫各類型應用發(fā)布部署成鏡像的Dockerfile；

d) 制作或者在網(wǎng)上找到現(xiàn)成的開發(fā)所需環(huán)境的Docker鏡像，并且Push到項目開發(fā)使用的私有鏡像庫中；

e) 編寫Shell腳本實現(xiàn)將子項目打包成Docker鏡像，并且Push到鏡像倉庫中。

f) 在Jenkins上配置自動編譯或者部署任務，實現(xiàn)持續(xù)集成和部署。

本文將對項目的開發(fā)、部署聯(lián)調(diào)以及測試發(fā)版流程和規(guī)范做簡要說明，并提供項目各個階段使用到的部分自動化腳本工具示例。

代碼分支管理：

如圖所示，在git上創(chuàng)建的每一個項目都需要至少建立develop和master兩個分支。開發(fā)人員只有權限把代碼提交到develop分支上，平時的持續(xù)集成和聯(lián)調(diào)都從develop分支上獲取代碼。 每個Sprint階段測試發(fā)版時，配置管理員從develop分支上創(chuàng)建一個用于測試的release分支。當測試修改bug時，開發(fā)人員只把修改后的代碼提交到對應的測試Release分支上。當測試版本穩(wěn)定后，由配置管理員將代碼合并到Master分支中。

自動部署和發(fā)布：

項目借助于Shell腳本、Dockerfile、K8s配置文件和Jenkins任務實現(xiàn)了自動化的持續(xù)集成和部署。配置管理員在項目目錄下編寫的腳本文件結(jié)構(gòu)如圖2所示。

a) 創(chuàng)建分支的shell腳本，示例見附件1；

#!/bin/bash
if [ -z "$1" ]; then
 cat <
            EOF  exit 1  fi DEPLOY_VERSION=$1 RP_FILES=(subproject1/kube-rc.yaml subproject1/pom.xml subproject1/Makefile) if [ -z $(git branch -a | grep -e /${DEPLOY_VERSION}$) ]; then   git branch ${DEPLOY_VERSION}  git checkout ${DEPLOY_VERSION}  else  git checkout ${DEPLOY_VERSION}  git pull  fi  #替換k8s配置文件中環(huán)境指向,從開發(fā)切換到測試  #替換掉pom.xml文件中的SNAPSHOT為release版本號  #替換掉makefile中發(fā)布的鏡像Tag的latest為release版本號  for f in ${RP_FILES[@]}; do  sed -i -e "s#api.devproject.com#api.testproject.com#g" \  -e "s#           0.0.1-SNAPSHOT     #           ${DEPLOY_VERSION}-SNAPSHOT     #g" \  -e "s#latest#${DEPLOY_VERSION}#g" $f  done git commit -a -m "Create Branch ${DEPLOY_VERSION}"  git push origin ${DEPLOY_VERSION}  

b) Dockerfile示例文件，將Java dubbo服務發(fā)布為鏡像為例，示例見附件2：

FROM registry.xcompany.com/java:openjdk-7-jre
MAINTAINER zhangsan
ENV spring.profiles.active="production"
 ENV JAVA_OPTS="-Xmx1024m"
RUN mkdir -p /app 
 COPY target/subproject1.war /app/
 COPY ./startup.sh /app/
 RUN chmod +x /app/startup.sh
 WORKDIR /app
 CMD ["./startup.sh"]
EXPOSE 8080

c) Makefile文件： 包括編譯項目、將項目打包成Docker鏡像、將鏡像Push到鏡像倉庫、在K8s上創(chuàng)建ReplicationController、在K8s上創(chuàng)建service的命令腳本：

IMAGE_PREFIX = registry.xcompany.com/project1/
COMPONENT = subproject1
ifndef BUILD_TAG
 BUILD_TAG = latest
endif
IMAGE = $(IMAGE_PREFIX)$(COMPONENT):$(BUILD_TAG)
ifndef KUBE_OPS
 KUBE_OPS = --server=https://api.devproject.com --namespace=project1
endif
clean:
 mvn clean
compile: clean
 mvn -U -DskipTests=true -Dmaven.javadoc.skip=true package
#將當前程序打包成Docker鏡像
 build: 
 docker build -t $(IMAGE) .
 #將當前鏡像Push到鏡像倉庫
 push: 
 docker push $(IMAGE)
run: 
 docker run --rm -it -e spring.profiles.active=application -p 8080:8080 $(IMAGE)
 #部署RelicationController
 deploy:
 kubectl create -f kube-rc.yaml $(KUBE_OPS)
redeploy:
 kubectl replace -f kube-rc.yaml $(KUBE_OPS)
undeploy:
 kubectl delete -f kube-rc.yaml $(KUBE_OPS)
 #創(chuàng)建service
 deploy-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)建ReplicationController
apiVersion: v1
kind: ReplicationController
metadata:
  name: subproject1
spec:
  replicas: 1
  selector:
    name: subproject1
  template:
    metadata:
      labels:
        name: subproject1
    spec:
      containers:
        - name: subproject1
          image: registry.xcompany.com/project1/subproject1:latest
          imagePullPolicy: Always
          env:
            - name: DUBBO_REGISTRY_ADDRESS
              value: "kube://zookeeper:2181"
            - name: DUBBO_REGISTRY_REGISTER
              value: "true"
          ports:
            - containerPort: 8888

#創(chuàng)建Service
apiVersion: v1
kind: Service
metadata: 
  name: subproject1
  labels:
    component: subproject1
spec: 
  ports:
    - port: 8888
      nodePort: 16888
  selector: 
    name: svc-subproject1
  type: NodePor

e) 配置管理員在Jenkins上配置自動或手動觸發(fā)的任務，在jenkins任務中配置shell腳本，可實現(xiàn)應用的一鍵部署，示例見附件5。

#!/bin/bash -e
IMAGE=registry.xcompay.com/project1/sub-project1:$IMAGE_VERSION
make compile
if [ $build = "true" ]; then
   echo "docker build -t $IMAGE"
   docker build -t $IMAGE .
   echo "docker push $IMAGE"
   docker push $IMAGE
fi
if [ $undeploy = "true" ]; then
	make undeploy
fi
if [ $deploy = "true" ]; then
	make deploy
fi
if [ $deploysvc = "true" ]; then
	make deploy-svc
fi

具體的過程說如下：

i. 從Git上拉取代碼，編譯、發(fā)布項目；

ii. 將編譯好的程序包，打包成Docker鏡像；

iii. 將打包好的Docker鏡像Push到鏡像倉庫；

iv. Jenkins執(zhí)行Shell腳本命令，從鏡像倉庫拉取鏡像在K8s環(huán)境中創(chuàng)建pod和RC，將應用程序及其運行環(huán)境所在的容器在K8s平臺上運行起來。

測試與發(fā)版：

從圖中可以看到，項目的開發(fā)環(huán)境和測試環(huán)境是相互隔離的兩套環(huán)境。

a) 部署在開發(fā)環(huán)境的應用代碼，來自develop分支，對應的Docker鏡像Tag用latest，供開發(fā)人員調(diào)試、以及測試人員隨時協(xié)助做集成測試；

b) 部署在測是環(huán)境的應用代碼，來自每到一個Sprint階段發(fā)版測試時配置管理員從develop分支中打出的測試發(fā)版分支，分支名對應的版本號不同，相應的Docker鏡像的tag也會隨是版本號改變。測試環(huán)境中部署的應用主要用于測試驗證。

部署聯(lián)調(diào)：

項目分為四層：前端UI、WEB層有若干個web應用、Service層包括若干個分布式服務、基礎底層。這里簡要說明一下各層之間的調(diào)試方式：

a) 前端和Web層聯(lián)調(diào)：前端開發(fā)人員本地啟動一個Nginx，配置nginx.conf文件將localhost代理指向web server的地址，即可在本地調(diào)試與動態(tài)Web端的交互。

b) WEB層與服務層聯(lián)調(diào)、服務層之間聯(lián)調(diào)、服務層與基礎層聯(lián)調(diào)，分為兩種方式：

本地調(diào)試：部署一個專用的zookeeper注冊中心，開發(fā)者可以把本機地址注冊到注冊中心，供相關人員臨時調(diào)用服務調(diào)試。

集成環(huán)境調(diào)試：提交代碼觸發(fā)Jenkins任務，將服務打包成容器鏡像，部署到K8s上在完整的系統(tǒng)運行環(huán)境中聯(lián)合調(diào)試。具體的集成環(huán)境編排依賴于k8s完成。

微服務的分層和服務交互設計

關于微服架構(gòu)的利弊以及設計原則有很多著名的文章有介紹，例如MarinFowler的博文《Microservices:a definition of this new architectural term》和來自DZone community社區(qū)的《Microservices in Practice: From Architecture to Deployment》在InfoQ等技術網(wǎng)站都有中文翻譯，本文就不對概念和設計原則做過多贅述。本小節(jié)主要是說明關于項目的邏輯分層結(jié)構(gòu)和服務交互方面的設計。

本項目遵守以下微服務架構(gòu)的主要基本原則，但是也會根據(jù)具體項目情況有所保留。

i. 單一責任原則（Single Responsibility Principle，SRP）

ii. 保證微服務設計能支持服務的敏捷/獨立地開發(fā)和部署。

架構(gòu)分層設計

如圖2所示，項目的架構(gòu)是分為四層：靜態(tài)UI層、動態(tài)WEB層、業(yè)務服務層、基礎業(yè)務層。

i. 靜態(tài)UI層，直接面向用戶的操作展示界面，包括靜態(tài)UI設計和JS交互代碼，主要采用Angulars框架；

ii.動態(tài)WEB層是各業(yè)務服務的“門面”，根據(jù)前端設計的需要調(diào)用、組裝業(yè)務服務層的API，相對來說，這一層變動的頻率較高，例如系統(tǒng)需要進行流程優(yōu)化或者前端UE改造，相應的都要變更這一層。動態(tài)WEB層采用Java Spring或者python Django框架實現(xiàn)；

iii.業(yè)務服務層，根據(jù)業(yè)務需求按照功能對基礎服務層進行擴展和包裝，采用Dubbo分布式服務框架實現(xiàn)，具體版本是當當擴展過的Dubbox，支持REST API，并且對Spring的支持升級到了3.x；

iv. 基礎服務層比較穩(wěn)定，提供一些基礎功能，采用Go語言/Ruby/Java/Python等多種語言實現(xiàn)的。

各層之間的交互通信設計

i. 各層次之間以及同一層次之間的交互主要是按照微服務架構(gòu)的設計原則，采用輕量式通信機制：REST API、Dubbo API（hessian協(xié)議）和異步消息實現(xiàn)的。

ii.但是也有些服務之間的交互是通過共享數(shù)據(jù)庫實現(xiàn)的，這一點是違背微服務架構(gòu)強調(diào)的“獨立的服務、獨立的數(shù)據(jù)庫”的原則的。本項目每個服務盡可能使用獨立的數(shù)據(jù)表，但是采用了共享的數(shù)據(jù)庫。根據(jù)具體業(yè)務場景，綜合考慮技術成本、以及耦合帶來的風險大小等因素，部分不同層次的服務之間的交互是通過數(shù)據(jù)表實現(xiàn)的。這也是從單體式應用進化到分布式應用的一個折中方案，將來若系統(tǒng)規(guī)模擴大，要拆分數(shù)據(jù)庫代價并不會很大。但是不可否認，微服務架構(gòu)下使用共享的數(shù)據(jù)庫是存在風險的，將來可能因為某些蹩腳的設計使得微服務之間的耦合性變大，導致微服務不再“微”了。