微服務-十二要素
前言
今天看“如何實現現代應用的快速落地”公開課，提到十二要素，之前文章也提到多次，這裏統一匯總下：
十二要素
如今，軟件通常會作為一種服務來交付，它們被稱為網絡應用程序，或“軟件即服務”（SaaS）。“十二要素應用程序”（12-Factor App）為構建如下的SaaS應用提供了方法論：
- 使用標準化流程自動配置，從而使新的開發者花費最少的學習成本加入這個項目；
- 和操作系統之間盡可能的劃清界限，在各個系統中提供最大的可移植性；
- 適合部署在現代的雲計算平臺，從而在服務器和系統管理方面節省資源；
- 將開發環境和生產環境的差異降至最低，並使用持續交付實施敏捷開發；
- 可以在工具、架構和開發流程不發生明顯變化的前提下實現擴展；
這套理論適用於任意語言和後端服務（數據庫、消息隊列、緩存等）開發的應用程序。
1. 基準代碼
一份基準代碼，多份部署
基準代碼和應用之間總是保持一一對應的關系：
一旦有多個基準代碼，就不能稱為一個應用，而是一個分布式系統。分布式系統中的每一個組件都是一個應用，每一個應用可以分別使用12-Factor進行開發。
多個應用共享一份基準代碼是有悖於12-Factor原則的。解決方案是將共享的代碼拆分為獨立的類庫，然後使用依賴管理策略去加載它們。盡管每個應用只對應一份基準代碼，但可以同時存在多份部署。所有部署的基準代碼相同，但每份部署可以使用其不同的版本。
2. 依賴
顯式聲明依賴關系
12-Factor規則下的應用程序不會隱式依賴系統級的類庫。 它一定通過依賴清單 ，確切地聲明所有依賴項。此外，在運行過程中通過 依賴隔離 工具來確保程序不會調用系統中存在但清單中未聲明的依賴項。這一做法會統一應用到生產和開發環境。
3. 配置
在環境中存儲配置
12-Factor推薦將應用的配置存儲於環境變量 中 (env vars, env) 。環境變量可以非常方便地在不同的部署間做修改，卻不動一行代碼；與配置文件不同，不小心把它們簽入代碼庫的概率微乎其微；與一些傳統的解決配置問題的機制（比如Java的屬性配置文件）相比，環境變量與語言和系統無關。
12-Factor應用中，環境變量的粒度要足夠小，且相對獨立。它們永遠也不會組合成一個所謂的“環境”，而是獨立存在於每個部署之中。當應用程序不斷擴展，需要更多種類的部署時，這種配置管理方式能夠做到平滑過渡。
4. 後端服務
把後端服務當作附加資源
12-Factor應用不會區別對待本地或第三方服務。 對應用程序而言，兩種都是附加資源，通過一個url或是其他存儲在 配置 中的服務定位/服務證書來獲取數據。12-Factor應用的任意 部署 ，都應該可以在不進行任何代碼改動的情況下，將本地MySQL數據庫換成第三方服務(例如 Amazon RDS)。類似的，本地SMTP服務應該也可以和第三方SMTP服務(例如Postmark)互換。
5. 構建，發布，運行
嚴格分離構建和運行
12-facfor應用嚴格區分構建，發布，運行這三個步驟。每一個發布版本必須對應一個唯一的發布ID。
新的代碼在部署之前，需要開發人員觸發構建操作。但是，運行階段不一定需要人為觸發，而是可以自動進行。
6. 進程
以一個或多個無狀態進程運行應用
12-factor應用的進程必須無狀態且無共享 。任何需要持久化的數據都要存儲在後端服務內，比如數據庫。粘性Session是twelve-factor極力反對的。Session中的數據應該保存在諸如Memcached 或 Redis 這樣的帶有過期時間的緩存中。
7. 端口綁定
通過端口綁定提供服務
12-factor應用完全自我加載而不依賴於任何網絡服務器就可以創建一個面向網絡的服務。互聯網應用 通過端口綁定來提供服務，並監聽發送至該端口的請求。
8. 並發
通過進程模型進行擴展
在12-factor應用中，進程是一等公民。 12-factor應用的進程主要借鑒於 unix守護進程模型 。開發人員可以運用這個模型去設計應用架構，將不同的工作分配給不同的進程類型 。
9. 易處理
快速啟動和優雅終止可最大化健壯性
12-factor應用的進程是可支配的，意思是說它們可以瞬間開啟或停止。 這有利於快速、彈性的伸縮應用，迅速部署變化的代碼或配置，穩健地部署應用。進程應當追求最小啟動時間；進程一旦接收終止信號(SIGTERM) 就會優雅的終止 。進程還應當在面對突然死亡時保持健壯 。
10. 開發環境與線上環境等價
盡可能的保持開發、預發布、線上環境相同
12-factor應用想要做到持續部署就必須縮小本地與線上差異。12-factor應用的開發人員應該反對在不同環境間使用不同的後端服務 ，即使適配器已經可以幾乎消除使用上的差異。
11. 日誌
把日誌當作事件流
12-factor應用本身從不考慮存儲自己的輸出流。 不應該試圖去寫或者管理日誌文件。相反，每一個運行的進程都會直接的標準輸出(stdout)事件流。開發環境中，開發人員可以通過這些數據流，實時在終端看到應用的活動。
12. 管理進程
後臺管理任務當作一次性進程運行
一次性管理進程應該和正常的 常駐進程 使用同樣的環境。這些管理進程和任何其他的進程一樣使用相同的代碼和配置，基於某個發布版本運行。後臺管理代碼應該隨其他應用程序代碼一起發布，從而避免同步問題。所有進程類型應該使用同樣的依賴隔離技術。12-factor尤其青睞那些提供了REPL shell的語言，因為那會讓運行一次性腳本變得簡單。
微服務-十二要素