簡介
雲端運算徹底改變了我們建構和操作軟體的方式。但僅僅在雲端上運行應用程式並不等於「雲端原生」。本課程將幫助您了解雲端原生的真正意義、其重要性以及每個工程師應掌握的基本原則。
1.什麼是雲端原生？
1.1 CNCF 的定義
根據雲端原生運算基金會 (CNCF)（管理 Kubernetes、Prometheus、Envoy 等專案的組織）的說法：
雲端原生技術使組織能夠在公有雲、私有雲和混合雲等現代動態環境中建置和運行可擴展的應用程式。容器、服務網格、微服務、不可變基礎架構和宣告式 API 就是這種方法的例證。
簡而言之：雲端原生是建構充分利用雲端運算的應用程式的方法。
1.2 核心特性
Cloud Native Application
├── Containerized → Đóng gói nhất quán, portable
├── Dynamically Orchestrated → Kubernetes tự động quản lý
├── Microservices-oriented → Chia nhỏ, độc lập, dễ scale
├── Loosely Coupled → Ít phụ thuộc lẫn nhau
├── Resilient → Tự phục hồi khi có lỗi
├── Observable → Giám sát toàn diện (metrics, logs, traces)
└── Automated → CI/CD, IaC, GitOps
1.3 雲端原生≠“在雲端運行”
在 AWS EC2 上運行的應用程序，但仍然是整體應用程序，手動部署，沒有自動擴展 - 不是雲端原生。
相較之下，在具有完整容器、CI/CD、可觀察性的本地 Kubernetes 叢集上運行的應用程式 — 這就是雲端原生。
雲端原生是關於如何建置和操作，而不是在哪裡運作。
2. 比較傳統與雲端原生
| 特點 | 傳統 | 雲端原生 |
|---|---|---|
| 架構 | 整體 | 微服務 |
| 部署 | 虛擬機器/裸機 | 容器/Kubernetes |
| 縮放 | 垂直（放大） | 水平（橫向擴展） |
| 發布週期 | 每月/每季 | 每日/每小時 |
| 故障處理 | 不惜一切代價避免失敗 | 接受失敗，自我恢復 |
| 基礎設施 | 可變（就地更新） | 不可變（完全替換） |
| 狀態 | 有狀態伺服器 | 無狀態服務+外部狀態 |
| 設定 | 伺服器上的設定檔 | 環境變數/ConfigMap |
| 網路 | 固定IP | 動態 DNS、服務發現 |
| 監控 | 反應性（知道什麼時候發生） | 主動（指標、警報、追蹤） |
實際例子
傳統方法：
Developer → Build WAR → Gửi cho Ops → Ops deploy lên Tomcat trên VM
→ Cần scale? Mua thêm server, cài đặt thủ công
→ Server die? Downtime cho đến khi fix xong
雲端原生方法：
Developer → Git push → CI/CD tự động build container image
→ ArgoCD sync → Kubernetes deploy 3 replicas
→ Cần scale? HPA tự thêm pod
→ Pod die? Kubernetes tự restart trong giây
3. 為什麼選擇雲端原生？
3.1 業務驅動因素
- 上市時間：在數小時而不是數週內部署新功能
- 可擴充性：自動處理流量高峰（黑色星期五、閃購）
- 成本效率：不需要時縮小規模，只需為您使用的部分付費
- 創新速度：團隊獨立並行開發
3.2 技術驅動因素
- 故障隔離：服務A中的錯誤不會導致整個系統癱瘓
- 技術多樣性：每個服務都可以使用最合適的語言/框架
- 獨立部署：更新服務A而不重新部署服務B
- 資源最佳化：為每個工作負載準確分配CPU/記憶體
4. 十二要素應用程序
Heroku於2011年提出的十二因素應用程式（12factor.net）方法論是雲端原生應用程式設計的理論基礎。
4.1 12個因素概述
因素 1：程式碼庫
由版本控制管理的單一程式碼庫，部署到多個環境。
Git Repository (1 codebase)
├── Deploy → Development
├── Deploy → Staging
└── Deploy → Production
規則：一個應用程式 = 一個儲存庫。如果有共享程式碼，請將其分離到一個庫中。
因素 2：依賴性
清楚地聲明和隔離依賴關係。
// package.json — khai báo rõ ràng
{
"dependencies": {
"express": "4.18.2",
"pg": "8.11.0"
}
}
永遠不要依賴伺服器上預先安裝的系統級軟體包。
因素 3：配置
將配置儲存到環境變數中。
# ✅ Đúng: Config qua env vars
DATABASE_URL=postgresql://user:pass@host:5432/db
REDIS_URL=redis://cache:6379
API_KEY=sk-xxx
# ❌ Sai: Hardcode trong source code
const DB_HOST = "192.168.1.100";
因素 4：支援服務
將支援服務作為附加資源來處理。
App ──attach──▶ PostgreSQL (có thể thay bằng RDS bất cứ lúc nào)
App ──attach──▶ Redis (có thể thay bằng ElastiCache)
App ──attach──▶ S3 (có thể thay bằng MinIO)
更改支援服務=更改配置，不更改代碼。
因素 5：建置、發布、運行
完全獨立的建置、發布和運行階段。
Build Stage: Source code → Executable (Docker image)
Release Stage: Image + Config → Versioned release (v1.2.3)
Run Stage: Launch release trong execution environment
因素 6：流程
將應用程式作為無狀態進程運行。
# ✅ Stateless: Session lưu ở Redis
Request → App Instance 1 ──session──▶ Redis
Request → App Instance 2 ──session──▶ Redis
# ❌ Stateful: Session lưu trong memory
Request → App Instance 1 (session ở đây)
Request → App Instance 2 (không có session!) ← BUG
因素 7：連接埠綁定
透過連接埠綁定導出服務。
應用程式包含自己的 HTTP 伺服器（不需要外部 Tomcat/Apache）：
const app = express();
app.listen(process.env.PORT || 8080);
因素 8：並發性
透過流程模型進行橫向擴展。
Thay vì 1 process lớn dùng 16 cores:
├── Web process × 4 (handle HTTP requests)
├── Worker process × 8 (background jobs)
└── Clock process × 1 (scheduled tasks)
因素 9：一次性使用
快速啟動，優雅關閉。
Startup: < 5 giây (lý tưởng < 1 giây)
Shutdown: SIGTERM → hoàn thành request đang xử lý → close connections → exit
因素 10：開發/產品對等
盡可能使開發、試運行和生產相似。
# ✅ Dev dùng PostgreSQL, Prod dùng PostgreSQL
# ❌ Dev dùng SQLite, Prod dùng PostgreSQL
# ❌ Dev dùng file system, Prod dùng S3
Docker Compose 有助於實現開發/產品對等。
因素 11：日誌
將日誌當作事件流處理。
Application → stdout/stderr → Log collector (Fluent Bit) → Loki/Elasticsearch
應用程式從不管理日誌檔案。只需寫入標準輸出即可。
因素 12：管理流程
將管理/管理任務作為一次性流程運行。
# Database migration
kubectl exec -it order-service-pod -- ./manage.py migrate
# Data cleanup
kubectl run --rm -it cleanup --image=myapp -- python cleanup_script.py
4.2 超越十二因數
Kevin Hoffman 在《Beyond the Twelve-Factor App》一書中增加了 3 個額外因素：
- 因素 13：API First — 先設計 API 合約，然後實作
- 因素 14：遙測 — 需要指標、日誌、追蹤
- 因素 15：身分驗證與授權 — 安全源自設計，而非事後考慮
5. 雲原生景觀
CNCF 維護著雲原生景觀－整個雲原生技術堆疊的地圖：
┌─────────────────────────────────────────────────────────────┐
│ Cloud Native Landscape │
├───────────────┬──────────────┬───────────────┬──────────────┤
│ App Definition│ Orchestration│ Runtime │ Provisioning│
│ & Development │ & Management │ │ │
│ │ │ │ │
│ - Helm │ - Kubernetes │ - containerd │ - Terraform │
│ - gRPC │ - Istio │ - CRI-O │ - Ansible │
│ - OpenAPI │ - ArgoCD │ - Envoy │ - Crossplane │
│ - Dapr │ - Keda │ - CoreDNS │ - Pulumi │
├───────────────┼──────────────┼───────────────┼──────────────┤
│ Observability │ Serverless │ Security │ Database │
│ │ │ │ │
│ - Prometheus │ - Knative │ - Vault │ - Vitess │
│ - Grafana │ - OpenFaaS │ - Falco │ - TiDB │
│ - Jaeger │ - Dapr │ - OPA │ - CockroachDB│
│ - Loki │ │ - Trivy │ │
└───────────────┴──────────────┴───────────────┴──────────────┘
6. 總結
| 概念 | 外送 |
|---|---|
| 雲端原生 | 建立利用雲端的應用程式的方法，而不僅僅是在雲端上運行 |
| 十二因素 | 可移植、可擴展、生產就緒的應用程式設計的 12 項原則 |
| 不可變的基礎設施 | 不修伺服器，徹底更換 |
| 無狀態設計 | 對外服務狀態，app實例可隨時更換 |
| 預設可觀察 | 指標、日誌、追蹤從一開始就是強制性要求 |
下一篇文章：容器和 Docker — 雲端原生應用程式打包平台，從 Dockerfile 最佳實務到映像安全。