在云的時代，應用會更多地遷移到云端，基于云的架構設計和開發模式需要一套全新的理念去承載，于是云原生思想應運而生，而針對云原生應用開發的最佳實踐原則，12-Factor脫穎而出，同時也帶來了新的解讀。本次分享將結合 Docker等技術，介紹在 Cloud Native時代下，如何一一實踐 12-Factor原則。

云原生

---

云原生（Cloud Native）是由 ?Pivotal 的 Matt Stine在 2013年提出的一個概念，是他多年的架構和咨詢總結出來的一個思想的集合。

那怎么去理解云原生應用？我覺得可以從三個角度來說明，這和云計算平臺的三個層次不謀而合，如下圖：

• IaaS看做基礎云設施，用來提供各種基礎資源 (Infrastructure)

• PaaS作為開發平臺，用來提供各種平臺服務 (Platform)

• SaaS交付應用或服務，直面用戶，提供應用價值 (Application)

云原生應用，正好契合了云、平臺和服務，一層層建構，所以我通常就把它理解為面向云（平臺）來設計我們的應用。網易三拾眾籌的架構師陳曉輝還為它起了一個小清新的名字——向云而生，我覺得非常貼切，再通俗一點講，也可以叫做云平臺應用。

?

12-Factor

---

12-Factor，是由 Heroku創始人 Adam Wiggins首次提出并開源，并由眾多經驗豐富的開發者共同完善，這綜合了他們關于 SaaS應用幾乎所有的經驗和智慧，是開發此類應用的理想實踐標準。

12-Factor 全稱叫 The Twelve-Factor App，它定義了一個優雅的互聯網應用在設計過程中，需要遵循的一些基本原則，和 Cloud-Native 有異曲同工之處。其中文翻譯不少，我覺得“十二要素”或“十二原則”比較貼切。

那具體有哪十二原則了，見下圖：

在接下來的應用和實踐當中，我們會一一實踐每條原則。

注：雖然 12-Factor 的原文書籍都是發布在其官網上，但因為網絡問題和格式問題，不是很方便閱讀，我將其轉化為了?GitBook 格式，并架設在網易云基礎服務（蜂巢）平臺上，同時開源在 GitHub 上，方便大家閱讀和下載：

在線閱讀地址：

http://12.bingohuang.com/zh_cn/index.html

GitHub 開源地址：

https://github.com/bingohuang/12factor-gitbook

pdf/epub下載地址：

https://github.com/bingohuang/12factor-gitbook/download

GitBook 地址：

https://www.gitbook.com/book/bingohuang/12factor/details

?

應用與實踐

---

既然 12-factor作為 SaaS開發的最佳實踐原則，當然脫離不了實踐，接下來我們就來設計一款云原生應用，并依照 12-factor，一步步驗證和升級我們的應用。從中，我們將講解每個 Factor的要點，以及如何在我們的應用中實踐 Factor。

?

應用準備

這是一個面向云平臺設計的簡單 Web應用，它將暴露一個 HTTP REST風格的接口，可以實現對 user 的增刪改查功能，將用到以下技術棧：

1. ?基于 Node.js，用 Node.js 寫 Web應用非常方便，而且是當今最火的編程平臺之一。

下載安裝 Node.js (包含 npm)：https://nodejs.org/zh-cn/download/

注：Node 版本只要 v4.4 以上就夠用，當前最新的穩定版是 v6.9.5, 我本地的版本是 v5.12.0

2. ?基于 Sails，類似 Rails 框架，用于快速開發 Node.js 應用：http://sailsjs.com/

安裝 Sails 框架最新版：

npm install sails -g

3. ?基于 mongo 3.2 ：https://docs.mongodb.org/manual/installation/

4. ?基于 Docker，非常契合 12-Factor理念，作為我們打包、發布、運行的工具。

安裝 Docker：https://docs.docker.com/engine/installation/

5. ?以上環境安裝好之后，就開始初始化我們的應用并運行，應用的名稱就叫：12factor-app。

$ sails new 12factor-app
? info: Created a new Sails app `12factor-app`!
$ cd 12factor-app
$ sails generate api user
? info: Created a new api!
$ npm start

注：本文源代碼放在 GitHub上，請參考文后參考鏈接

僅需 4條命令就搞定了應用的框架代碼，并自動生成了基于 user的 CRUD接口，我們已經將應用啟動起來，可以通過以下方式本地調試接口：

控制臺輸出正常，在瀏覽器中訪問下面鏈接，即可看到 Sails應用的首頁：http://localhost:1337

接著，就可以通過本地 curl命令或者 http工具來做接口調試，這里以常規的增刪改查為例：

1. 增加一個新用戶

$ curl -XPOST http://localhost:1337/user?name=bingo
{
? "name": "bingo",
? "createdAt": "2017-02-13T06:13:53.791Z",
? "updatedAt": "2017-02-13T06:13:53.791Z",
? "id": 58a41d952f53291200b9e065
}

2. 獲取用戶列表

$ curl http://localhost:1337/user
[
? {
??? "name": "bingo",
??? "createdAt": "2017-02-13T06:13:53.791Z",
??? "updatedAt": "2017-02-13T06:13:53.791Z",
??? "id": 58a41d952f53291200b9e065
? }
]

3. 修改一個用戶

curl -XPUT http://localhost:1337/user/58a41d952f53291200b9e065?name=bingohuang
{
? "name": "bingohuang",
? "createdAt": "2017-02-13T06:13:53.791Z",
? "updatedAt": "2017-02-13T06:14:13.460Z",
? "id": 58a41d952f53291200b9e065
}

4. 刪除一個用戶

curl -XDELETE http://localhost:1337/user/58a41d952f53291200b9e065

我已經將該應用部署到了網易云基礎服務（蜂巢）在線平臺，如果您對這個應用感興趣，直接將 localhost替換為 59.111.110.95，一樣可以體驗 CRUD操作，如下所示，只要把 yourname換成您的名字即可(建議在 PC端操作)：

# 注冊你自己
curl -XPOST http://59.111.110.95:1337/user?name=yourname
# 查看所有注冊過的用戶
curl http://59.111.110.95:1337/user
# 或者 PC瀏覽器直接訪問 http://59.111.110.95:1337/user

接下來開始就讓我們開始一一實踐 12-Factor中的每條原則吧，每個原則中我們將分為?Factor解說和?Factor實踐兩塊。

?

1 基準代碼

Factor解說：

12-Factor應用只有一份基準代碼（Codebase），可以多份部署（deploy）。

意思就是說一個應用只有一份用來跟蹤所有修訂版本的代碼倉庫，基準代碼和應用之間總是保持一一對應的關系，因為：

○ 一旦有多個基準代碼，就不能稱為一個應用，而是一個分布式系統。分布式系統中的每一個組件都是一個應用，每一個應用可以分別使用 12-Factor 進行開發。

○ 多個應用共享一份基準代碼是有悖于 12-Factor 原則的。解決方案是將共享的代碼拆分為獨立的類庫，然后使用依賴管理（第二個原則） 策略去加載它們。

○ 多份部署相當于是運行了該應用的多個實例，比如開發環境一個實例，測試環境、生產環境都有一個實例。

○ 一個代碼倉庫，確保了單一的信任源，從而保證了更少的配置錯誤和更強的容錯和復原能力。

Factor實踐：

使用 Git作為應用的版本管理系統，使用 GitHub我們的在線倉庫。

在剛剛創建好的應用目錄下執行：

$ echo "# 12factor-app" >> README.md
$ git init
$ git add .
$ git commit -m "first commit"
$ git remote add origin git@github.com:bingohuang/12factor-app.git
$ git push -u origin master

?

2?依賴

Factor解說：

12-Factor規則下的應用程序不會隱式依賴系統級的類庫。

意思就是說：通過依賴清單聲明所有依賴項，通過依賴隔離工具確保程序不會調用系統中存在但清單中未聲明的依賴項。并統一應用到生產和開發環境。

云平臺根據這些聲明管理依賴，確保云應用所需的庫和服務。

Factor實踐：

package.json 就是我們的依賴清單，所有應用程序的依賴都聲明在此。

{
"name": "12factor-app",
"private": true,
"version": "0.0.0",
"description": "a Sails application",
"keywords": [],
"dependencies": {
?"ejs": "2.3.4",
?"grunt": "1.0.1",
?"grunt-contrib-clean": "1.0.0",
?"grunt-contrib-coffee": "1.0.0",
?"grunt-contrib-concat": "1.0.1",
?"grunt-contrib-copy": "1.0.0",
?"grunt-contrib-cssmin": "1.0.1",
?"grunt-contrib-jst": "1.0.0",
?"grunt-contrib-less": "1.3.0",
?"grunt-contrib-uglify": "1.0.1",
?"grunt-contrib-watch": "1.0.0",
?"grunt-sails-linker": "~0.10.1",
?"grunt-sync": "0.5.2",
?"include-all": "^1.0.0",
?"rc": "1.0.1",
?"sails": "~0.12.11",
?"sails-disk": "~0.10.9"
},
"scripts": {
?"debug": "node debug app.js",
?"start": "node app.js"
},
"main": "app.js",
"repository": {
?"type": "git",
?"url": "git://github.com/bingo/12factor-app.git"
},
"author": "bingo",
"license": ""
}

# 接下來我們加入 mongodb的庫依賴（后續會用到），只需要執行：

npm install sails-mongo --save

# 同時 package.json 中會有相應的變更

{
? ...
? "dependencies": {
? ? ...
? ? "sails-mongo": "^0.12.2" ?//最新加入的依賴
? }
? ...
}

應用程序需要用到的依賴庫都安裝在?node_modules文件夾下，該文件夾就是作為應用的依賴隔離，并且和系統的庫是隔離的。

?

3?配置

Factor解說：

12-Factor推薦將應用的配置存儲于環境變量中，保證配置排除在代碼之外，有如下好處：

• 環境變量是一種清楚、容易理解和標準化的配置方法；

• 環境變量可以非常方便地在不同的部署間做修改，卻不動一行代碼；

• 與配置文件不同，不小心把它們簽入代碼庫的概率微乎其微；

• 與一些傳統的解決配置問題的機制（比如 Java 的屬性配置文件）相比，環境變量與語言和系統無關；

• 存儲在環境變量中的另一個好處是，方便和 Docker配合使用。

一個技巧：判斷一個應用是否正確地將配置排除在代碼之外，一個簡單的方法是看該應用可以立刻開源，而不用擔心會暴露任何敏感的信息。

Factor實踐：

在應用程序的?config/connections.js?文件中，我們使用 MONGO_URL 這個環境變量來定義?mongo?的連接方式。

module.exports.connections = {
?mongo: {
? ? adapter: 'sails-mongo',
? ? url: process.env.MONGO_URL
?}
};

在文件中，指定?module所使用的連接。

module.exports.models = {
?connection: mongo,
?migrate: 'safe'
};

如果你在本地起了一個 mongodb測試服務，就可以用這個命令驗證應用是否正常配置。

MONGO_URL=mongodb://localhost:27017/12factor-app npm start

?

4 后端服務

Factor解說：

12-Factor 應用不會區別對待本地或第三方服務，統一把后端服務 (backing services)當作附加資源或者說是遠程的資源。

所謂后端服務是指程序運行所需要的通過網絡調用的各種服務，如數據庫（MySQL），消息/隊列系統（RabbitMQ），SMTP 郵件發送服務（ Postfix），以及緩存系統（Memcached）等。

除了本地服務之外，應用程序有可能使用了第三方發布和管理的服務，如 SMTP（例如 Postmark），數據收集服務，數據存儲服務（如 Amazon S3），以及使用 API 訪問的服務（例如 Twitter）等。

對應用程序而言，本地或第三方服務都是附加資源，通過一個 url 或是其他存儲在 配置中的設置來獲取數據，僅需修改配置中的資源地址即可。

應用也因此具有容錯和復原能力，因為它一方面要求編碼時就要考慮資源不可用的情況，另外一方面也增強微服務方法的好處。

Factor實踐：

對我們的應用程序來說，用到的后端服務就是 MongoDB 數據庫。我們正是通過 MONGO_URL 來傳遞 MongoDB 的資源地址，從而實現了后端服務和應用程序的解耦。

如果當前這個 MongoDB 實例出問題了，我們可以通過設置 MONGO_URL 這個環境變量，很方便的切換一個新的實例。

?

5 構建，發布，運行

Factor解說：

12-Factor 應用嚴格區分構建，發布，運行這三個步驟。

Cloud Native應用的構建流程把大部分發布配置挪到開發階段，包括實際的代碼構建和運行應用所需的生產環境配置。

舉例來說，直接修改處于運行狀態的代碼是非常不可取的做法，因為這些修改很難再同步回構建步驟。

發布的版本就像一本只能追加的賬本，一旦發布就不可修改，任何的變動都應該產生一個新的發布版本。

Factor實踐：

針對這條原則，強烈推薦使用 Docker及其組件（Compose），它的核心理念正是：Build, Ship and Run，將適合在整個構建、發布和運行流程，我們也將從這三個方面進行講解。

① 構建：

書寫構建腳本：Dockerfile

FROM hub.c.163.com/library/node:5.12.0
MAINTAINER bingohuang <me@bingohuang.com>
# 拷貝依賴清單
COPY package.json /tmp/package.json
# 安裝依賴包
RUN cd /tmp && npm install --registry=https://registry.npm.taobao.org
# 將依賴包拷貝到應用程序目錄下
RUN mkdir /app && cp -a /tmp/node_modules /app/
# 更改工作目錄
WORKDIR /app
# 拷貝應用程序代碼
COPY . /app
# 設置應用啟動端口
ENV PORT 1337
# 暴露應用程序端口
EXPOSE 1337
# 啟動應用
CMD ["npm","start"]

Docker 構建

$ docker build -t 12factor-app:v1.0 .

Docker 鏡像推送：可以將其 push 到指定的鏡像倉庫，比如網易云基礎服務（蜂巢）的鏡像倉庫中。

$ docker push hub.c.163.com/bingohuang/12factor-app:1.0

② 發布：

書寫發布腳本：docker-compose.yml

version: '2'
services:
mongo:
?image: hub.c.163.com/library/mongo:3.2
?volumes:
? ?- mongo-data:/data/db
?ports:
? ?- "27017:27017"
app:
?image: hub.c.163.com/bingohuang/12factor-app:1.0
?ports:
? ?- "1337:1337"
?links:
? ?- mongo
?depends_on:
? ?- mongo
?environment:
? ?- MONGO_URL=mongodb://mongo/12factor-app
volumes:
?mongo-data:

以上在構建好的鏡像基礎上，定義了一個發布過程，并將配置（MONGO_URL）通過環境變量注入進去。

MONGO_URL=mongodb://mongo/12factor-app

③ 運行：

可以通過 Docker Compose在本地運行，也可以通過云平臺來在線編排（網易云基礎服務即將支持服務編排功能）。

docker-compose up -d

繼而查看日志

docker-compose logs -f

注：為了方便不熟悉 docker和 docker-compose命令的人快速運行程序和本地調試，我在源代碼中還提供了?docker.sh?腳本，方便構建、發布和運行應用（源碼請看后續資料鏈接）。

?

6 進程

Factor解說：

12-Factor 應用的進程必須無狀態且無共享。

任何需要持久化的數據都要存儲在后端服務內，比如數據庫。Session 中的數據應該保存在諸如 Memcached 或 Redis 這樣的帶有過期時間的緩存中。

運行環境中，應用程序通常是以一個和多個進程 運行的。

最簡單的場景中，代碼是一個獨立的腳本，運行環境是開發人員自己的筆記本電腦，進程由一條命令行（例如 python my_script.py）。另外一個極端情況是，復雜的應用可能會使用很多進程類型 ，也就是零個或多個進程實例。

這么做是為了保證 Cloud Native基礎設施的速度和效率。

Factor實踐：

雖然這是一個簡單的 demo應用，但查看 docker容器中的運行進程，發現也有4個進程在運行，其中?npm也就是我們的啟動進程，`node app.js` 是實際運行應用的進程。

$ docker ?exec 12-factor ps aux
USER ? ? ? PID %CPU %MEM ? ?VSZ ? RSS TTY ? ? ?STAT START ? TIME COMMAND
root ? ? ? ? 1 ?0.2 ?2.0 1076204 42024 ? ? ? ? Ssl ?18:22 ? 0:00 npm
root ? ? ? ?17 ?0.0 ?0.0 ? 4340 ? 724 ? ? ? ? ?S ? ?18:22 ? 0:00 sh -c node app.js
root ? ? ? ?18 ?0.9 ?4.5 1253808 93808 ? ? ? ? Sl ? 18:22 ? 0:01 node app.js
root ? ? ? ?27 ?1.1 ?3.7 962884 77076 ? ? ? ? ?Sl ? 18:22 ? 0:01 grunt

在這里，我們的應用進程是無狀態的，持久化的數據都存儲在了后端服務 MongoDB 當中。

?

7 端口綁定

Factor解說：

12-Factor 應用通過自我加載而不依賴于任何網絡服務器就可以創建一個面向網絡的服務。

意思就是說：Web應用通過端口綁定 (Port binding)來提供服務 ，并監聽發送至該端口的請求。Cloud Native應用的服務接口優先選擇 HTTP API 作為通用的集成框架。

還要指出的是，端口綁定這種方式也意味著一個應用可以成為另外一個應用的后端服務 ，調用方將服務方提供的相應 URL 當作資源存入 配置 以備將來調用。

Factor實踐：

docker-compose文件為我們很好的定義了端口綁定。

ports：?"1337:1337" // 應用容器暴露 1337端口在容器中，宿主機將其映射到 1337端口。

需要注意的是，如果在一個宿主機中部署多個應用實例，就不能將一個宿主機端口映射到多個容器端口（端口沖突），解決方法是在這之上加一個負載均衡，負載宿主機的不同端口服務所對應的不同容器。

?

8 并發

Factor解說：

12-factor 應用通過進程模型進行擴展，把進程看作是一等公民，并且具備無共享，水平分區的特性。

這意味著依賴底層平臺就能實現橫向擴展，不需要技術難度高的多線程編碼。

舉例來說，HTTP 請求可以交給 web 進程來處理，而常駐的后臺工作則交由 worker 進程負責，定時任務交由 clock 來處理，這樣擴展每一類的進程就非常方便，如下圖所示：

Factor實踐：

如第六個原則所描述，我們的應用擁有多個進程，最主要的是 Node.js 的http server進程，進程都是無狀態并無共享，所以我們可以非常容易的水平擴展應用。

?

9 易處理

Factor解說：

12-Factor 應用的進程是易處理（disposable）的，意思是說任何進程都可以快速啟動和優雅終止，這樣做的好處是：

• 這有利于快速、彈性的伸縮應用，迅速部署變化的代碼或配置，提高健壯性；

• 進程應當追求最小啟動時間，可以提供了更敏捷的發布以及擴展過程；

• 進程一旦接收終止信號（SIGTERM） 就會優雅的終止。

如下圖所示，就是一個優雅的應用啟動和終止流程。

Factor實踐：

Docker 先天的輕量級和隔離性，就非常適合來做快速啟動和優雅終止，Docker非常適合實踐這條原則，在我們的應用中，就加入了 Docker和Compose實踐。

針對線上環境，推薦構建在容器云平臺之上（比如網易云基礎服務平臺），可以更優雅的處理進程的啟動和停止。

?

10 環境等價

Factor解說：

12-Factor 應用想要做到持續部署就必須縮小本地與線上差異，包括以下三種差異：

• 縮小時間差異：開發人員可以幾小時，甚至幾分鐘就部署代碼；

• 縮小人員差異：開發人員不只要編寫代碼，更應該密切參與部署過程以及代碼在線上的表現；

• 縮小工具差異：盡量保證開發環境以及線上環境的一致性。

12-Factor 應用的開發人員應該反對在不同環境間使用不同的后端服務。

這是因為，不同的后端服務意味著會突然出現的不兼容，從而導致測試、預發布都正常的代碼在線上出現問題。

Factor實踐：

我們的應用程序中，使用了 docker-compose作為我們的發布腳本，它使得應用既可以在本地運行，也可以在任何支持 Docker 的云平臺上運行，應用無需變化，只需修改配置文件，很好的解除了不同環境的差異化。

從以往經驗來看，傳統應用和 12-Factor應用會存在如下差異：

?

11 日志

Factor解說：

12-factor應用本身從不考慮存儲自己的輸出流。相反，每一個運行的進程都會直接的標準輸出（stdout）事件流。

當日志是由云平臺而不是應用包含的庫處理時，日志處理機制必須保持簡單。

Factor實踐：

許多服務都能提供日志集中管理，比如 ELK、Splunk、Logentries，而且大多數都能方便的和 Docker集成在一起。

這里以 Logentries 為例來為應用集成日志服務，需要在 docker-compose 文件中加入 log 服務，如下：

log:
?command: '-t a80277ea-4233-7785203ae328'
?image: 'logentries/docker-logentries’
?restart: always
?tags:
? ?- development
?volumes:
? ?- '/var/run/docker.sock:/var/run/docker.sock'

一個典型的 Logentries 面板界面如下：

?

12 管理進程

Factor解說：

開發人員經常希望執行一些管理或維護應用的一次性任務，例如：

• 運行數據移植

• 運行一個控制臺也被稱為 REPL shell，來執行一些代碼或是針對線上數據庫做一些檢查。

• 運行一些提交到代碼倉庫的一次性腳本。

12-Factor應用中，一次性管理進程應該和正常的常駐進程（應用進程）使用同樣的環境，并且使用相同的代碼和配置，基于某個發布版本運行，隨著其他的應用程序一起發布。

在 Cloud Native中，管理任務也是一個進程，而不是特別的工具；同樣重要的是，管理任務的進程不應使用秘密的 API 或者內部機制。

Factor實踐：

我們可以在 docker-compose 文件中定義管理服務，和程序一起執行。

我們可以通過通過docker exec命令執行一些管理任務，比如：

docker exec -ti ADMIN_CONTAINER_ID bash

如果多個容器處在相同的網絡下，可以通過一個容器來管理其它容器。

?

總結

---

至此，12-Factor一一實踐完畢，從中可以看出，12-Factor并非相互獨立，而是一個整體，有的涉及代碼和框架（Node和Rails），有的涉及工具（Docker和Compose）有的涉及架構和平臺。在云原生時代，12-Factor仍然具有強大的生命力，每一條原則都是應用開發的珠璣，而且每一個原則也不是一成不變的，隨著新的理念出現，原有的Factor會得到延伸和發展，也會出現新的原則，有興趣的同學，不妨讀一讀《Beyond the 12 Factor App》這本書，還會有更大的收獲。最后，希望此次分享對你理解云原生應用、實踐 12-Factor有所幫助。

?

參考鏈接

---

源代碼：

https://github.com/bingohuang/12factor-app

文章地址：

http://talks.bingohuang.com/2017/cloud-native-12factor.article

12-Factor 在線書籍：

http://12.bingohuang.com/zh_cn/index.html

12-Factor 書籍開源：

https://github.com/bingohuang/12factor-gitbook

總結

以上是生活随笔為你收集整理的云原生时代下的12-factor应用与实践的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。