# 雲原生12要素
雲原生的 12 要素提供了一套最佳實踐，幫助開發者建構在雲環境中運行的應用。以下是 12 要素的價值和它們可以解決的問題：


### 代碼基底 (Codebase)

說明：確保一個應用只有一個代碼基底，但可以多重部署。使用版本控制系統，如 Git，來管理代碼
解決問題：避免版本不一致和部署混亂。
例子：一家公司的網站可能有一個 GitHub 存儲庫，其中包含整個網站的代碼。該代碼可以部署到開發環境、測試環境和生產環境。
### 依賴 (Dependencies)

說明：明確聲明和隔離依賴。使用包管理工具，如 npm 或 pip，來管理依賴
解決問題：消除“在我的機器上運行正常”問題，確保一致性。
例子：一個 Python 應用可能使用 pip 和 requirements.txt 文件來管理和安裝其依賴。
### 配置 (Config)

說明：將配置與代碼分離。將應用的配置存儲在環境變數中。避免將配置硬編碼在代碼中。
解決問題：提高安全性，避免敏感資訊泄露。
例子：資料庫連接字串不應該硬編碼在代碼中，而是存儲在環境變數中。
### 後端服務 (Backing Services)

說明：把後端服務，如資料庫或郵件服務，當作附加資源。透過 URL 或其他標識符來連接後端服務。
解決問題：提高應用的靈活性和可移植性。
例子：應用可能使用 Amazon RDS 作為其資料庫，並使用 Redis 作為其快取層。
### 構建、發布、運行 (Build, release, run)

說明：清晰分隔構建、發布和運行階段。每次更改都會產生新的發布。
解決問題：確保代碼的一致性和可追溯性。
例子：使用 Jenkins 進行 CI/CD，首先構建代碼，然後結合配置創建一個發布，最後在伺服器上運行該發布。
### 進程 (Processes)

說明：應用以無狀態進程運行。每次請求都應該是無狀態的。
解決問題：提高應用的可擴展性和可靠性。
例子：一個 e-commerce 網站在處理用戶訂單時，每個訂單都在其自己的進程中處理，不共享任何本地狀態。
### 端口綁定 (Port binding)

說明：應用應該自行綁定到所需的端口，而不依賴於運行時提供的服務。
解決問題：提高應用的可移植性。
例子：一個 Node.js 應用使用 Express 框架，它可以直接綁定到端口 3000，而不需要 Apache 或 Nginx。
### 同步與擴展 (Concurrency)

說明：透過進程模型擴展應用。
解決問題：確保應用可以應對大量的用戶和請求。
例子：在 Black Friday 期間，為了應對大量的用戶流量，應用可以橫向擴展，運行多個進程副本。
### 可丟棄性 (Disposability)

說明：快速啟動和優雅終止。
解決問題：提高系統的韌性和可靠性。
例子：在部署新版本時，舊版本的應用實例可以迅速關閉，而新實例可以迅速啟動。
### 開發/生產平行性 (Dev/prod parity)

說明：保持開發和生產環境的一致性。
解決問題：減少部署風險和問題排查時間。
例子：開發者在本地使用 Docker 容器運行應用，確保開發環境與生產環境保持一致。
### 日誌 (Logs)
說明：產生結構化的日誌。
解決問題：提高問題的可追溯性和排查效率。
例子：應用將日誌寫入 stdout，然後使用像 Logstash 或 Fluentd 這樣的工具來收集和分析日誌。

### 管理進程 (Admin processes)
說明：一次性的管理和維護任務。
解決問題：確保管理任務的一致性和可靠性。
例子：

資料庫遷移：當您需要更新資料庫結構或進行資料轉換時，您可能會執行一次性的資料庫遷移腳本。例如，使用 Django 的 manage.py 腳本執行資料庫遷移。

* 清理任務：例如，您可能有一個腳本，專門用於清理舊的日誌文件或過期的資料。
* 資料初始化：當部署一個新的應用或服務時，您可能需要執行一些腳本來填充或初始化資料庫。
* 臨時修復：例如，如果資料庫中的某些資料出現問題，您可能需要執行一個一次性的腳本來修復這些資料。

這些管理進程應該使用與常規應用相同的代碼基底和配置，並在相同的環境中運行，以確保一致性。此外，這些進程應該是一次性的，意味著它們執行一次特定的任務，然後終止。

總之，雲原生的 12 要素提供了一套最佳實踐，幫助開發者建構在雲環境中運行的應用，確保其可擴展性、可維護性和可靠性。這些要素解決了傳統應用開發和部署中常見的問題，使得應用更適合在雲環境中運行。

为了云原生应用程序而新增加3个因素：

API first - API 优先
Telemetry - 遥测
Authentication and authorization - 认证和授权