xDev Asia

雲原生原則、微服務 vs 單體式架構、Service Mesh、12-Factor App、不可變基礎設施與雲原生設計模式。

1. 雲原生 — CNCF 定義

根據 CNCF（Cloud Native Computing Foundation），雲原生是在公有雲、私有雲、混合雲等動態環境中建置和執行可擴展應用程式的方式，使用：容器、微服務、宣告式 API、不可變基礎設施。

原則	含義	範例
容器化	將應用程式與相依套件打包	Docker image
動態編排	自動排程、擴展、自我修復	Kubernetes
微服務	鬆耦合、單一職責	Auth Service、Payment Service
宣告式 API	描述期望狀態，而非步驟	kubectl apply -f deployment.yaml
不可變基礎設施	不修改執行中的系統；改為替換	新映像版本 → Rolling Update

2. 微服務 vs 單體式架構

MONOLITH                          MICROSERVICES
─────────────────────             ──────────────────────────────
┌──────────────────┐              ┌────────┐ ┌────────┐ ┌─────┐
│  Auth    │  UI   │              │  Auth  │ │  Cart  │ │  UI │
│  Cart    │  API  │              │Service │ │Service │ │Svc  │
│  Payment │  DB   │              └────────┘ └────────┘ └─────┘
└──────────────────┘                   │          │         │
  Deploy as 1 unit                     └─── API Gateway ───┘
                                            │
                                       Client/Browser

面向	單體式	微服務
部署	全有或全無	每個服務獨立部署
擴展	整個應用一起擴展	僅擴展瓶頸服務
複雜度	低（單一程式碼庫）	高（分散式）
故障隔離	一個錯誤影響全部	故障侷限在服務內
技術選型	單一技術堆疊	多語言（每個服務最佳工具）

3. 12-Factor App

12-Factor App 方法論定義了雲原生應用的最佳實踐：

#	因素	雲原生實踐
1	Codebase	每個應用 1 個 repo，多次部署
2	Dependencies	明確宣告（package.json、go.mod）
3	Config	儲存在環境中（ConfigMap、Secrets）
4	Backing services	DB、快取 = 透過 URL 附加的資源
5	Build/Release/Run	嚴格分離（CI 建置，CD 部署）
6	Processes	無狀態程序，狀態儲存在外部
7	Port binding	透過連接埠匯出服務（無 Web 伺服器層）
8	Concurrency	透過程序模型擴展（HPA）
9	Disposability	快速啟動、優雅關閉
10	Dev/Prod parity	跨環境使用相同工具/服務
11	Logs	視為事件串流（stdout，非檔案）
12	Admin processes	以 Job 執行一次性管理任務

考試重點： 因素 3、6、9、11 在 KCNA 考題中經常出現。因素 3（環境中的組態）→ ConfigMap/Secret。因素 6（無狀態）→ 使用外部儲存的原因。因素 11（日誌為串流）→ stdout → 日誌聚合器。

4. Service Mesh

當微服務增多時，需要管理：mTLS、重試、斷路器、可觀測性。Service Mesh 透過在每個 Pod 中注入 Sidecar Proxy 來解決這些問題。

Without Service Mesh:          With Service Mesh (Istio):
  App A ──────────────► App B    App A ──► [Envoy] ──► [Envoy] ──► App B
  (manual TLS, retry code)         sidecar           sidecar
                                 (auto mTLS, metrics, retry, tracing)

功能	Service Mesh 提供
mTLS 雙向驗證	自動加密服務間流量
流量管理	Canary、A/B、加權路由
可觀測性	自動指標、追蹤、存取日誌
韌性	重試、逾時、斷路器

5. 速查表

考試問題	答案
CNCF 定義的雲原生包含什麼？	容器、微服務、宣告式 API、不可變基礎設施
按 12-Factor 組態應儲存在哪？	環境變數（不要硬編碼）
按 12-Factor 日誌應如何處理？	視為串流（stdout/stderr）
Service Mesh 在 Pod 中注入什麼？	Sidecar Proxy（Envoy）
微服務擴展哪個部分？	僅擴展有瓶頸的服務

6. 練習題

Q1: 根據 12-Factor App 方法論，應用程式應該如何儲存資料庫連接字串？

A) 硬編碼在原始碼中
B) 存放在提交到儲存庫的設定檔中
C) 作為環境變數（Kubernetes ConfigMap 或 Secret） ✓
D) 在容器映像中作為建置參數

解析：因素 3（Config）指出：「將組態儲存在環境中。」在 Kubernetes 中，這意味著使用 ConfigMap 存放非敏感組態，Secret 存放敏感值，以環境變數注入。

Q2: 在微服務架構中使用 Service Mesh 的主要好處是什麼？

A) 取代 Kubernetes 進行容器編排
B) 提供基礎設施層級的網路功能（mTLS、重試、可觀測性），無需修改應用程式碼 ✓
C) 儲存應用程式組態
D) 在容器重啟後保存應用程式狀態

解析：Service Mesh 透過 Sidecar Proxy 將跨領域關注點（安全、可觀測性、韌性）移至基礎設施層。開發人員不需要在每個服務中實作重試邏輯或 mTLS。

Q3: 「不可變基礎設施」與傳統基礎設施的區別特徵是什麼？

A) 伺服器從不重新啟動
B) 替換執行中的系統而非就地修改 ✓
C) 組態變更需要人工審批
D) 基礎設施僅使用 YAML 檔案定義