SaaS應(yīng)用12原則

• 1、What
• • 1.1 什么是 "12 Factor App" ?
  • 1.2 "12 Factor App" 分別是什么？
• 2、Why
• 3、How
• • 3.1 基準(zhǔn)代碼
  • 3.2 依賴
  • 3.3 配置
  • 3.4 后端服務(wù)
  • 3.5 構(gòu)建，發(fā)布，運(yùn)行
  • 3.6 進(jìn)程
  • 3.7 端口綁定
  • 3.8 并發(fā)
  • 3.9 易處理
  • 3.10 開發(fā)環(huán)境與線上環(huán)境等價(jià)
  • 3.11 日志
  • 3.12 管理進(jìn)程
• 4、Sample

1、What

1.1 什么是 “12 Factor App” ?

目前，軟件通常作為一種服務(wù)來進(jìn)行交付，他們被稱之為網(wǎng)絡(luò)應(yīng)用程序，或軟件即服務(wù)（Saas）, 12-Factor 為構(gòu)建Saas 應(yīng)用提供了方法論。

1.2 “12 Factor App” 分別是什么？

#因素描述

1	基準(zhǔn)代碼	一份基準(zhǔn)代碼，可以進(jìn)行多份部署
2	依賴	顯示聲明所有的依賴關(guān)系
3	配置	在環(huán)境中存儲配置
4	后端服務(wù)	把后端服務(wù)當(dāng)做附加資源
5	構(gòu)建，發(fā)布，運(yùn)行	嚴(yán)格分離構(gòu)建和運(yùn)行
6	進(jìn)程	以一個(gè)或多個(gè)無狀態(tài)進(jìn)程運(yùn)行應(yīng)用
7	端口綁定	通過端口綁定提供服務(wù)
8	并發(fā)	通過進(jìn)程模型進(jìn)行擴(kuò)展
9	易處理	快速啟動(dòng)和優(yōu)雅終止可最大化健壯性
10	開發(fā)環(huán)境與線上環(huán)境等價(jià)	盡可能的保持開發(fā)，預(yù)發(fā)布，線上的環(huán)境相同
11	日志	把日志當(dāng)做事件流
12	管理進(jìn)程	后臺管理任務(wù)當(dāng)做一次性進(jìn)程運(yùn)行

2、Why

“12-factor app” 是為構(gòu)建可擴(kuò)展、高性能、獨(dú)立且最具彈性的云原生應(yīng)用程序而定義的一種方法或一組原則：
The 12-factor app is a methodology or set of principles defined for building the scalable and performant, independent, and most resilient cloud-native applications:

• 使用聲明性格式進(jìn)行設(shè)置自動(dòng)化，從而最大限度地減少新進(jìn)開發(fā)人員加入項(xiàng)目的時(shí)間和成本
  Use declarative formats for setup automation, which minimizes time and cost for new developers joining the project
• 與底層操作系統(tǒng)松耦合的狀態(tài)，為執(zhí)行環(huán)境之間提供了最大的可移植性
  Have a clean contract with the underlying operating system, offering maximum portability between execution environments
• 適合部署在現(xiàn)代云平臺上
  Are suitable for deployment on modern cloud platforms
• 最大限度地減少開發(fā)環(huán)境和生產(chǎn)環(huán)境之間的差異，實(shí)現(xiàn)持續(xù)部署以獲得最大的敏捷性
  Minimize divergence between development and production, enabling continuous deployment for maximum agility
• 無需對工具、架構(gòu)或開發(fā)實(shí)踐進(jìn)行重大更改即進(jìn)行擴(kuò)展
  Can scale up without significant changes to tooling, architecture, or development practices

3、How

3.1 基準(zhǔn)代碼

軟件開發(fā)中，版本控制尤為重要，常用的如Git，SVN等。一份用來跟蹤代碼所有修訂版本的數(shù)據(jù)庫被稱作：代碼庫。
在類似 SVN 這樣的集中式版本控制系統(tǒng)中，基準(zhǔn)代碼 就是指控制系統(tǒng)中的這一份代碼庫；而在 Git 那樣的分布式版本控制系統(tǒng)中，基準(zhǔn)代碼 則是指最上游的那份代碼庫。
基準(zhǔn)代碼和應(yīng)用之間總是保持一一對應(yīng)的關(guān)系：

• 一旦有多個(gè)基準(zhǔn)代碼，就不能稱為一個(gè)應(yīng)用，而是一個(gè)分布式系統(tǒng)。分布式系統(tǒng)中的每一個(gè)組件都是一個(gè)應(yīng)用，每一個(gè)應(yīng)用可以分別使用 12-Factor 進(jìn)行開發(fā)。
• 多個(gè)應(yīng)用共享一份基準(zhǔn)代碼是有悖于 12-Factor 原則的。解決方案是將共享的代碼拆分為獨(dú)立的類庫，然后使用依賴管理策略去加載它們。

盡管每個(gè)應(yīng)用只對應(yīng)一份基準(zhǔn)代碼，但可以同時(shí)存在多份部署。每份部署相當(dāng)于運(yùn)行了一個(gè)應(yīng)用的實(shí)例。通常會有一個(gè)生產(chǎn)環(huán)境，一個(gè)或多個(gè)預(yù)發(fā)布環(huán)境。此外，每個(gè)開發(fā)人員都會在自己本地環(huán)境運(yùn)行一個(gè)應(yīng)用實(shí)例，這些都相當(dāng)于一份部署。

所有部署的基準(zhǔn)代碼相同，但每份部署可以使用其不同的版本。比如，開發(fā)人員可能有一些提交還沒有同步至預(yù)發(fā)布環(huán)境；預(yù)發(fā)布環(huán)境也有一些提交沒有同步至生產(chǎn)環(huán)境。但它們都共享一份基準(zhǔn)代碼，我們就認(rèn)為它們只是相同應(yīng)用的不同部署而已。

3.2 依賴

大多數(shù)編程語言都會提供一個(gè)打包系統(tǒng)，用來為各個(gè)類庫提供打包服務(wù)。12-Factor規(guī)則下的應(yīng)用程序不會隱式依賴系統(tǒng)級的類庫。 它一定通過依賴清單，確切地聲明所有依賴項(xiàng)。此外，在運(yùn)行過程中通過依賴隔離工具來確保程序不會調(diào)用系統(tǒng)中存在但清單中未聲明的依賴項(xiàng)。這一做法會統(tǒng)一應(yīng)用到生產(chǎn)和開發(fā)環(huán)境。

顯式聲明依賴的優(yōu)點(diǎn)之一是為新進(jìn)開發(fā)者簡化了環(huán)境配置流程。新進(jìn)開發(fā)者可以檢出應(yīng)用程序的基準(zhǔn)代碼，安裝編程語言環(huán)境和它對應(yīng)的依賴管理工具，只需通過一個(gè)構(gòu)建命令來安裝所有的依賴項(xiàng)，即可開始工作。

12-Factor 應(yīng)用同樣不會隱式依賴某些系統(tǒng)工具，如 ImageMagick 或是curl。即使這些工具存在于幾乎所有系統(tǒng)，但終究無法保證所有未來的系統(tǒng)都能支持應(yīng)用順利運(yùn)行，或是能夠和應(yīng)用兼容。如果應(yīng)用必須使用到某些系統(tǒng)工具，那么這些工具應(yīng)該被包含在應(yīng)用之中。

3.3 配置

通常，引用的配置在不同部署環(huán)境中會有很大差異，有些應(yīng)用在代碼中使用了常量保存配置，這就與12-Factor所要求的代碼的代碼和配置嚴(yán)格分離大相徑庭。配置文件在各部署間存在大幅差異，代碼卻完全一致。判斷一個(gè)應(yīng)用是否正確地將配置排除在代碼之外，一個(gè)簡單的方法是看該應(yīng)用的基準(zhǔn)代碼是否可以立刻開源，而不用擔(dān)心會暴露任何敏感的信息。

一個(gè)解決方法是使用配置文件，但不把它們納入版本控制系統(tǒng)，就像 Rails 的 config/database.yml 。這相對于在代碼中使用常量已經(jīng)是長足進(jìn)步，但仍然有缺點(diǎn)：總是會不小心將配置文件簽入了代碼庫；配置文件也可能會分散在不同的目錄，并有著不同的格式，這讓找出一個(gè)地方來統(tǒng)一管理所有配置變的不太現(xiàn)實(shí)。更糟的是，這些格式通常是語言或框架特定的。

12-Factor推薦將應(yīng)用的配置存儲于 環(huán)境變量 中（ env vars, env ）。環(huán)境變量可以非常方便地在不同的部署間做修改，卻不動(dòng)一行代碼；與配置文件不同，不小心把它們簽入代碼庫的概率微乎其微；與一些傳統(tǒng)的解決配置問題的機(jī)制（比如 Java 的屬性配置文件）相比，環(huán)境變量與語言和系統(tǒng)無關(guān)。

目前特別流行的docker是可以很容易地滿足這個(gè)需求

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

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

配置管理的另一個(gè)方面是分組。有時(shí)應(yīng)用會將配置按照特定部署進(jìn)行分組（或叫做“環(huán)境”），隨著項(xiàng)目的不斷深入，開發(fā)人員可能還會添加他們自己的環(huán)境，這將導(dǎo)致各種配置組合的激增，從而給管理部署增加了很多不確定因素。

2-Factor 應(yīng)用中，環(huán)境變量的粒度要足夠小，且相對獨(dú)立。它們永遠(yuǎn)也不會組合成一個(gè)所謂的“環(huán)境”，而是獨(dú)立存在于每個(gè)部署之中。當(dāng)應(yīng)用程序不斷擴(kuò)展，需要更多種類的部署時(shí)，這種配置管理方式能夠做到平滑過渡。

3.4 后端服務(wù)

后端服務(wù)是指程序運(yùn)行所需要的通過網(wǎng)絡(luò)調(diào)用的各種服務(wù)，如數(shù)據(jù)庫（MySQL，CouchDB），消息/隊(duì)列系統(tǒng)（RabbitMQ，Beanstalkd），SMTP 郵件發(fā)送服務(wù)（Postfix），以及緩存系統(tǒng)（Memcached）。

類似數(shù)據(jù)庫的后端服務(wù)，通常由部署應(yīng)用程序的系統(tǒng)管理員一起管理。除了本地服務(wù)之外，應(yīng)用程序有可能使用了第三方發(fā)布和管理的服務(wù)。12-Factor 應(yīng)用不會區(qū)別對待本地或第三方服務(wù)。 對應(yīng)用程序而言，兩種都是附加資源，通過一個(gè) url 或是其他存儲在 配置 中的服務(wù)定位/服務(wù)證書來獲取數(shù)據(jù)。

每個(gè)不同的后端服務(wù)是一份資源 。例如，一個(gè) MySQL 數(shù)據(jù)庫是一個(gè)資源，兩個(gè) MySQL 數(shù)據(jù)庫（用來數(shù)據(jù)分區(qū)）就被當(dāng)作是 2 個(gè)不同的資源。12-Factor 應(yīng)用將這些數(shù)據(jù)庫都視作附加資源，這些資源和它們附屬的部署保持松耦合。例如，如果應(yīng)用的數(shù)據(jù)庫服務(wù)由于硬件問題出現(xiàn)異常，管理員可以從最近的備份中恢復(fù)一個(gè)數(shù)據(jù)庫，卸載當(dāng)前的數(shù)據(jù)庫，然后加載新的數(shù)據(jù)庫，整個(gè)過程僅需修改配置中的資源地址，都不需要修改代碼即可完成。

3.5 構(gòu)建，發(fā)布，運(yùn)行

基準(zhǔn)代碼 轉(zhuǎn)化為一份部署(非開發(fā)環(huán)境)需要以下三個(gè)階段：

• 構(gòu)建階段 是指將代碼倉庫轉(zhuǎn)化為可執(zhí)行包的過程。構(gòu)建時(shí)會使用指定版本的代碼，獲取和打包 依賴項(xiàng)，編譯成二進(jìn)制文件和資源文件。
• 發(fā)布階段 會將構(gòu)建的結(jié)果和當(dāng)前部署所需配置相結(jié)合，并能夠立刻在運(yùn)行環(huán)境中投入使用。
• 運(yùn)行階段 （或者說“運(yùn)行時(shí)”）是指針對選定的發(fā)布版本，在執(zhí)行環(huán)境中啟動(dòng)一系列應(yīng)用程序進(jìn)程。

12-factor 應(yīng)用嚴(yán)格區(qū)分構(gòu)建，發(fā)布，運(yùn)行這三個(gè)步驟。直接修改處于運(yùn)行狀態(tài)的代碼是非常不可取的做法，因?yàn)檫@些修改很難再同步回構(gòu)建步驟。部署工具通常都提供了發(fā)布管理工具，最引人注目的功能是退回至較舊的發(fā)布版本。并且，每一個(gè)發(fā)布版本必須對應(yīng)一個(gè)唯一的發(fā)布 ID，發(fā)布的版本就像一本只能追加的賬本，一旦發(fā)布就不可修改，任何的變動(dòng)都應(yīng)該產(chǎn)生一個(gè)新的發(fā)布版本。

新的代碼在部署之前，需要開發(fā)人員觸發(fā)構(gòu)建操作。但是，運(yùn)行階段不一定需要人為觸發(fā)，而是可以自動(dòng)進(jìn)行。如服務(wù)器重啟，或是進(jìn)程管理器重啟了一個(gè)崩潰的進(jìn)程。因此，運(yùn)行階段應(yīng)該保持盡可能少的模塊，這樣假設(shè)半夜發(fā)生系統(tǒng)故障而開發(fā)人員又捉襟見肘也不會引起太大問題。構(gòu)建階段是可以相對復(fù)雜一些的，因?yàn)殄e(cuò)誤信息能夠立刻展示在開發(fā)人員面前，從而得到妥善處理。

3.6 進(jìn)程

運(yùn)行環(huán)境中，應(yīng)用程序通常是以一個(gè)或多個(gè)進(jìn)程運(yùn)行的。12-Factor 應(yīng)用的進(jìn)程必須無狀態(tài)且無共享。任何需要持久化的數(shù)據(jù)都要存儲在后端服務(wù)內(nèi)，比如數(shù)據(jù)庫。

內(nèi)存區(qū)域或磁盤空間可以作為進(jìn)程在做某種事務(wù)型操作時(shí)的緩存，例如下載一個(gè)很大的文件，對其操作并將結(jié)果寫入數(shù)據(jù)庫的過程。12-Factor應(yīng)用根本不用考慮這些緩存的內(nèi)容是不是可以保留給之后的請求來使用，這是因?yàn)閼?yīng)用啟動(dòng)了多種類型的進(jìn)程，將來的請求多半會由其他進(jìn)程來服務(wù)。即使在只有一個(gè)進(jìn)程的情形下，先前保存的數(shù)據(jù)（內(nèi)存或文件系統(tǒng)中）也會因?yàn)橹貑?#xff08;如代碼部署、配置更改、或運(yùn)行環(huán)境將進(jìn)程調(diào)度至另一個(gè)物理區(qū)域執(zhí)行）而丟失。

一些互聯(lián)網(wǎng)系統(tǒng)依賴于粘性 session（sticky session）， 這是指將用戶 session 中的數(shù)據(jù)緩存至某進(jìn)程的內(nèi)存中，并將同一用戶的后續(xù)請求路由到同一個(gè)進(jìn)程。粘性 session 是 12-Factor 極力反對的，因?yàn)槲覀儾粦?yīng)該在進(jìn)程內(nèi)存中存放數(shù)據(jù)，而且也無法確保客戶端下次的請求也會被路由到該進(jìn)程中去。Session 中的數(shù)據(jù)應(yīng)該保存在諸如 Memcached 或 Redis 這樣的帶有過期時(shí)間的緩存中。

3.7 端口綁定

互聯(lián)網(wǎng)應(yīng)用有時(shí)會運(yùn)行于服務(wù)器的容器之中。12-Factor 應(yīng)用完全自我加載而不依賴于任何網(wǎng)絡(luò)服務(wù)器就可以創(chuàng)建一個(gè)面向網(wǎng)絡(luò)的服務(wù)。互聯(lián)網(wǎng)應(yīng)用通過端口綁定來提供服務(wù)，并監(jiān)聽發(fā)送至該端口的請求。

端口綁定這種方式也意味著一個(gè)應(yīng)用可以成為另外一個(gè)應(yīng)用的后端服務(wù)，調(diào)用方將服務(wù)方提供的相應(yīng) URL 當(dāng)作資源存入配置以備將來調(diào)用。

原則總結(jié):

• 應(yīng)用內(nèi)嵌 HTTP 庫，如 Tomcat、Jetty等，例如 Spring Boot 的應(yīng)用
• 直接綁定端口對外提供服務(wù)，不依賴外部服務(wù)容器運(yùn)行，例如 Dubbo
• 通過在環(huán)境變量中聲明，服務(wù)可以作為其他服務(wù)的依賴

需要注意的是，如果在一個(gè)宿主機(jī)中部署多個(gè)應(yīng)用實(shí)例，就不能將一個(gè)宿主機(jī)端口映射到多個(gè)容器端口（端口沖突），解決方法是在這之上加一個(gè)負(fù)載均衡，負(fù)載宿主機(jī)的不同端口服務(wù)所對應(yīng)的不同容器

3.8 并發(fā)

任何計(jì)算機(jī)程序，一旦啟動(dòng)，就會生成一個(gè)或多個(gè)進(jìn)程。在Java開發(fā)中，在Java程序啟動(dòng)之初 JVM 就提供了一個(gè)超級進(jìn)程儲備了大量的系統(tǒng)資源(CPU 和內(nèi)存)，并通過多線程實(shí)現(xiàn)內(nèi)部的并發(fā)管理。

在 12-factor 應(yīng)用中，進(jìn)程是一等公民。12-Factor 應(yīng)用的進(jìn)程主要借鑒于 unix 守護(hù)進(jìn)程模型。開發(fā)人員可以運(yùn)用這個(gè)模型去設(shè)計(jì)應(yīng)用架構(gòu)，將不同的工作分配給不同的進(jìn)程類型。

舉例來說，HTTP 請求可以交給 web 進(jìn)程來處理，而常駐的后臺工作則交由 worker 進(jìn)程負(fù)責(zé)，定時(shí)任務(wù)交由 clock 來處理，這樣擴(kuò)展每一類的進(jìn)程就非常方便，如下圖所示：

[外鏈圖片轉(zhuǎn)存失敗,源站可能有防盜鏈機(jī)制,建議將圖片保存下來直接上傳(img-6asQqlnE-1664186699924)(/.attachments/12-Factor_并發(fā)模型-8f89d4af-8796-48c8-8502-2f24a54f36d5.jpg)]

上述進(jìn)程模型會在系統(tǒng)急需擴(kuò)展時(shí)大放異彩。 12-Factor 應(yīng)用的進(jìn)程所具備的無共享，水平分區(qū)的特性 意味著添加并發(fā)會變得簡單而穩(wěn)妥。這些進(jìn)程的類型以及每個(gè)類型中進(jìn)程的數(shù)量就被稱作進(jìn)程構(gòu)成 。

總結(jié)：

• 進(jìn)程內(nèi)仍然可以進(jìn)行多線程或時(shí)間模型
• 因?yàn)榉?wù)都是無狀態(tài)的，所以橫向擴(kuò)展很容易，依賴底層平臺就能實(shí)現(xiàn)，不需要技術(shù)難度高的多線程編碼
• 進(jìn)程永遠(yuǎn)都不應(yīng)該讓自己變成守護(hù)進(jìn)程

3.9 易處理

12-Factor 應(yīng)用的進(jìn)程是易處理（disposable）的，意思是說它們可以瞬間開啟或停止。這有利于快速、彈性的伸縮應(yīng)用，迅速部署變化的代碼或配置，穩(wěn)健的部署應(yīng)用。

進(jìn)程應(yīng)當(dāng)追求最小啟動(dòng)時(shí)間 。理想狀態(tài)下，進(jìn)程從敲下命令到真正啟動(dòng)并等待請求的時(shí)間應(yīng)該只需很短的時(shí)間。更少的啟動(dòng)時(shí)間提供了更敏捷的發(fā)布以及擴(kuò)展過程，此外還增加了健壯性，因?yàn)檫M(jìn)程管理器可以在授權(quán)情形下容易的將進(jìn)程搬到新的物理機(jī)器上。

進(jìn)程一旦接收到終止信號（SIGTERM） 就會優(yōu)雅的終止。就網(wǎng)絡(luò)進(jìn)程而言，優(yōu)雅終止是指停止監(jiān)聽服務(wù)的端口，即拒絕所有新的請求，并繼續(xù)執(zhí)行當(dāng)前已接收的請求，然后退出。此類型的進(jìn)程所隱含的要求是HTTP請求大多都很短(不會超過幾秒鐘)，而在長時(shí)間輪詢中，客戶端在丟失連接后應(yīng)該馬上嘗試重連。

進(jìn)程還應(yīng)當(dāng)在面對突然死亡時(shí)保持健壯，例如底層硬件故障。雖然這種情況比起優(yōu)雅終止來說少之又少，但終究有可能發(fā)生。一種推薦的方式是使用一個(gè)健壯的后端隊(duì)列，例如 Beanstalkd ，它可以在客戶端斷開或超時(shí)后自動(dòng)退回任務(wù)。無論如何，12-Factor 應(yīng)用都應(yīng)該可以設(shè)計(jì)能夠應(yīng)對意外的、不優(yōu)雅的終結(jié)。Crash-only design 將這種概念轉(zhuǎn)化為合乎邏輯的理論。

3.10 開發(fā)環(huán)境與線上環(huán)境等價(jià)

從以往經(jīng)驗(yàn)來看，開發(fā)環(huán)境（即開發(fā)人員的本地 部署）和線上環(huán)境（外部用戶訪問的真實(shí)部署）之間存在著很多差異。這些差異表現(xiàn)在以下三個(gè)方面：

• 時(shí)間差異： 開發(fā)人員正在編寫的代碼可能需要幾天，幾周，甚至幾個(gè)月才會上線。
• 人員差異： 開發(fā)人員編寫代碼，運(yùn)維人員部署代碼。
• 工具差異： 開發(fā)人員或許使用 Nginx，SQLite，OS X，而線上環(huán)境使用 Apache，MySQL 以及 Linux。

12-Factor 應(yīng)用想要做到持續(xù)部署就必須縮小本地與線上差異。

后端服務(wù)是保持開發(fā)與線上等價(jià)的重要部分，例如數(shù)據(jù)庫，隊(duì)列系統(tǒng)，以及緩存。許多語言都提供了簡化獲取后端服務(wù)的類庫，例如不同類型服務(wù)的適配器。開發(fā)人員有時(shí)會覺得在本地環(huán)境中使用輕量的后端服務(wù)具有很強(qiáng)的吸引力，而那些更重量級的健壯的后端服務(wù)應(yīng)該使用在生產(chǎn)環(huán)境。

12-Factor 應(yīng)用的開發(fā)人員應(yīng)該反對在不同環(huán)境間使用不同的后端服務(wù) ，即使適配器已經(jīng)可以幾乎消除使用上的差異。這是因?yàn)?#xff0c;不同的后端服務(wù)意味著會突然出現(xiàn)不兼容，從而導(dǎo)致測試、預(yù)發(fā)布都正常的代碼在線上出現(xiàn)問題。這些錯(cuò)誤會給持續(xù)部署帶來阻力。從應(yīng)用程序的生命周期來看，消除這種阻力需要花費(fèi)很大的代價(jià)。

不同后端服務(wù)的適配器仍然是有用的，因?yàn)樗鼈兛梢允挂浦埠蠖朔?wù)變得簡單。但應(yīng)用的所有部署，這其中包括開發(fā)、預(yù)發(fā)布以及線上環(huán)境，都應(yīng)該使用同一個(gè)后端服務(wù)的相同版本。

3.11 日志

日志使得應(yīng)用程序運(yùn)行的動(dòng)作變得透明。在基于服務(wù)器的環(huán)境中，日志通常被寫在硬盤的一個(gè)文件里，但這只是一種輸出格式。日志應(yīng)該是事件流的匯總，將所有運(yùn)行中進(jìn)程和后端服務(wù)的輸出流按照時(shí)間順序收集起來。盡管在回溯問題時(shí)可能需要看很多行，日志最原始的格式確實(shí)是一個(gè)事件一行。日志沒有確定開始和結(jié)束，但隨著應(yīng)用在運(yùn)行會持續(xù)的增加。

12-factor 應(yīng)用本身從不考慮存儲自己的輸出流。不應(yīng)該試圖去寫或者管理日志文件。相反，每一個(gè)運(yùn)行的進(jìn)程都會直接的標(biāo)準(zhǔn)輸出（stdout）事件流。開發(fā)環(huán)境中，開發(fā)人員可以通過這些數(shù)據(jù)流，實(shí)時(shí)在終端看到應(yīng)用的活動(dòng)。

在預(yù)發(fā)布或線上部署中，每個(gè)進(jìn)程的輸出流由運(yùn)行環(huán)境截獲，并將其他輸出流整理在一起，然后一并發(fā)送給一個(gè)或多個(gè)最終的處理程序，用于查看或是長期存檔。這些存檔路徑對于應(yīng)用來說不可見也不可配置，而是完全交給程序的運(yùn)行環(huán)境管理。這些事件流可以輸出至文件，或者在終端實(shí)時(shí)觀察。最重要的，輸出流可以發(fā)送到 Splunk 這樣的日志索引及分析系統(tǒng)，或 Hadoop/Hive 這樣的通用數(shù)據(jù)存儲系統(tǒng)。這些系統(tǒng)為查看應(yīng)用的歷史活動(dòng)提供了強(qiáng)大而靈活的功能，包括：

• 找出過去一段時(shí)間特殊的事件。
• 圖形化一個(gè)大規(guī)模的趨勢，比如每分鐘的請求量。
• 根據(jù)用戶定義的條件實(shí)時(shí)觸發(fā)警報(bào)，比如每分鐘的報(bào)錯(cuò)超過某個(gè)警戒線。

3.12 管理進(jìn)程

進(jìn)程構(gòu)成（process formation）是指用來處理應(yīng)用的常規(guī)業(yè)務(wù)（比如處理 web 請求）的一組進(jìn)程。與此不同，開發(fā)人員經(jīng)常希望執(zhí)行一些管理或維護(hù)應(yīng)用的一次性任務(wù)，例如：

• 運(yùn)行數(shù)據(jù)移植
• 運(yùn)行一個(gè)控制臺（也被稱為 REPL shell），來執(zhí)行一些代碼或是針對線上數(shù)據(jù)庫做一些檢查。大多數(shù)語言都通過解釋器提供了一個(gè) REPL 工具，或是其他命令
• 運(yùn)行一些提交到代碼倉庫的一次性腳本。

一次性管理進(jìn)程應(yīng)該和正常的 常駐進(jìn)程 使用同樣的環(huán)境。這些管理進(jìn)程和任何其他的進(jìn)程一樣使用相同的 代碼 和 配置 ，基于某個(gè) 發(fā)布版本 運(yùn)行。后臺管理代碼應(yīng)該隨其他應(yīng)用程序代碼一起發(fā)布，從而避免同步問題。

所有進(jìn)程類型應(yīng)該使用同樣的依賴隔離 技術(shù)。12-factor 尤其青睞那些提供了 REPL shell 的語言，因?yàn)槟菚屵\(yùn)行一次性腳本變得簡單。在本地部署中，開發(fā)人員直接在命令行使用 shell 命令調(diào)用一次性管理進(jìn)程。在線上部署中，開發(fā)人員依舊可以使用ssh或是運(yùn)行環(huán)境提供的其他機(jī)制來運(yùn)行這樣的進(jìn)程。

4、Sample

以之前的項(xiàng)目為例：

• 基準(zhǔn)代碼: 項(xiàng)目采用 Git 進(jìn)行代碼管理，采用 Feature Branch 的分支管理策略。 dev 分支作為開發(fā)分支，每次的開發(fā)任務(wù)都從dev 分支切出任務(wù)分支進(jìn)行開發(fā)，開發(fā)完成后，將任務(wù)分支代碼再合并到dev 分支中。
• 依賴: 采用了 Maven 管理我們項(xiàng)目中用到的所有依賴，沒有其他私有依賴。只需要根據(jù)分支拉取對應(yīng)的代碼，導(dǎo)入到開發(fā)工具中，就會自動(dòng)下載項(xiàng)目用到的所有依賴，啟動(dòng)我們的服務(wù)。
• 配置: 項(xiàng)目采用配置文件的方式管理項(xiàng)目中用到的一些公共配置信息。單獨(dú)創(chuàng)建了一個(gè)的 config_file 的工程項(xiàng)目，專門存儲項(xiàng)目中用到的配置文件信息，當(dāng)新增或修改時(shí)，直接修改對應(yīng)的配置信息即可，不需要改動(dòng)代碼。使用Sring Cloud Config 構(gòu)建運(yùn)行。
• 后端服務(wù): 項(xiàng)目中用到的數(shù)據(jù)庫，MQ，緩存等信息都是一種附加的資源，他們與我們的開發(fā)的項(xiàng)目之間應(yīng)該是個(gè)松耦合的關(guān)系。例如當(dāng)我們需要更換MySQL的數(shù)據(jù)庫時(shí)，我們可以直接通過更改配置文件中對應(yīng)的 MySQL 服務(wù)的配置信息來更換我們項(xiàng)目中連接使用的數(shù)據(jù)庫。
• 構(gòu)建，發(fā)布，運(yùn)行: 當(dāng)開發(fā)完畢后，會在 Jenkins 上根據(jù)自己的開發(fā)分支進(jìn)行打包成docker鏡像，然后將服務(wù)發(fā)布到測試環(huán)境中，經(jīng)過測試沒有問題后，我們會將我們分支上的代碼統(tǒng)一合并到dev分支中，然后 Jenkins 重新使用dev分支進(jìn)行打包，將服務(wù)發(fā)布到生產(chǎn)環(huán)境中。如果有新的需求任務(wù)或者bug的出現(xiàn)，我們會創(chuàng)建另外的任務(wù)，然后根據(jù)任務(wù)進(jìn)行開發(fā)，測試，部署等一系列操作。我們不能直接修改已經(jīng)發(fā)布的服務(wù)信息，可以繼續(xù)追加一個(gè)版本，將問題修改后重新測試發(fā)布即可。
• 進(jìn)程: 每一個(gè)發(fā)布的服務(wù)都是一個(gè)進(jìn)程
• 端口綁定: 每一個(gè)服務(wù)在環(huán)境中都對一個(gè)一個(gè)唯一的端口號，請求到服務(wù)器上的請求數(shù)據(jù)，會根據(jù)特定的解析方式分發(fā)到不同的服務(wù)中去。服務(wù)通過 k8s 職工的service 配置服務(wù)的端口信息，最后通過 Ingress 將端口映射出來供前端請求調(diào)用。
• 并發(fā): 一個(gè)環(huán)境可以有多個(gè)服務(wù)進(jìn)行部署，通常我們的一個(gè)請求可能會涉及到多個(gè)服務(wù)之間的調(diào)用。或者當(dāng)我們需要一個(gè)新的服務(wù)時(shí)，只需要端口號等特殊信息不同，即可再次進(jìn)行部署，橫向擴(kuò)展十分方便。
• 易處理: 項(xiàng)目部署采用 docker 鏡像部署的方式發(fā)布運(yùn)行，開發(fā)完成后，先通過 Jenkins 將服務(wù)打包成可執(zhí)行的鏡像，在對應(yīng)的服務(wù)中，選擇將發(fā)布的鏡像版本即可。這種發(fā)布服務(wù)的當(dāng)時(shí)，可以快速的部署我們的項(xiàng)目，實(shí)現(xiàn)易處理的特點(diǎn)。
• 開發(fā)環(huán)境與線上環(huán)境等價(jià): 開發(fā)過程中，我們有專門的開發(fā)環(huán)境供我們開發(fā)使用，通過DockFile 配置環(huán)境信息，當(dāng)開發(fā)完成后，將對應(yīng)的服務(wù)發(fā)布到測試環(huán)境中，供測試人員進(jìn)行測試，驗(yàn)證。所有功能都測試通過后，就可以將測試環(huán)境中運(yùn)行的相同版本的服務(wù)在生產(chǎn)環(huán)境中發(fā)布運(yùn)行。首先，保證了測試環(huán)境與生產(chǎn)環(huán)境要相同，當(dāng)在測試環(huán)境中測試無誤后，就可以向生產(chǎn)環(huán)境發(fā)布了。
• 日志: 每一個(gè)發(fā)布的服務(wù)都會有自己的日志記錄，當(dāng)我們的程序發(fā)生錯(cuò)誤或者服務(wù)宕機(jī)的時(shí)候，我們可以通過 Ranach 平臺查看日志文件來快速定位發(fā)生的問題。 同時(shí)，項(xiàng)目中，我們采用了 elasticsearch + Kanba 的方式集成了日志系統(tǒng)，可以直接通過網(wǎng)頁來查看我們需要的日志信息。
• 管理進(jìn)程: 當(dāng)需要手動(dòng)進(jìn)行一些操作的時(shí)候，通過 k8s 直接進(jìn)入相關(guān)的 pod 中，直接通過命令進(jìn)行操作。

總結(jié)

以上是生活随笔為你收集整理的SaaS应用12原则的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。