當我們討論Microservices架構時，我們通常會和Monolithic架構(單體架構 )進行比較。

在Monolithic架構中，一個簡單的應用會隨著功能的增加、時間的推移變得越來越龐大。當Monoltithic App變成一個龐然大物，就沒有人能夠完全理解它究竟做了什么。此時無論是添加新功能，還是修復Bug，都是一個非常痛苦、異常耗時的過程。

Microservices架構漸漸被許多公司采用(Amazon、eBay、Netflix)，用于解決Monolithic架構帶來的問題。

其思路是將應用分解為小的、可以相互組合的Microservices。這些Microservices通過輕量級的機制進行交互，通常會采用基于HTTP協(xié)議的服務。

每個Microservices完成一個獨立的業(yè)務邏輯，它可以是一個HTTP API服務，提供給其他服務或者客戶端使用。也可以是一個ETL服務，用于完成數(shù)據(jù)遷移工作。每個Microservices除了在業(yè)務獨立外，也會有自己獨立的運行環(huán)境，獨立的開發(fā)、部署流程。

這種獨立性給服務的部署和運營帶來很大的挑戰(zhàn)。因此持續(xù)部署(Continuous Deployment)是Microservices場景下一個重要的技術實踐。本文將介紹持續(xù)部署Microservices的實踐和準則。

實踐:

• 使用Docker容器化服務
• 采用Docker Compose運行測試

準則:

• 構建適合團隊的持續(xù)部署流水線
• 版本化一切
• 容器化一切 

1. 使用Docker容器化服務

我們在構建和發(fā)布服務的時候，不僅要發(fā)布服務本身，還需要為其配置服務器環(huán)境。使用Docker容器化微服務，可以讓我們不僅發(fā)布服務，同時還發(fā)布其需要的運行環(huán)境。容器化之后，我們可以基于Docker構建我們的持續(xù)部署流水線：

上圖描述了一個基于Ruby on Rails(簡稱：Rails)服務的持續(xù)部署流水線。我們用Dockerfile配置Rails項目運行所需的環(huán)境，并將Dockerfile和項目同時放在Git代碼倉庫中進行版本管理。下面Dockerfile可以描述一個Rails項目的基礎環(huán)境：

FROM ruby:2.3.3 
 
RUN apt-get update -y && \ 
    apt-get install -y libpq-dev nodejs git 
 
WORKDIR /app 
 
ADD Gemfile /app/Gemfile 
ADD Gemfile.lock /app/Gemfile.lock 
RUN bundle install 
 
ADD . /app 
 
EXPOSE 80 
 
CMD ["bin/run"] 

在持續(xù)集成服務器上會將項目代碼和Dockerfile同時下載(git clone)下來進行構建(Build Image)、單元測試(Testing)、最終發(fā)布(Publish)。此時整個構建過程都基于Docker進行，構建結果為Docker Image，并且將最終發(fā)布到Docker Registry。

在部署階段，部署機器只需要配置Docker環(huán)境，從Docker Registry上Pull Image進行部署。

在服務容器化之后，我們可以讓整套持續(xù)部署流水線只依賴Docker，并不需要為環(huán)境各異的服務進行單獨配置。

2. 使用Docker Compose運行測試

在整個持續(xù)部署流水線中，我們需要在持續(xù)集成服務器上部署服務、運行單元測試和集成測試Docker Compose為我們提供了很好的解決方案。

Docker Compose可以將多個Docker Image進行組合。在服務需要訪問數(shù)據(jù)庫時，我們可以通過Docker Compose將服務的Image和數(shù)據(jù)庫的Image組合在一起，然后使用Docker Compose在持續(xù)集成服務器上進行部署并運行測試。

上圖描述了Rails服務和Postgres數(shù)據(jù)庫的組裝過程。我們只需在項目中額外添加一個docker-compose.yml來描述組裝過程：

db: 
  image: postgres:9.4 
  ports: 
    - "5432" 
 
service: 
  build: . 
  command: ./bin/run 
  volumes: 
    - .:/app 
  ports: 
    - "3000:3000" 
 
dev: 
  extends: 
    file: docker-compose.yml 
    service: service 
  links: 
    - db 
  environment: 
    - RAILS_ENV=development 
 
ci: 
  extends: 
    file: docker-compose.yml 
    service: service 
  links: 
    - db 
  environment: 
    - RAILS_ENV=test 

采用Docker Compose運行單元測試和集成測試：

docker-compose run -rm ci bundle exec rake 

3. 構建適合團隊的持續(xù)部署流水線

當我們的代碼提交到代碼倉庫后，持續(xù)部署流水線應該能夠?qū)Ψ者M行構建、測試、并最終部署到生產(chǎn)環(huán)境。

為了讓持續(xù)部署流水線更好的服務團隊，我們通常會對持續(xù)部署流水線做一些調(diào)整，使其更好的服務于團隊的工作流程。例如下圖所示的，一個敏捷團隊的工作流程：

通常團隊會有業(yè)務分析師(BA)做需求分析，業(yè)務分析師將需求轉換成適合工作的用戶故事卡(Story Card)，開發(fā)人員(Dev)在拿到新的用戶故事卡時會先做分析，之后和業(yè)務分析師、技術主管(Tech Lead)討論需求和技術實現(xiàn)方案(Kick off)。

開發(fā)人員在開發(fā)階段會在分支(Branch)上進行開發(fā)，采用Pull Request的方式提交代碼，并且邀請他人進行代碼評審(Review)。在Pull Request被評審通過之后，分支會被合并到Master分支，此時代碼會被自動部署到測試環(huán)境(Test)。

在Microservices場景下，本地很難搭建一整套集成環(huán)境，通常測試環(huán)境具有完整的集成環(huán)境，在部署到測試環(huán)境之后，測試人員(QA)會在測試環(huán)境上進行測試。

測試完成后，測試人員會跟業(yè)務分析師、技術主管進行驗收測試(User Acceptance Test)，確認需求的實現(xiàn)和技術實現(xiàn)方案，進行驗收。驗收后的用戶故事卡會被部署到生產(chǎn)環(huán)境(Production)。

在上述團隊工作的流程下，如果持續(xù)部署流水線僅對Master分支進行打包、測試、發(fā)布，在開發(fā)階段(即：代碼還在分支)時，無法從持續(xù)集成上得到反饋，直到代碼被合并到Master并運行構建后才能得到反饋，通常會造成“本地測試成功，但是持續(xù)集成失敗”的場景。

因此，團隊對僅基于Master分支的持續(xù)部署流水線做一些改進。使其可以支持對Pull Request代碼的構建：

如上圖所示：

• 持續(xù)部署流水線區(qū)分Pull Request和Master。Pull Request上只運行單元測試，Master運行完成全部構建并自動將代碼部署到測試環(huán)境。
• 為生產(chǎn)環(huán)境部署引入手動操作，在驗收測試完成之后再手動觸發(fā)生產(chǎn)環(huán)境部署。

經(jīng)過調(diào)整后的持續(xù)部署流水線可以使團隊在開發(fā)階段快速從持續(xù)集成上得到反饋，并且對生產(chǎn)環(huán)境的部署有更好的控制。

4. 版本化一切

版本化一切，即將服務開發(fā)、部署相關的系統(tǒng)都版本化控制。我們不僅將項目代碼納入版本管理，同時將項目相關的服務、基礎設施都進行版本化管理。 對于一個服務，我們一般會為它單獨配置持續(xù)部署流水線，為它配置獨立的用于運行的基礎設施。此時會涉及兩個非常重要的技術實踐：

• 構建流水線即代碼
• 基礎設施即代碼

構建流水線即代碼。通常我們使用Jenkins或者Bamboo來搭建配置持續(xù)部署流水線，每次創(chuàng)建流水線需要手動配置，這些手動操作不易重用，并且可讀性很差，每次對流水線配置的改動并不會保存在歷史記錄中，也就是說我們無從追蹤配置的改動。

在今年上半年，團隊將所有的持續(xù)部署流水線從Bamboo遷移到了BuildKite，BuildKite對構建流水線即代碼有很好的支持。下圖描述了BuildKite的工作方式:

在BuildKite場景下，我們會在每個服務代碼庫中新增一個pipeline.yml來描述構建步驟。構建服務器(CI Service)會從項目的pipeline.yml中讀取配置，生成構建步驟。例如，我們可以使用如下代碼描述流水線：

steps: 
  - 
    name: "Run my tests" 
    command: "shared_ci_script/bin/test" 
    agents: 
      queue: test 
 
  - wait 
 
  - 
    name: "Push docker image" 
    command: "shared_ci_script/bin/docker-tag" 
    branches: "master" 
    agents: 
      queue: test 
 
  - wait 
 
  - 
    name: "Deploy To Test" 
    command: "shared_ci_script/bin/deploy" 
    branches: "master" 
    env: 
      DEPLOYMENT_ENV: test 
    agents: 
      queue: test 
 
  - block 
 
  - name: "Deploy to Production" 
    command: "shared_ci_script/bin/deploy" 
    branches: "master" 
    env: 
      DEPLOYMENT_ENV: production 
    agents: 
      queue: production 

在上述配置中，command中的步驟(即：test、docker-tag、deploy)分別是具體的構建腳本，這些腳本被放在一個公共的sharedciscript代碼庫中，sharedciscript會以git submodule的方式被引入到每個服務代碼庫中。

經(jīng)過構建流水線即代碼方式的改造，對于持續(xù)部署流水線的任何改動都會在Git中被追蹤，并且有很好的可讀性。

基礎設施即代碼。對于一個基于HTTP協(xié)議的API服務基礎設施可以是:

• 用于部署的機器
• 機器的IP和網(wǎng)絡配置
• 設備硬件監(jiān)控服務(CPU，Memory等)
• 負載均衡(Load Balancer)
• DNS服務
• AutoScaling Service(自動伸縮服務)
• Splunk日志收集
• NewRelic性能監(jiān)控
• PagerDuty報警

這些基礎設施我們可以使用代碼進行描述，AWS Cloudformation在這方面提供了很好的支持。我們可以使用AWS Cloudformation設計器或者遵循AWS Cloudformation的語法配置基礎設施。下圖為一個服務的基礎設施構件圖，圖中構建了上面提到的大部分基礎設施：

在AWS Cloudformation中，基礎設施描述代碼可以是JSON文件，也可以是YAML文件。我們將這些文件也放到項目的代碼庫中進行版本化管理。

所有對基礎設施的操作，我們都通過修改AWS Cloudformation配置進行修改，并且所有修改都應該在Git的版本化控制中。

由于我們采用代碼描述基礎設施，并且大部分服務遵循相通的部署流程和基礎設施，基礎設施代碼的相似度很高。DevOps團隊會為團隊創(chuàng)建屬于自己的部署工具來簡化基礎設施配置和部署流程。

5. 容器化一切

通常在部署服務時，我們還需要一些輔助服務，這些服務我們也將其容器化，并使用Docker運行。下圖描述了一個服務在AWS EC2 Instance上面的運行環(huán)境：

在服務部署到AWS EC2 Instance時，我們需要為日志配置收集服務，需要為服務配置Nginx反向代理。

按照12-factors原則，我們基于fluentd，采用日志流的方式處理日志。其中l(wèi)ogs-router用來分發(fā)日志、splunk-forwarder負責將日志轉發(fā)到Splunk。

在容器化一切之后，我們的服務啟動只需要依賴Docker環(huán)境，相關服務的依賴也可以通過Docker的機制運行。

總結

Microservices給業(yè)務和技術的擴展性帶來了極大的便利，同時在組織和技術層面帶來了極大的挑戰(zhàn)。由于在架構的演進過程中，會有很多新服務產(chǎn)生，持續(xù)部署是技術層面的挑戰(zhàn)之一，好的持續(xù)部署實踐和準則可以讓團隊從基礎設施抽離出來，關注與產(chǎn)生業(yè)務價值的功能實現(xiàn)。