云原生時代下的12-Factor應用與實踐

作者簡介：黃慶兵，網(wǎng)易蜂巢首席技術(shù)布道師，浙大碩士畢業(yè)，從事云計算、Docker、Go等相關(guān)開發(fā)及技術(shù)布道工作；喜歡開源，樂于分享，勤于布道，折騰過開源小工具，制作過Docker課程，分享過 Gopher Meetup。歡迎一起來探討技術(shù)！個人主頁：http://bingohuang.com/

以下為正文：

1. 簡介

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

2. 云原生

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

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

1.png
  • IaaS看做基礎 云 設施，用來提供各種基礎資源(Infrastructure)
  • PaaS作為開發(fā) 平臺，用來提供各種平臺服務(Platform)
  • SaaS交付 應用 或 服務，直面用戶，提供應用價值(Application)

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

3. 12-Factor

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

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

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

2.png

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

注：雖然 12-Factor 的原文書籍都是發(fā)布在其官網(wǎng)上，但因為網(wǎng)絡問題和格式問題，不是很方便閱讀，我將其轉(zhuǎn)化了為 GitBook 格式，并架設在網(wǎng)易蜂巢平臺上，同時開源在 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

  1. 應用與實踐

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

0. 應用準備

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

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

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

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

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

安裝 Sails 框架最新版：
<code>npm install sails -g</code>

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

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

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

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

<code>
$ 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
</code>

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

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

5.PNG

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

1.增加一個新用戶
<code>
$ 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
}
</code>

2.獲取用戶列表
<code>
$ curl http://localhost:1337/user
[
{
"name": "bingo",
"createdAt": "2017-02-13T06:13:53.791Z",
"updatedAt": "2017-02-13T06:13:53.791Z",
"id": 58a41d952f53291200b9e065
}
]
</code>

3.修改一個用戶
<code>
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
}
</code>

4.刪除一個用戶

<code>
curl -XDELETE http://localhost:1337/user/58a41d952f53291200b9e065
</code>

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

<code>
注冊你自己
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
</code>

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

I. 基準代碼

Factor解說：

12-Factor應用只有一份基準代碼（Codebase），可以多份部署（deploy）。意思就是說一個應用只有一份用來跟蹤所有修訂版本的代碼倉庫，基準代碼和應用之間總是保持一一對應的關(guān)系，因為：

  • 一旦有多個基準代碼，就不能稱為一個應用，而是一個分布式系統(tǒng)。分布式系統(tǒng)中的每一個組件都是一個應用，每一個應用可以分別使用 12-Factor 進行開發(fā)。
  • 多個應用共享一份基準代碼是有悖于 12-Factor 原則的。解決方案是將共享的代碼拆分為獨立的類庫，然后使用 依賴管理（第二個原則） 策略去加載它們。
  • 多份部署相當于是運行了該應用的多個實例，比如開發(fā)環(huán)境一個實例，測試環(huán)境、生產(chǎn)環(huán)境都有一個實例
  • 一個代碼倉庫，確保了單一的信任源，從而保證了更少的配置錯誤和更強的容錯和復原能力
11.png

Factor實踐：

使用Git作為應用的版本管理系統(tǒng)，使用GitHub我們的在線倉庫
在剛剛創(chuàng)建好的應用目錄下執(zhí)行：

<code>
$ 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
</code>

II. 依賴

Factor解說：

12-Factor規(guī)則下的應用程序不會隱式依賴系統(tǒng)級的類庫。意思就是說：通過 依賴清單 聲明所有依賴項，通過 依賴隔離 工具確保程序不會調(diào)用系統(tǒng)中存在但清單中未聲明的依賴項。并統(tǒng)統(tǒng)一應用到生產(chǎn)和開發(fā)環(huán)境。

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

Factor實踐：

package.json 就是我們的 依賴清單，所有應用程序的依賴都聲明在此。
<code>
{
"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": ""
}
</code>

接下來我們加入 mongodb 的庫依賴（后續(xù)會用到），只需要執(zhí)行：
<code>
npm install sails-mongo --save
</code>

同時 package.json 中會有相應的變更
<code>
{
...
"dependencies": {
...
"sails-mongo": "^0.12.2" //最新加入的依賴
}
...
}
</code>
應用程序需要用到的依賴庫都安裝在node_modules文件夾下，該文件夾就是作為應用的 依賴隔離，并且和系統(tǒng)的庫是隔離的

III. 配置

Factor解說：

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

  • 環(huán)境變量是一種清楚、容易理解和標準化的配置方法
  • 環(huán)境變量可以非常方便地在不同的部署間做修改，卻不動一行代碼
  • 與配置文件不同，不小心把它們簽入代碼庫的概率微乎其微
  • 與一些傳統(tǒng)的解決配置問題的機制（比如 Java 的屬性配置文件）相比，環(huán)境變量與語言和系統(tǒng)無關(guān)
  • 存儲在環(huán)境變量中的另一個好處是，方便和Docker配合使用

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

Factor實踐：

在應用程序的 config/connections.js 文件中，我們使用 MONGO_URL 這個環(huán)境變量來定義 mongo 的連接方式
<code>
module.exports.connections = {
mongo: {
adapter: 'sails-mongo',
url: process.env.MONGO_URL
}
};
</code>
在 文件中，指定module所使用的連接
<code>
module.exports.models = {
connection: mongo,
migrate: 'safe'
};
</code>

如果你在本地起了一個mongodb測試服務，就可以用這個命令驗證應用是否正常配置
<code>
MONGO_URL=mongodb://localhost:27017/12factor-app npm start
</code>

IV. 后端服務

Factor解說：

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

  • 所謂后端服務是指程序運行所需要的通過網(wǎng)絡調(diào)用的各種服務，如數(shù)據(jù)庫（MySQL），消息/隊列系統(tǒng)（RabbitMQ），SMTP 郵件發(fā)送服務（ Postfix），以及緩存系統(tǒng)（Memcached）等
  • 除了本地服務之外，應用程序有可能使用了第三方發(fā)布和管理的服務，如 SMTP（例如 Postmark），數(shù)據(jù)收集服務，數(shù)據(jù)存儲服務（如 Amazon S3），以及使用 API 訪問的服務（例如 Twitter）等

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

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

15.PNG

Factor實踐：

  • 對我們的應用程序來說，用到的后端服務就是 MongoDB 數(shù)據(jù)庫。我們正是通過 MONGO_URL 來傳遞 MongoDB 的資源地址，從而實現(xiàn)了后端服務和應用程序的解耦。
  • 如果當前這個 MongoDB 實例出問題了，我們可以通過設置 MONGO_URL 這個環(huán)境變量，很方便的切換一個新的實例

V. 構(gòu)建，發(fā)布，運行

Factor解說：

12-facfor 應用嚴格區(qū)分構(gòu)建，發(fā)布，運行這三個步驟：

  • Cloud Native應用的構(gòu)建流程把大部分發(fā)布配置挪到開發(fā)階段，包括實際的代碼構(gòu)建和運行應用所需的生產(chǎn)環(huán)境配置
  • 舉例來說，直接修改處于運行狀態(tài)的代碼是非常不可取的做法，因為這些修改很難再同步回構(gòu)建步驟
  • 發(fā)布的版本就像一本只能追加的賬本，一旦發(fā)布就不可修改，任何的變動都應該產(chǎn)生一個新的發(fā)布版本
15.PNG

Factor實踐：

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

構(gòu)建：

書寫構(gòu)建腳本：Dockerfile
<code>
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"]
</code>

Docker 構(gòu)建
<code>$ docker build -t message-app:v1.0 .
</code>

Docker 鏡像 推送：可以將其 push 到指定的鏡像倉庫，比如網(wǎng)易蜂巢的鏡像中倉庫

<code>docker push hub.c.163.com/bingohuang/12factor-app:1.0
</code>

發(fā)布：

書寫發(fā)布腳本：docker-compose.yml

<code>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:
</code>

以上在構(gòu)建好的鏡像基礎上，定義了一個發(fā)布過程，并將配置（MONGO_URL）通過環(huán)境變量注入進去
<code>
MONGO_URL=mongodb://mongo/12factor-app
</code>

運行：

可以通過Docker Compose在本地運行，也可以通過云平臺來在線編排（網(wǎng)易蜂巢即將支持服務編排功能）
<code>
docker-compose up -d
</code>
繼而查看日志
<code>
docker-compose logs -f
</code>
注：為了方便不熟悉docker和docker-compose命令的人快速運行程序和本地調(diào)試，我在源代碼中還提供了 docker.sh 腳本，方便構(gòu)建、發(fā)布和運行應用（源碼請看后續(xù)資料鏈接）。

VI. 進程

Factor解說：

  • 12-Factor 應用的進程必須無狀態(tài)且無共享。
  • 任何需要持久化的數(shù)據(jù)都要存儲在 后端服務內(nèi)，比如數(shù)據(jù)庫。
  • Session 中的數(shù)據(jù)應該保存在諸如 Memcached 或 Redis 這樣的帶有過期時間的緩存中。
  • 運行環(huán)境中，應用程序通常是以一個和多個 進程 運行的。
  • 最簡單的場景中，代碼是一個獨立的腳本，運行環(huán)境是開發(fā)人員自己的筆記本電腦，進程由一條命令行（例如python my_script.py）。另外一個極端情況是，復雜的應用可能會使用很多 進程類型 ，也就是零個或多個進程實例。
  • 這么做是為了保證Cloud Native基礎設施的速度和效率。

Factor實踐：

雖然這是一個簡單的demo應用，但查看docker容器中的運行進程，發(fā)現(xiàn)也有4個進程在運行，其中 npm 也就是我們的啟動進程，node app.js 是實際運行應用的進程
<code>
$ docker exec eaaa922abf08 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
</code>
在這里，我們的應用進程是無狀態(tài)的，持久化的數(shù)據(jù)都存儲在了后端服務 MongoDB 當中
到此，我們已經(jīng)分享完了6個Factor，并且都成功實踐在了我們的應用上，Yes！

接下來，我們繼續(xù)分享和實踐后續(xù)的6個Factor。

VII. 端口綁定

Factor解說：

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

  • 意思就是說：Web應用通過端口綁定(Port binding)來提供服務 ，并監(jiān)聽發(fā)送至該端口的請求。
  • Cloud Native應用的服務接口優(yōu)先選擇 HTTP API 作為通用的集成框架。
    還要指出的是，端口綁定這種方式也意味著一個應用可以成為另外一個應用的 后端服務 ，調(diào)用方將服務方提供的相應 URL 當作資源存入 配置 以備將來調(diào)用。

Factor實踐：

docker-compose文件為我們很好的定義了端口綁定
<code>
ports:
- "1337:1337" // 應用容器暴露1337端口在容器中，宿主機將其映射到1337端口
</code>
需要注意的是，如果在一個宿主機中部署多個應用實例，就不能將一個宿主機端口映射到多個容器端口（端口沖突），解決方法是在這之上加一個負載均衡，負載宿主機的不同端口服務所對應的不同容器。

VIII. 并發(fā)

Factor解說：

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

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

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

18.png

Factor實踐：

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

IX. 易處理

Factor解說：

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

  • 這有利于快速、彈性的伸縮應用，迅速部署變化的代碼或配置，提高健壯性
  • 進程應當追求最小啟動時間，可以提供了更敏捷的發(fā)布以及擴展過程
  • 進程一旦接收終止信號（SIGTERM） 就會優(yōu)雅的終止

如下圖所示，就是一個優(yōu)雅的應用啟動和終止流程

19.png

Factor實踐：

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

針對線上環(huán)境，推薦構(gòu)建在容器云平臺之上（比如網(wǎng)易蜂巢平臺），可以更優(yōu)雅的處理進程的啟動和停止。

X. 環(huán)境等價

Factor解說：

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

  • 縮小時間差異：開發(fā)人員可以幾小時，甚至幾分鐘就部署代碼
  • 縮小人員差異：開發(fā)人員不只要編寫代碼，更應該密切參與部署過程以及代碼在線上的表現(xiàn)
  • 縮小工具差異：盡量保證開發(fā)環(huán)境以及線上環(huán)境的一致性

12-Factor 應用的開發(fā)人員應該反對在不同環(huán)境間使用不同的后端服務

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

Factor實踐：

我們的應用程序中，使用了docker-compose作為我們的發(fā)布腳本，它使得應用既可以在本地運行，也可以在任何支持 Docker 的云平臺上運行，應用無需變化，只需修改配置文件，很好的解除了不同環(huán)境的差異化
從以往經(jīng)驗來看，傳統(tǒng)應用和12-Factor應用會存在如下差異：

20.png

XI. 日志

Factor解說：

  • 12-factor應用本身從不考慮存儲自己的輸出流。相反，每一個運行的進程都會直接的標準輸出（stdout）事件流。
  • 當日志是由云平臺而不是應用包含的庫處理時，日志處理機制必須保持簡單。

Factor實踐：

  • 許多服務都能提供日志集中管理，比如ELK、Splunk、Logentries，而且大多數(shù)都能方便的和Docker集成在一起
  • 這里以 Logentries 為例來為應用集成日志服務，需要在 docker-compose 文件中加入 log 服務，如下：
    <code>
    log:
    command: '-t a80277ea-4233-7785203ae328'
    image: 'logentries/docker-logentries’
    restart: always
    tags:
    • development
      volumes:
    • '/var/run/docker.sock:/var/run/docker.sock'
      </code>
      一個典型的 Logentries 面板界面如下：
21.png

XII. 管理進程

Factor解說：

開發(fā)人員經(jīng)常希望執(zhí)行一些管理或維護應用的一次性任務，例如：

  • 運行數(shù)據(jù)移植

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

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

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

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

Factor實踐：

  • 我們可以在 docker-compose 文件中定義管理服務，和程序一起執(zhí)行
  • 我們可以通過通過docker exec命令執(zhí)行一些管理任務，比如：
    <code>docker exec -ti ADMIN_CONTAINER_ID bash
    </code>
  • 如果多個容器處在相同的網(wǎng)絡下，可以通過一個容器來管理其它容器

5. 總結(jié)

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

6. 參考鏈接：

最后編輯于 ：
?著作權(quán)歸作者所有,轉(zhuǎn)載或內(nèi)容合作請聯(lián)系作者
【社區(qū)內(nèi)容提示】社區(qū)部分內(nèi)容疑似由AI輔助生成，瀏覽時請結(jié)合常識與多方信息審慎甄別。
平臺聲明：文章內(nèi)容（如有圖片或視頻亦包括在內(nèi)）由作者上傳并發(fā)布，文章內(nèi)容僅代表作者本人觀點，簡書系信息發(fā)布平臺，僅提供信息存儲服務。

相關(guān)閱讀更多精彩內(nèi)容

  • Spring Cloud為開發(fā)人員提供了快速構(gòu)建分布式系統(tǒng)中一些常見模式的工具（例如配置管理，服務發(fā)現(xiàn)，斷路器，智...
    卡卡羅2017閱讀 136,695評論 19贊 139
  • Docker — 云時代的程序分發(fā)方式 要說最近一年云計算業(yè)界有什么大事件？Google Compute Engi...
    ahohoho閱讀 15,874評論 15贊 147
  • 從出生到現(xiàn)在媽媽對我說的話最多的一句就是：“本事長在自己身上，是誰也搶不走的。”直至今天我才徹底的明白。 今天一個...
    丁信子閱讀 308評論 0贊 0
  • reasons： 是從服務器一次拉取全部不重復的過往的填寫記錄 public class ComboxKeyAda...
    秋蘭兮青青閱讀 862評論 0贊 0
  • 又是一個光棍節(jié)，總自詡自己是文青的H先生又在朋友圈文縐縐地發(fā)了一句話：“無人問我粥可溫，無人與我立黃昏?！边^了一會...
    冷月丶葬花魂閱讀 551評論 0贊 0

友情鏈接更多精彩內(nèi)容