隨著業務規模的擴大，微服務架構的擴充套件性就變得至關重要。水平擴充套件透過增加服務例項數量來提升系統容量和可用性，而彈性擴充套件則根據負載變化自動調整資源，有效提升資源利用率。Kubernetes 和 Terraform 是實作這些策略的常用工具，它們分別負責容器協調和基礎設施管理。資料函式庫的擴充套件策略也需要仔細考量，避免單點瓶頸，確保資料函式庫效能能跟上服務擴充套件的腳步。此外，Blue-Green 佈署策略能有效降低更新風險，實作不停機佈署。
水平擴充套件的優點
- 靈活性: 水平擴充套件允許系統根據需要動態調整容量，無需對現有硬體進行大規模升級或更換。
- 可擴充套件性: 透過新增虛擬機器，系統可以輕鬆地增加容量，以應對日益增長的使用者需求。
- 高用性: 即使個別虛擬機器出現故障，叢集也可以繼續運作，確保系統的整體可用性和可靠性。
實踐案例
在實際應用中，水平擴充套件被廣泛用於各種需要高效能和高用性的場景，例如網站服務、雲端運算平臺和大資料處理等領域。透過新增虛擬機器，系統可以快速應對變化的需求，提高整體效率和使用者經驗。
Mermaid 圖表
flowchart TD
A[使用者請求] --> B[負載平衡]
B --> C[虛擬機器1]
B --> D[虛擬機器2]
B --> E[虛擬機器3]
C --> F[資料函式庫]
D --> F
E --> F
圖表翻譯
上述 Mermaid 圖表展示了一個簡單的叢集架構，其中使用者請求透過負載平衡器分發到多個虛擬機器上。每個虛擬機器都可以存取同一個資料函式庫，實作資源分享和合作。這種架構可以根據需要進行水平擴充套件，新增更多的虛擬機器以提高系統的整體效能和容量。
12.3.3 個別微服務的水平擴充套件
當個別微服務面臨效能瓶頸時，我們可以透過水平擴充套件來分配其負載至多個例項。這個過程如圖 12.13 所示，透過增加計算資源、記憶體和儲存空間來增強微服務的工作能力。
實作水平擴充套件
要實作水平擴充套件，可以透過 Kubernetes 的佈署設定（Deployment）來完成。以下是佈署設定檔的一部分，設定了微服務的複製數（replicas）為 3：
apiVersion: apps/v1
kind: Deployment
metadata:
name: example-deployment
spec:
replicas: 3
selector:
matchLabels:
app: example
template:
metadata:
labels:
app: example
spec:
containers:
- name: example
image: example/image
ports:
- containerPort: 80
在這個設定中，replicas 欄位被設定為 3，表示這個微服務將會被複製三次，分別佈署在不同的節點上，以達到負載平衡和容錯的效果。
結合 Terraform 進行叢集管理
除了使用 Kubernetes 的佈署設定外，也可以透過 Terraform 進行叢集管理。以下是一個使用 Terraform 的範例，增加節點池的大小到 6：
resource "azurerm_kubernetes_cluster" "example" {
name = "example-aks"
location = "East US"
resource_group_name = "example-resource-group"
dns_prefix = "exampleaks"
default_node_pool {
name = "default"
node_count = 6
vm_size = "Standard_B2ms"
}
}
這個 Terraform 設定檔增加了節點池的大小到 6，為叢集提供更多的計算資源。透過這種方式，可以輕鬆地管理和擴充套件 Kubernetes 叢集。
圖表翻譯
圖 12.13 個別微服務的水平擴充套件
這個圖表展示瞭如何透過水平擴充套件來增強個別微服務的工作能力。透過增加計算資源、記憶體和儲存空間，微服務可以處理更大的工作負載。這個過程可以透過 Kubernetes 的佈署設定或 Terraform 的叢集管理來實作。
此圖示
圖 12.13 顯示了水平擴充套件的過程，包括增加計算資源、記憶體和儲存空間。這個過程可以透過 Kubernetes 的佈署設定或 Terraform 的叢集管理來實作，從而增強微服務的工作能力和提高系統的可靠性。
水平擴充套件和彈性擴充套件
水平擴充套件是一種將單一微服務複製多次的技術，以增加系統的整體容量和可用性。這種方法可以確保即使個別微服務發生故障，系統仍能繼續運作。
在水平擴充套件中，微服務至少被複製三次，以確保有足夠的備份來應對故障和增加的工作負載。當有新的請求進入系統時，負載平衡器會將請求分配給多個微服務例項，以確保沒有單一點故障。
水平擴充套件的優點
- 提高系統的整體容量和可用性
- 減少單一點故障的風險
- 可以根據工作負載的變化動態調整系統的容量
實作水平擴充套件
水平擴充套件可以透過修改 Kubernetes 的佈署組態檔案來實作。以下是一個簡單的範例：
apiVersion: apps/v1
kind: Deployment
metadata:
name: gateway
spec:
replicas: 3
selector:
matchLabels:
app: gateway
template:
metadata:
labels:
app: gateway
spec:
containers:
- name: gateway
image: gateway:latest
ports:
- containerPort: 80
在這個範例中，replicas 欄位被設定為 3，表示微服務將被複製三次。
彈性擴充套件
彈性擴充套件是一種自動和動態地根據工作負載的變化調整系統容量的技術。這種方法可以確保系統在低負載時節省資源，在高負載時增加資源，以滿足工作負載的需求。
彈性擴充套件可以透過修改 Terraform 的組態檔案來實作。以下是一個簡單的範例：
resource "azurerm_kubernetes_cluster" "example" {
name = "example-aks-cluster"
resource_group_name = azurerm_resource_group.example.name
location = azurerm_resource_group.example.location
dns_prefix = "exampleaks"
default_node_pool {
name = "default"
node_count = 3
vm_size = "Standard_DS2_v2"
}
}
在這個範例中，default_node_pool 的 node_count 欄位被設定為 3，表示初始節點數為 3。
彈性擴充套件的優點
- 自動調整系統容量以滿足工作負載的需求
- 節省資源和成本
- 提高系統的整體效率和可用性
12.3.5 個別微服務的彈性擴充套件
我們也可以在個別微服務層級啟用彈性擴充套件。清單 12.9 是一個 Kubernetes 資源的範例，可以佈署到您的叢集中，以給予閘道微服務「可爆發」能力。微服務的複本數會動態擴充套件和收縮以滿足微服務的變化工作量（活動爆發）。若要了解更多關於 Kubernetes 中的 Pod 自動擴充套件，請參考 apiVersion: autoscaling/v2。
apiVersion: autoscaling/v2
kind: HorizontalPodAutoscaler
metadata:
name: gateway
spec:
scaleTargetRef:
apiVersion: apps/v1
kind: Deployment
name: gateway
minReplicas: 3
maxReplicas: 20
內容解密：
此範例定義了一個 HorizontalPodAutoscaler 物件，目的是為了控制 gateway 微服務的複本數。minReplicas 和 maxReplicas 分別設定了微服務的最小和最大複本數，允許它根據工作量動態調整。這種方法使得系統能夠在需求增加時自動擴充套件，並在需求減少時收縮，從而提高資源利用率和系統的彈性。
12.3.6 資料函式庫的擴充套件
最後，我們來看一下資料函式庫的擴充套件。在第 4 章中，你可能記得我們曾經討論過每個微服務應該有自己的資料函式庫（見第 4.5.4 節）。分享資料函式庫之間的微服務存在多個問題，其中一個問題是它嚴重限制了我們的擴充套件能力。請考慮圖 12.14 所示的情況，我們有多個微服務分享一個資料函式庫。這是一個未來的擴充套件噩夢！這些微服務並不獨立。分享的資料函式庫是一個固定的整合點，它可能成為一個嚴重的效能瓶頸。如果微服務之間分享資料，它們將緊密耦合，這嚴重限制了我們的擴充套件能力。
圖表翻譯：
圖 12.14 顯示了多個微服務分享單一資料函式庫的情況。這種架構會導致資料函式庫成為一個瓶頸，因為所有微服務都依賴於同一個資料函式庫。這種分享會限制每個微服務的獨立性和擴充套件能力，從而導致系統整體的擴充套件受限。因此，在設計微服務架構時，盡量避免分享資料函式庫，除非是為了同一個微服務的複製品。
圖表：
graph LR
A[微服務1] -->|分享|> B[資料函式庫]
C[微服務2] -->|分享|> B
D[微服務3] -->|分享|> B
B -->|瓶頸|> E[系統效能]
圖表翻譯：
此圖表顯示了多個微服務分享同一個資料函式庫的情況，以及這如何導致系統效能瓶頸。每個微服務都依賴於同一個資料函式庫，這使得資料函式庫成為一個單點故障和效能瓶頸。當多個微服務競爭資料函式庫資源時，系統的整體效能將受到影響。因此，為了避免這種情況，應盡量避免分享資料函式庫，並為每個微服務提供獨立的資料函式庫。
微服務的效能擴充套件
在設計微服務架構時，為了確保未來的效能擴充套件能力，我們需要謹慎考慮每個微服務的資料函式庫設計。若我們將多個微服務繫結到同一個資料函式庫，將會限制未來的擴充套件能力。這種設計方式可能會導致效能瓶頸，從而破壞我們辛苦打造的「易於擴充套件」的微服務架構。
每個微服務應有自己的資料函式庫
理想的情況是，每個微服務都應該有自己的獨立資料函式庫，如圖 12.15 所示。這種設計使得每個微服務之間完全獨立，從而可以輕鬆地進行水平擴充套件。當某個微服務的負載增加時，我們可以單獨對其進行擴充套件，而不會影響到其他微服務。
資料函式庫伺服器的選擇
雖然每個微服務需要自己的資料函式庫，但這並不意味著我們需要為每個資料函式庫設立獨立的資料函式庫伺服器。管理資料函式庫伺服器的成本是存在的，尤其是在初期階段，我們通常希望保持這部分的成本最低。因此，使用單一的資料函式庫伺服器來容納所有微服務的資料函式庫是完全可行的，如圖 12.16 所示。這樣不僅簡化了架構，也降低了初期的成本。
未來的擴充套件
當某個微服務的資料函式庫負載增大時，我們可以輕鬆地建立新的資料函式庫伺服器，並將該資料函式庫遷移到新的伺服器上，如圖 12.17 所示。根據需要，我們可以為任何需要額外計算資源、記憶體或儲存空間的資料函式庫建立專用伺服器。
圖表翻譯：
圖 12.15 展示了每個微服務都應該有自己的獨立資料函式庫，以確保微服務之間的獨立性和易於擴充套件性。 圖 12.16 顯示了為了簡化架構和降低成本，我們可以使用分享的資料函式庫伺服器來容納所有微服務的資料函式庫。 圖 12.17 說明瞭當某個微服務的資料函式庫負載增大時，我們可以建立新的資料函式庫伺服器並將資料函式庫遷移到新的伺服器上，以滿足其額外的需求。
內容解密：
在設計微服務架構時，資料函式庫的設計是一個非常重要的方面。為了確保未來的效能擴充套件能力，每個微服務應該有自己的獨立資料函式庫。雖然這可能會增加初期的複雜度和成本，但從長遠來看，這種設計可以帶來更好的擴充套件性和靈活性。透過使用分享的資料函式庫伺服器，我們可以在初期階段降低成本，而當需要時，又可以輕鬆地進行擴充套件。這種設計方法不僅滿足了微服務的獨立性和易於擴充套件性的需求，也為未來的效能最佳化和資源分配提供了良好的基礎。
資料函式庫擴充套件方法
隨著應用程式的成長，我們需要考慮如何擴充套件資料函式庫，以滿足日益增長的需求。有一種簡單且經濟的方法是使用分享資料函式庫伺服器（Shared Database Server），在同一臺伺服器上執行多個獨立的資料函式庫。這種方法可以快速實作，但當資料函式庫過大或伺服器過載時，就需要考慮其他擴充套件方案。
分散式資料函式庫
另一種選擇是使用分散式資料函式庫（Sharding），這種方法可以將單一的大型資料函式庫分散到多臺虛擬機器（VM）上。MongoDB 就是一種支援資料函式庫分散的 NoSQL 資料函式庫。在使用分散式資料函式庫時，我們可以根據需要動態增加或減少 VM 數量，以確保資料函式庫的可擴充套件性和效率。
避免過早擴充套件
在進行擴充套件之前，需要仔細評估是否真正需要。過早擴充套件不僅會增加成本，還可能導致系統複雜性增加和維護難度提高。因此，應該根據實際需求進行擴充套件，避免為了未來可能的需求而進行不必要的擴充套件。
圖表翻譯：
graph LR
A[分享資料函式庫伺服器] -->|過載|> B[新增資料函式庫伺服器]
B -->|分散資料函式庫|> C[多臺虛擬機器]
C -->|動態調整|> D[最佳化資料函式庫效能]
內容解密：
在上述流程中，我們首先評估分享資料函式庫伺服器是否過載。如果過載，則需要新增資料函式庫伺服器以分散負載。接下來，透過將資料函式庫分散到多臺虛擬機器上，可以動態調整資源以最佳化資料函式庫效能。這種方法不僅可以提高系統的可擴充套件性，也可以降低維護成本。
圖表示：
圖 12.17 展示瞭如何透過新增資料函式庫伺服器和分散資料函式庫來擴充套件應用程式。當分享資料函式庫伺服器過載或特定資料函式庫太大時，可以新增資料函式庫伺服器並將資料函式庫遷移到新伺服器，以分散負載並提高效率。這種方法可以根據實際需求動態調整，確保系統的可擴充套件性和效率。
分散式資料函式庫架構
在處理大型資料函式庫時，單一伺服器可能無法滿足儲存和計算需求。為瞭解決這個問題，MongoDB 提供了一種稱為分片（Sharding）的功能。分片允許將一個大型資料函式庫分散到多個虛擬機器（VM）上，每個虛擬機器被稱為一個分片（Shard）。
分片架構
在分片架構中，每個分片包含了資料函式庫中的一部分資料。這意味著每個分片只需要儲存和處理整個資料函式庫中的一小部分資料，從而減輕了單一伺服器的負擔。
graph LR
A[資料函式庫] -->|分片|> B[分片1]
A -->|分片|> C[分片2]
A -->|分片|> D[分片3]
B -->|資料|> E[資料1]
C -->|資料|> F[資料2]
D -->|資料|> G[資料3]
內容解密：
上述 Mermaid 圖表展示瞭如何將一個大型資料函式庫分散到多個分片中。每個分片包含了資料函式庫中的一部分資料，從而實作了資料的分散式儲存和計算。
分片伺服器
在分片架構中，需要有一個單一的伺服器負責將資料和查詢分佈到所有的分片中。這個伺服器被稱為分片伺服器（Shard Server）。分片伺服器的主要功能是：
- 將資料分佈到各個分片中
- 將查詢路由到相應的分片中
graph LR
A[分片伺服器] -->|路由查詢|> B[分片1]
A -->|路由查詢|> C[分片2]
A -->|路由查詢|> D[分片3]
B -->|處理查詢|> E[結果1]
C -->|處理查詢|> F[結果2]
D -->|處理查詢|> G[結果3]
圖表翻譯：
上述 Mermaid 圖表展示了分片伺服器如何將查詢路由到各個分片中。每個分片接收到查詢後，會處理查詢並傳回結果給分片伺服器。分片伺服器然後會將結果傳回給使用者。
分片的優點
分片架構有以下優點：
- 水平擴充套件性：分片允許資料函式庫水平擴充套件，從而能夠處理更大的資料量和更高的流量。
- 提高效能：由於每個分片只需要處理整個資料函式庫中的一小部分資料，因此可以提高查詢和寫入的效能。
- 提高用性：如果一個分片失敗，其他分片可以繼續提供服務，從而提高了整個系統的可用性。
然而，分片架構也有一些複雜性和挑戰，例如：
- 複雜性：分片架構比單一伺服器架構更複雜，需要更多的組態和管理。
- 一致性：保證各個分片之間的資料一致性是一個挑戰。
因此，在設計和實作分片架構時，需要仔細考慮和權衡各個因素，以確保系統的可擴充套件性、效能和可用性。
12.4 減輕玄貓帶來的問題
在設計和架構應用程式時，過度複雜化可能會導致未來擴充套件性問題。通常，我們很難預測未來的需求和使用方式，因此盲目地增加複雜性可能會使應用程式更難以維護和擴充套件。
12.4.1 自動化測試和佈署
自動化佈署是微服務架構中的一個重要環節。透過自動化測試和佈署，我們可以確保應用程式的更新可以快速、安全地推播到生產環境。自動化測試可以幫助我們在早期階段發現問題，避免將錯誤的程式碼推播到生產環境。
12.4.2 分支保護
為了防止開發人員直接將錯誤的程式碼推播到生產環境，我們可以啟用分支保護機制。例如，GitHub 可以設定為禁止直接推播程式碼到特定的分支，開發人員必須提交提取請求，並經過自動化測試和審查後才能合並程式碼。
12.4.3 測試環境佈署
如果開發人員不能直接將程式碼推播到生產環境，他們需要一個測試環境來驗證程式碼。測試環境應該與生產環境盡可能相似，以便於發現潛在問題。
12.4.4 滾動更新
Kubernetes 提供了滾動更新功能，允許我們逐步更新微服務。例如，如果我們有三個副本的閘道器微服務，我們可以先更新其中一個副本，如果更新成功，則繼續更新下一個副本。這樣可以減少更新過程中出錯的風險。
12.4.5 藍綠佈署
藍綠佈署是一種技術，允許我們建立兩個生產環境：藍色環境和綠色環境。藍色環境是目前的生產環境，而綠色環境是新的、正在開發的環境。當新的環境準備就緒後，我們可以切換 DNS 記錄，將流量從藍色環境切換到綠色環境。如果出現問題，我們可以快速切換回藍色環境。
這種方法需要保持叢集的無狀態性，這樣才能夠輕鬆地在不同環境之間切換。透過藍綠佈署，我們可以在不中斷服務的情況下進行風險較大的變更和實驗。
環境隔離與DNS路由
在軟體開發過程中，環境隔離是一個非常重要的概念。它允許我們同時維護多個不同的環境，例如生產環境（Production）、測試環境（Testing）和開發環境（Development）。這樣做的好處是可以讓開發人員和測試人員在不影響生產環境的情況下進行工作。
環境設定
假設我們有兩個環境：藍色環境（Blue）和綠色環境（Green）。藍色環境是導向客戶的生產環境，而綠色環境則是用於開發和測試的。這樣的設定可以確保客戶使用的環境是穩定的，而開發人員和測試人員可以在綠色環境中進行新的功能開發和測試，同時不會影響到客戶的使用。
DNS路由
網域名稱系統（DNS）在這裡扮演著一個重要的角色。透過DNS路由，可以將應用程式的網域名稱指向不同的環境。例如，客戶存取的網域名稱可以被路由到藍色環境，而開發人員和測試人員則可以透過不同的網域名稱或內網地址存取綠色環境。
實際應用
在實際應用中，這種環境隔離和DNS路由的設定可以如下圖所示：
flowchart TD
A[客戶] -->|存取|> B[藍色環境]
C[開發人員和測試人員] -->|工作|> D[綠色環境]
E[DNS] -->|路由|> B
E -->|路由|> D
圖表翻譯：
上述流程圖展示了客戶如何透過DNS路由存取藍色環境，而開發人員和測試人員則如何在綠色環境中工作。這種設定可以有效地隔離不同環境，避免開發和測試工作對生產環境造成影響。
雙環境佈署：Blue-Green佈署策略
在軟體開發和佈署的過程中，實作無停機更新一直是一個挑戰。為瞭解決這個問題，Blue-Green佈署策略被廣泛採用。這種策略允許開發團隊在不中斷服務的情況下，實作新版本軟體的平滑過渡。
Blue環境
Blue環境代表著目前正在執行的生產環境。這是客戶們正在使用的版本，所有的請求和流量都指向這個環境。Blue環境是穩定的、已經測試過的版本，確保了業務的連續性。
Green環境
Green環境則是新的、準備好要上線的版本。它包含了最新的功能、修復和更新。這個環境與Blue環境是平行的，兩者之間沒有直接的關聯，直到切換的時候。
切換過程
當新版本的軟體準備好之後，開發團隊會將其佈署到Green環境中。這時，兩個環境（Blue和Green）都存在，但只有Blue環境對外提供服務。當所有準備工作就緒，包括測試和驗證新版本的正確性後，DNS（網域名稱系統）就會被更新，以便將客戶請求從Blue環境重新導向到Green環境。
DNS的作用
DNS在這個過程中扮演著關鍵角色。透過更新DNS記錄，開發團隊可以控制流量的方向。當DNS更新完成後，新的客戶請求將被路由到Green環境，而現有的連線仍然保持在Blue環境中，直到它們超時或被重定向。
開發者和測試人員
開發者和測試人員在這個過程中發揮著重要作用。他們負責確保新版本在Green環境中的正確性和穩定性。透過在Green環境中進行測試，他們可以在不影響生產環境（Blue）的情況下，識別和修復問題。
客戶切換
一旦Green環境被驗證為可用且穩定，客戶就會被切換到新的環境中。這個過程通常是透明的，客戶不會感受到任何中斷或停機時間。透過這種方式，Blue-Green佈署策略實作了無停機更新，最大限度地減少了對業務的影響。
基礎安全概述
在軟體開發中，安全性是一個至關重要的議題，尤其是在微服務架構中。即使是初期的開發階段，安全性也不能被忽視。為了確保應用程式和資料的安全，我們需要使用各種安全技術，例如身份驗證、授權和加密。
基礎安全概念
每個應用程式都需要某種程度的安全性，即使資料不敏感，也需要防止未經授權的修改。同樣，即使系統不是關鍵基礎設施，也需要防止攻擊者破壞系統和流程。
身份驗證和授權
身份驗證是確定使用者身份的過程，而授權則是確定使用者是否有權存取特定資源的過程。在微服務架構中，身份驗證和授權可以在入口點（例如閘道器）進行，也可以在每個微服務中進行。
加密
加密是將明文資料轉換為金鑰資料的過程，以防止未經授權的存取。在微服務架構中，加密可以用於保護資料在傳輸和儲存中的安全。
信任模型
信任模型是指系統中各個元件之間的信任關係。在微服務架構中，有兩種常見的信任模型：內部信任模型和零信任模型。
內部信任模型
內部信任模型假設所有微服務之間都是可信的，只有入口點需要進行身份驗證和授權。這種模型簡單易行，但可能不適合高安全性需求的應用程式。
零信任模型
零信任模型假設所有微服務之間都是不可信的，需要對所有連線進行身份驗證和授權。這種模型更安全，但也更複雜。
Kubernetes 和安全性
Kubernetes 是一個流行的容器協調系統，它提供了許多安全功能，例如網路政策和秘密管理。然而，Kubernetes 本身並不能保證應用程式的安全性，需要開發人員和維運人員共同努力來確保系統的安全。
從系統架構的演進來看，水平擴充套件已成為構建高用性、高彈性系統的關鍵技術。本文深入探討了水平擴充套件的優點、實踐案例以及結合Kubernetes、Terraform等工具的佈署策略，並分析了資料函式庫擴充套件的不同方法，包括分享資料函式庫伺服器、分散式資料函式庫以及MongoDB Sharding技術。實務上，採用水平擴充套件策略的同時，也必須考量資料函式庫的擴充套件性，避免資料函式庫成為效能瓶頸。展望未來，隨著雲原生技術的普及，預期水平擴充套件將與自動化測試、佈署、藍綠佈署等DevOps實踐更緊密結合，進一步提升系統的可靠性和彈性。對於追求高效能和高用性的企業而言，深度理解並應用水平擴充套件技術至關重要。玄貓認為，結合自動化工具和最佳實務，水平擴充套件將持續賦能企業構建更具競爭力的應用系統。
