本文件介紹了一些模式和做法，可用於建立具備彈性和可擴充性的應用程式，這也是許多現代架構練習的兩個重要目標。設計完善的應用程式會隨著需求的增減而擴充或縮減，並具備足以承受服務中斷的彈性。如要建構及運作符合這些規定的應用程式，您必須謹慎規劃和設計。
擴充性：因應需求調整容量
「擴充性」是指系統能否藉由增減資源來因應不斷變化的工作量。舉例來說，可擴充的網路應用程式不論使用者多寡，都能應付自如，並能從容應對流量的高峰期和低谷期。
彈性調整應用程式所消耗的資源，是遷移至雲端的重要業務動力。如果設計得當，您就能移除使用率過低的資源，進而降低成本，而且不會影響到效能或使用者體驗。遭遇流量較高的狀況時，也同樣能透過增加資源來維持良好的使用者體驗。如此一來，應用程式只會耗用因應需求的必要資源。
Google Cloud 提供的產品和功能可協助您建構可擴充且高效能的應用程式：
- Compute Engine 虛擬機器和 Google Kubernetes Engine (GKE) 叢集會整合自動調整器，讓您根據自訂的指標增加或減少資源用量。
- Google Cloud的無伺服器平台提供代管運算、資料庫和其他服務，可從零快速擴充至高要求量，而且您只需為實際使用的資源付費。
- BigQuery、Spanner 和 Bigtable 等資料庫產品，可在處理大量資料時維持一致的效能。
- Cloud Monitoring 會提供應用程式和基礎架構的指標，協助您做出以資料為依據的擴充決策。
復原彈性：設計可承受故障情況
高彈性應用程式是指在系統元件故障的情況下，仍能繼續運作的應用程式。為了確保系統具備彈性，您必須在架構的所有層級進行規劃。這會影響您建構基礎架構和網路的方式，以及設計應用程式和資料儲存空間的方式。復原力也延伸至人與文化。
建構及操作彈性應用程式並不容易。這點對於分散式應用程式尤其適用，因為這類應用程式可能包含多層基礎架構、網路和服務。錯誤和服務中斷是難免的，因此您必須持續改善應用程式的彈性。您可以透過謹慎規劃，提升應用程式抵禦故障的彈性。透過適當的程序和組織文化，您也可以從失敗中學習，進一步提高應用程式的復原能力。
Google Cloud 提供工具和服務，協助您建構高可用性和彈性的應用程式：
- Google Cloud 服務可在全球地區和區域中使用，讓您部署應用程式時，能盡可能達成可用性目標。
- 您可以將 Compute Engine 執行個體群組和 GKE 叢集分散於地區內的不同可用區域，並加以管理。
- Compute Engine 區域性永久磁碟會在區域內的各個可用區中同步複製。
- Google Cloud 提供多種負載平衡選項，可用於管理應用程式流量，包括全域負載平衡，可將流量導向最接近使用者的健康區域。
- Google Cloud的無伺服器平台包含提供內建備援和負載平衡功能的代管運算和資料庫產品。
- Cloud Build 會在 Google Cloud 上執行建構作業，並讓您在 App Engine、Compute Engine、Cloud Run 和 GKE 等平台上部署。
- Cloud Monitoring 會提供應用程式和基礎架構的指標，協助您根據資料做出關於應用程式效能和健康狀態的決策。
驅動因子和限制
改善應用程式的可擴充性和韌性有不同的需求和動機。此外，也可能有限制，限制您達成可擴充性和韌性目標的能力。這些需求和限制的相對重要性會因應用程式類型、使用者設定檔，以及貴機構的規模和成熟度而異。
驅動因素
為協助您優先處理需求，請考量貴機構不同部門的驅動因素。
業務驅動力
在業務上常見的驅動因子包括：
- 降低成本和資源用量。
- 盡量減少應用程式停機時間。
- 確保在使用量高峰期間，能滿足使用者需求。
- 提升服務品質與可用性。
- 確保在服務中斷期間維持使用者體驗和信任。
- 提高靈活性和敏捷性，以因應不斷變化的市場需求。
開發驅動程式
在開發方面常見的驅動因子包括：
- 盡量減少調查失敗問題所花費的時間。
- 增加開發新功能的時間。
- 透過自動化機制減少重複性工作。
- 使用最新的業界模式和做法建構應用程式。
營運推力
在營運方面的需求和限制包括：
- 減少需要人為介入的失敗頻率。
- 提高自動復原失敗功能的效能。
- 透過自動化機制減少重複性工作。
- 將任何特定元件故障的影響降至最低。
限制
限制可能會限制您提高應用程式可擴充性和彈性的能力。請確認您的設計決策不會引入或導致下列限制：
- 依賴難以擴充的硬體或軟體。
- 依附元件是難以在高可用性設定中運作的硬體或軟體。
- 應用程式之間的依附元件。
- 授權限制。
- 開發和營運團隊缺乏技能或經驗。
- 機構組織對自動化功能的反對。
模式和做法
本文其餘部分會定義模式和做法，協助您建構彈性且可擴充的應用程式。這些模式會影響應用程式生命週期的所有部分，包括基礎架構設計、應用程式架構、儲存空間選項、部署程序和組織文化。
這些模式中明顯有三個主題：
- 自動化。建構可擴充且有彈性的應用程式需要自動化功能。自動化基礎架構佈建、測試和應用程式部署作業，可提高一致性和速度，並盡可能減少人為錯誤。
- 鬆散耦合。將系統視為一組鬆散耦合的獨立元件，可提供彈性和復原能力。獨立性涵蓋實際發布資源的方式，以及如何建構應用程式和設計儲存空間。
- 以數據為準的設計。收集指標以瞭解應用程式行為至關重要。決定何時要擴充應用程式，或特定服務是否處於不健康狀態時，必須以資料為依據。指標和記錄應為核心功能。
自動化基礎架構佈建
透過自動化功能建立不可變動的基礎架構，改善環境一致性，並提高部署成功率。
將基礎架構視為程式碼
基礎架構即程式碼 (IaC) 是一項技術，鼓勵您以處理應用程式程式碼的方式處理基礎架構佈建和設定。您的佈建和設定邏輯會儲存在原始碼控制中，因此可供探索，並可進行版本管理和稽核。由於這項功能位於程式碼存放區，您可以利用持續整合和持續部署 (CI/CD) 管道，自動測試及部署設定的任何變更。
透過移除基礎架構佈建作業中的手動步驟，IaC 可盡量減少人為錯誤，並提高應用程式和環境的一致性和可重現性。這樣一來，採用 IaC 可提高應用程式的彈性。
Infrastructure Manager 可讓您自動建立及管理 Google Cloud 資源。或者，您也可以使用 Config Connector 透過 Kubernetes 技術和工作流程管理資源。Google Cloud 也內建支援熱門的第三方 IaC 工具，包括 Terraform、Chef 和 Puppet。
建立不可變動的基礎架構
不變基礎架構是一種理念，可發揮基礎架構即程式碼的優點。不可變動基礎架構規定資源在部署後不得修改。如果需要更新虛擬機器、Kubernetes 叢集或防火牆規則，您可以更新來源存放區中的資源設定。測試並驗證變更後，您可以使用新設定全面重新部署資源。換句話說，您不需調整資源，而是重新建立資源。
建立不可變更的基礎架構，可讓部署和回溯作業更可預測。它還可減輕變動基礎架構中常見的問題，例如設定偏移和雪花狀伺服器。採用不變基礎架構後，您可以進一步提升環境的一致性和可靠性。
高可用性設計
可用性是指服務可供使用的時間比例。可用性通常是整體服務健全度的關鍵指標。高可用性架構旨在盡可能提高服務可用性，通常會透過部署備援元件來達成此目標。簡單來說，要達到高可用性通常需要分散運算資源、負載平衡和複寫資料。
實際分發資源
Google Cloud 服務已在全球各地推出。這些位置分為「地區」和「區域」。您在這些地區和可用區部署應用程式的方式，會影響應用程式的可用性、延遲時間和其他屬性。如需更多資訊，請參閱選擇 Compute Engine 地區的最佳做法。
備援是指複製系統元件，以提高該系統的整體可用性。在 Google Cloud中，通常會將應用程式或服務部署至多個區域，甚至是多個區域，以達到備援目的。如果服務位於多個區域或地區，就能更有效因應特定區域或地區的服務中斷情形。雖然 Google Cloud 會盡力避免發生此類中斷情況，但某些事件無法預測，因此最好預先做好準備。
您可以使用 Compute Engine 代管執行個體群組，將虛擬機器執行個體分散至某個地區的多個區域，並以邏輯單元管理執行個體。 Google Cloud 還提供地區性永久磁碟，可自動將資料複製到某個地區的兩個區域。
同樣地，您也可以建立地區叢集，提高在 GKE 上部署的應用程式可用性和彈性。區域叢集會在區域內的多個可用區中，分散分配 GKE 控制層元件、節點和 Pod。由於控制層元件是分散式，因此即使一或多個 (但非全部) 區域發生服務中斷情況，您仍可繼續存取叢集的控制層。
選擇代管服務
您不需要獨立安裝、支援及操作一個應用程式堆疊中的所有部分，可以透過代管服務，以服務形式使用應用程式堆疊中的各個部分。例如，您可以使用 Cloud SQL 提供的 MySQL 資料庫，不必在虛擬機器 (VM) 上安裝及管理 MySQL 資料庫。接著，您會取得可用性的服務水準協議 (SLA)，並可依賴 Google Cloud 來管理資料複寫、備份和基礎架構。使用代管服務後，您就能縮短管理基礎架構的時間，將更多心力投注在改善應用程式的可靠性。
Google Cloud的許多代管運算、資料庫和儲存空間服務都提供內建備援功能，有助您達成可用性目標。許多這類服務都提供地區模式，這表示執行應用程式的基礎架構位於特定地區，且由 Google 代管，可為該地區內所有區域提供備援功能。如果某個區域無法使用，應用程式或資料會自動從該區域的其他區域提供服務。
某些資料庫和儲存服務也提供多地區可用性，也就是說，執行應用程式的基礎架構位於多個地區。多區域服務可以承受整個區域服務中斷的損失，但通常會導致延遲時間增加。
各層級的負載平衡
負載平衡功能可讓您將流量分配至資源群組。分配流量時，您可以確保個別資源不會在其他資源閒置時過載。大多數的負載平衡器也提供健康狀態檢查功能，協助確保流量不會路由至狀態不佳或無法使用的資源。
Google Cloud 提供多種負載平衡選項。如果應用程式在 Compute Engine 或 GKE 上執行，您可以根據流量的類型、來源和其他方面，選擇最合適的負載平衡器類型。詳情請參閱負載平衡總覽和 GKE 網路總覽。
或者，某些由 Google Cloud代管的服務 (例如 App Engine 和 Cloud Run) 會自動負載平衡流量。
負載平衡器通常會負責處理來自外部來源 (例如網頁或行動用戶端) 的請求。不過，在應用程式內的不同服務或層級之間使用負載平衡器，也可以提高彈性和韌性。 Google Cloud 提供內部第 4 層和第 7 層負載平衡器，以便執行這項操作。
下圖顯示外部負載平衡器將全球流量分配至兩個區域：us-central1 和 asia-east1。這張圖表也顯示內部負載平衡器將流量從網頁層分配到各個區域內部的內部層。
監控基礎架構和應用程式
在決定如何改善應用程式的彈性和可擴充性之前，您必須先瞭解應用程式的行為。您可以透過一組完整的相關指標和時間序列，瞭解應用程式的效能和健康狀態，進而找出潛在問題，避免造成服務中斷。這些工具還可協助您診斷及解決服務中斷問題。Google SRE 書籍中的「監控分散式系統」一節，提供了一些監控方法的概略說明。
除了提供應用程式健康狀況的洞察資料，指標還可用於控制服務的自動調度資源行為。
Cloud Monitoring 是 Google Cloud的整合式監控工具。Cloud Monitoring 會擷取事件、指標和中繼資料，並透過資訊主頁和快訊提供深入分析。大多數 Google Cloud 服務會自動將指標傳送至 Cloud Monitoring， Google Cloud 也支援許多第三方來源。Cloud Monitoring 也可做為熱門開放原始碼監控工具的後端，提供「單一資訊窗格」，方便您觀察應用程式。
在所有層級監控
在架構中收集各層級或各層級的指標，可全面掌握應用程式的健康狀態和行為。
基礎架構監控
基礎架構層級監控可為應用程式提供基準健康狀態和效能。這種監控方法可擷取 CPU 負載、記憶體用量和寫入磁碟的位元組數量等資訊。這些指標可能表示機器超載或無法正常運作。
除了自動收集的指標之外，Cloud Monitoring 也提供代理程式，可用於收集 Compute Engine VM 的詳細資訊，包括在這些機器上執行的第三方應用程式。
應用程式監控
建議您擷取應用程式層級指標。舉例來說，您可能想測量執行特定查詢所需的時間，或是執行相關服務呼叫序列所需的時間。您可以自行定義這些應用程式層級指標。這類指標可擷取內建 Cloud Monitoring 指標無法取得的資訊。應用程式層級指標可擷取更能反映重要工作流程的匯總條件，並可揭露低層基礎架構指標無法顯示的問題。
我們也建議您使用 OpenTelemetry 擷取應用程式層級指標。OpenTelemetry 為遙測資料提供單一開放式標準。使用 OpenTelemetry 收集及匯出雲端優先應用程式和基礎架構的資料。接著，您可以監控及分析匯出的遙測資料。
服務監控
對於分散式和微服務驅動型應用程式，請務必監控應用程式中不同服務和元件之間的互動情形。這些指標可協助您診斷問題，例如錯誤數量增加或服務間的延遲。
Cloud Service Mesh 是可在 Google Cloud 上使用的服務網格，可讓您在所選基礎架構中管理、觀察、評估及保護微服務，不論是否在Google Cloud上執行皆可。
端對端監控
端對端監控 (也稱為使用者監控) 會以使用者可見的方式測試外部可見行為。這類監控功能會檢查使用者是否能在您定義的門檻內完成重要操作。這類粗粒度監控可找出精細監控可能無法發現的錯誤或延遲，並顯示使用者感知的可用性。
公開應用程式的健康狀態
高可用性系統必須具備某種方法，可判斷系統的哪些部分運作正常且正常運作。如果某些資源似乎不健康，系統可以將要求傳送至其他位置。健康狀態檢查通常會從端點擷取資料，以判斷服務的狀態或健康狀況。
負載平衡器的主要責任之一，就是進行健康狀態檢查。建立與一組虛擬機器執行個體相關聯的負載平衡器時，您也必須定義健康狀態檢查。健康狀態檢查會定義負載平衡器如何與虛擬機器通訊，以評估特定執行個體是否應繼續接收流量。負載平衡器健康狀態檢查也可用於自動修復執行個體群組，例如重新建立健康狀態不良的機器。如果您在 GKE 上執行，並透過 ingress 資源負載平衡外部流量，GKE 會自動為負載平衡器建立適當的健康情況檢查。
Kubernetes 內建有效性和就緒性探測功能支援。這些探測可協助 Kubernetes 自動化調度管理器決定如何在叢集中管理 Pod 和要求。如果應用程式已部署至 Kubernetes，建議您透過適當的 Endpoints 向這些探針公開應用程式健康狀況。
制定關鍵指標
監控和健康檢查可提供應用程式行為和狀態的指標。下一步是分析這些指標，判斷哪些指標最能說明或影響應用程式。主要指標會因應用程式部署的平台和應用程式執行的工作而異。
您不太可能只找到一個指標，就能判斷是否要擴充應用程式，或是判斷特定服務是否不健康。通常是多種因素共同指出特定條件。您可以使用 Cloud Monitoring 建立自訂指標，協助擷取這些條件。Google SRE 書籍建議使用四大黃金訊號來監控面向使用者的系統：延遲、流量、錯誤和飽和。
也請考量對離群值的容忍度。使用平均值或中位數來評估健康或效能可能不是最佳選擇，因為這些指標可能會隱藏嚴重不平衡的情況。因此，請務必考量指標分布；99 百分位數可能比平均值更能提供有用的資訊。
定義服務等級目標 (SLO)
您可以使用監控系統收集到的指標，定義服務等級目標 (SLO)。服務等級目標可指定服務的目標效能或可靠度。SLO 是 SRE 做法的關鍵支柱，詳情請參閱 SRE 書籍中的「服務等級目標」一節，以及 SRE 工作手冊中的「實作 SLO」一節。
您可以使用服務監控功能，根據 Cloud Monitoring 中的指標定義 SLO。您可以針對 SLO 建立快訊政策，瞭解自己是否有違反 SLO 的風險。
儲存指標
監控系統提供的指標在短期內非常實用，可協助進行即時健康檢查或調查近期的問題。Cloud Monitoring 會保留數週的指標資料，以便滿足這些用途。
不過，儲存監控指標以利長期分析也有其價值。您可以透過歷史記錄採用資料導向的方法，改善應用程式架構。您可以使用中斷期間和中斷後收集到的資料，找出應用程式中的瓶頸和相互依賴情形。您也可以使用這些資料來建立及驗證有意義的測試。
您也可以利用歷來資料，驗證應用程式是否在重要期間協助達成業務目標。舉例來說，您可以利用這項資料分析應用程式在過去幾季或幾年內，在高流量宣傳活動期間的成長情形。
如要進一步瞭解如何匯出及儲存指標，請參閱 Cloud Monitoring 指標匯出作業解決方案。
決定資源調度設定檔
您希望應用程式能夠滿足使用者體驗和效能目標，但不必過度配置資源。
下圖顯示應用程式縮放設定檔的簡易表示方式。應用程式會維持資源的基準層級，並使用自動調度資源功能回應需求變化。
平衡成本和使用者體驗
決定是否要擴大應用程式規模時，基本上就是要平衡成本和使用者體驗。決定可接受的最低效能水準，並視需要設定上限。這些門檻會因應用程式而異，也可能因單一應用程式中的不同元件或服務而異。
舉例來說，面向消費者的網站或行動應用程式可能會有嚴格的延遲目標。研究顯示，即使延遲時間很短，也會對使用者對應用程式的看法造成負面影響，導致轉換次數和註冊人數減少。因此，請務必確保應用程式有足夠的服務能力，以便快速回應使用者要求。在這種情況下，執行更多網路伺服器的費用較高，但也許是合理的。
對於非業務關鍵的內部應用程式，使用者可能較能容忍輕微的延遲時間，因此成本與效能比率可能有所不同。因此，您可以採用較不激進的調整設定檔。在這種情況下，降低成本可能比改善使用者體驗更重要。
設定基準資源
資源調度設定檔的另一個關鍵要素，是決定適當的最小資源集合。
由於需要建立及初始化新節點，因此 Compute Engine 虛擬機器或 GKE 叢集通常需要一些時間才能擴充。因此，即使沒有流量，也可能需要維護一組最少的資源。同樣地，基準資源的程度會受到應用程式類型和流量設定檔的影響。
相反地，App Engine、Cloud Run 函式和 Cloud Run 等無伺服器技術則可讓您快速啟動及調度資源，即使在冷啟動執行個體的情況下也一樣。視應用程式類型和流量設定檔而定，這些技術可為應用程式的部分內容提供效率。
設定自動調度資源功能
自動調度資源可協助您自動調整應用程式所消耗的運算資源。通常，當超過特定指標或符合特定條件時，系統就會自動調度資源。舉例來說，如果網頁層級的網路要求延遲時間開始超過特定值，您可能需要自動新增更多機器，以提高服務容量。
許多 Google Cloud 運算產品都具備自動調度資源功能。Cloud Run、Cloud Run 函式和 App Engine 等無伺服器管理服務的設計目的，就是為了快速擴充。這些服務通常會提供設定選項，用於限制或影響自動調度資源行為，但一般來說，運算子無法查看大部分的自動配置器行為。
Compute Engine 和 GKE 提供更多選項，可控管縮放行為。您可以使用 Compute Engine 依據各種輸入內容調整資源，包括 Cloud Monitoring 自訂指標和負載平衡器服務規模。您可以為調度行為設定下限和上限，並定義具備多個信號的自動調度資源政策，以處理不同情況。與 GKE 一樣，您可以設定叢集自動配置器，根據工作負載或 Pod 指標，或叢集外部指標，新增或移除節點。
建議您根據主要應用程式指標、成本設定檔，以及所定義的資源最低必要層級，設定自動調度資源行為。
盡可能縮短啟動時間
為了讓調整規模的效果更顯著，您必須盡快調整，才能處理不斷增加的工作負載。尤其是在新增運算或服務容量時。
使用預先處理圖片
如果應用程式在 Compute Engine VM 上執行，您可能需要安裝軟體，並設定執行個體來執行應用程式。雖然您可以使用啟動指令碼來設定新的執行個體，但更有效率的方法是建立自訂映像檔。自訂映像檔是指您使用應用程式專屬軟體和設定所設定的開機磁碟。
如要進一步瞭解如何管理圖片，請參閱圖片管理最佳做法一文。
建立映像檔後，您可以定義執行個體範本。執行個體範本會結合開機磁碟映像檔、機器類型和其他執行個體屬性。之後即可使用執行個體範本，建立個別的 VM 執行個體或代管執行個體群組。執行個體範本可輕鬆儲存 VM 執行個體的設定，即可日後用於建立相同的 VM 執行個體。
雖然建立自訂映像檔和執行個體範本可加快部署速度，但也可能會增加維護成本，因為可能需要更頻繁地更新映像檔。詳情請參閱「平衡映像檔設定和部署速度」說明文件。
將應用程式容器化
除了建構自訂 VM 執行個體，您也可以將應用程式封裝在容器中。容器是輕量級、獨立的軟體可執行檔套件，內含執行應用程式所需的一切：程式碼、執行階段、系統工具、系統程式庫和設定。這些特性可讓容器化的應用程式更具可攜性、更易於部署，也能更輕鬆地進行大規模維護作業，容器通常啟動速度也很快，因此適合用於可擴充且具備彈性的應用程式。
Google Cloud 提供多項服務，可執行應用程式容器。Cloud Run 提供無伺服器的代管運算平台，可代管無狀態容器。App Engine 彈性環境會在代管平台式服務 (PaaS) 中代管容器。GKE 提供代管的 Kubernetes 環境，可代管及自動化調度管理容器化應用程式。如需完全控管容器環境，您也可以在 Compute Engine 上執行應用程式容器。
加快應用程式啟動速度
除了確保基礎架構和應用程式能盡可能有效地部署外，也請務必確保應用程式能快速上線。
適合應用程式的最佳化方式會因應用程式的特性和執行平台而異。請務必完成下列操作：
- 找出並消除瓶頸，方法是分析應用程式在啟動時叫用的關鍵區段。
- 實作延遲初始化等技術 (特別是耗用大量資源的技術)，縮短初始啟動時間。
- 盡量減少可能需要在啟動期間載入的應用程式依附元件。
偏好模組化架構
您可以選擇可讓元件獨立部署、管理及調整的架構，藉此提升應用程式的彈性。這個模式還能消除單點故障，進而提升彈性。
將應用程式分解為獨立服務
如果您將應用程式設計為一組鬆耦合的獨立服務，就能提高應用程式的彈性。如果採用鬆耦合設計，服務就能獨立發布及部署。除了許多其他優點之外，這種做法還可讓這些服務使用不同的技術堆疊，並由不同的團隊管理。這種鬆散耦合方法是微服務和 SOA 等架構模式的主要主題。
在考量如何為服務劃分邊界時，可用性和擴充性需求是重要的維度。舉例來說，如果某個元件與其他元件的可用性需求或縮放設定檔不同，就很適合做為獨立服務。
以無狀態為目標
無狀態應用程式或服務不會保留任何本機永久資料或狀態。無狀態模型可確保您能獨立於先前要求，處理與服務的每項要求或互動。這個模型可促進可擴充性和可復原性，因為這表示服務可以擴充、縮減或重新啟動，而不會遺失處理任何執行中的程序或要求所需的資料。使用自動配置器時，無狀態功能就顯得格外重要，因為代管服務的執行個體、節點或 Pod 可能會在意料之外建立及刪除。
您可能無法讓所有服務都無狀態。在這種情況下，請明確指出需要狀態的服務。確保無狀態和有狀態服務的明確區隔，可確保無狀態服務的簡單可擴充性，同時採用更周全的做法處理有狀態服務。
管理服務間的通訊
分散式微服務架構的其中一個挑戰，就是管理服務之間的通訊。隨著服務網路的擴大，服務之間的相互依賴性也可能會增加。您不希望某項服務的失敗導致其他服務失敗，這有時稱為連鎖失敗。
您可以採用斷路器模式、指數輪詢和平穩降級等技術，減少流量前往超載或失敗的服務。這些模式會為超載的服務提供復原機會，或妥善處理錯誤狀態，進而提高應用程式的彈性。詳情請參閱 Google SRE 書籍中的「處理連鎖失敗」一章。
使用服務網格可協助您管理分散式服務的流量。服務網格是將服務連結在一起的軟體，有助於將業務邏輯與網路分離。服務網格通常會提供彈性功能，例如重試要求、容錯移轉和斷路器。
使用適當的資料庫和儲存技術
某些資料庫和儲存類型很難擴充及提高韌性。請確認所選資料庫不會限制應用程式的可用性和可擴充性。
評估資料庫需求
將應用程式設計為一組獨立服務的模式，也適用於資料庫和儲存空間。為應用程式的不同部分選擇不同類型的儲存空間可能比較適當，這會導致異質儲存空間。
傳統應用程式通常只會與關聯式資料庫搭配運作。關聯式資料庫提供實用的功能，例如交易、強一致性、參照完整性，以及跨資料表的複雜查詢。這些功能讓關聯式資料庫成為許多常見應用程式功能的理想選擇。不過，關聯資料庫也有一定的限制。這類服務通常難以擴充，且需要在高可用性設定中進行仔細管理。關聯資料庫可能不是滿足所有資料庫需求的最佳選擇。
非關聯資料庫 (通常稱為 NoSQL 資料庫) 則採用不同的做法。雖然不同產品的詳細資料有所差異，但 NoSQL 資料庫通常會犧牲關聯式資料庫的部分功能，以便提高可用性和擴充性。根據 CAP 定理，NoSQL 資料庫通常會選擇可用性而非一致性。
NoSQL 資料庫是否合適，通常取決於所需的一致性程度。如果特定服務的資料模型不需要 RDBMS 的所有功能，且可設計為最終一致性，選擇 NoSQL 資料庫可能會提高可用性和可擴充性。
在資料管理領域中，關聯資料庫和非關聯資料庫通常被視為互補技術，而非競爭技術。透過策略性地使用這兩種資料庫，機構便可發揮各自的優勢，在資料儲存、擷取和分析方面取得最佳成果。
除了各種關聯資料庫和 NoSQL 資料庫， Google Cloud也提供 Spanner，這是一個具備同步一致性、高可用性，且遍及全球的資料庫，支援 SQL。如要瞭解如何在Google Cloud上選擇合適的資料庫，請參閱 Google Cloud 資料庫。
實作快取
快取的主要目的，是減少存取底層較慢的儲存層需求，藉此提高資料擷取效能。
快取功能可減少對磁碟式儲存空間的依賴，進而提升擴充性。由於要求可透過記憶體提供，因此系統可減少對儲存層的要求延遲時間，通常可讓服務處理更多要求。此外，快取功能還可減少應用程式後端服務 (尤其是資料庫) 的負載，讓與該後端服務互動的其他元件也能進一步或完全調整。
快取也可以支援優雅降級等技巧，進而提高彈性。如果基礎儲存空間層超載或無法使用，快取可以繼續處理要求。即使快取記憶體傳回的資料可能不完整或過時，在某些情況下也許可以接受。
Memorystore for Redis 提供全代管服務，採用 Redis 記憶體內資料儲存空間。Memorystore for Redis 可針對密集存取的資料，提供低延遲存取和高總處理量。可在提供跨區複製和自動容錯移轉功能的高可用性設定中部署。
以現代化的方式進行開發流程和文化
開發運作可視為一套廣泛的程序、文化和工具集合，可打破開發、營運和相關團隊之間的隔閡，提高應用程式和功能的敏捷性，並加快其上市時間。DevOps 技巧旨在改善軟體的品質和可靠性。
本文件不會詳細討論 DevOps，但後續章節會討論一些與提升應用程式可靠性和韌性相關的重要面向。詳情請參閱Google Cloud「開發運作頁面」。
將可測試性列入設計考量
自動化測試是現代軟體交付實務的重要一環。有能力執行一整套裝置、整合和系統測試的作業，是驗證應用程式是否如預期般運作，且能進展至部署週期下一階段的基本要求。測試能力是應用程式的重要設計標準。
我們建議您使用單元測試進行大部分的測試，因為這類測試執行速度快，且通常容易維護。我們也建議您自動化較高層級的整合和系統測試。如果採用基礎架構即程式碼技術，這些測試就會大幅簡化，因為您可以視需要建立專屬的測試環境和資源，然後在測試完成後拆除。
隨著測試涵蓋的程式碼集百分比增加，您就能減少不確定性，並降低每項程式碼變更可能造成的可靠性降低。充分的測試涵蓋率代表您可以在可接受的程度下，進行更多變更，直到可靠性降低為止。
自動化測試是持續整合的必要環節。針對每個程式碼修訂版本執行一組可靠的自動化測試，可快速取得變更的意見回饋，進而提升軟體的品質和可靠性。 Google Cloud– 原生工具 (例如 Cloud Build) 和第三方工具 (例如 Jenkins) 可協助您實作持續整合。
自動進行部署
持續整合和全面的自動化測試，可讓您確信軟體的穩定性。完成這些步驟後，下一步就是自動部署應用程式。部署自動化程度會因貴機構的成熟度而異。
選擇適當的部署策略，可盡量降低部署新軟體的風險。只要採用正確的策略，您就能逐步向更多目標對象曝光新版本，並在過程中驗證行為。您也可以在發生問題時，設定明確的回溯條件。
採用 SRE 做法來處理失敗
對於大規模運作的分散式應用程式，在一個或多個元件中發生某種程度的失敗是很常見的情況。如果您採用本文件所述的模式，應用程式就能更妥善地處理因軟體版本瑕疵、虛擬機器意外終止，甚至是影響整個區域的基礎架構中斷而導致的服務中斷。
不過，即使您謹慎設計應用程式，仍可能遇到需要人為介入的意外事件。如果您採用有條理的流程來管理這些事件，就能大幅降低事件影響，並更快解決問題。此外，如果您檢查事件的原因和回應，就能協助保護應用程式，避免日後發生類似事件。
事件管理和無責檢討的強大程序，是 SRE 的重要原則。雖然實施 Google SRE 的完整做法對貴機構來說可能不切實際，但只要採用最少的規範，就能提升應用程式的復原能力。SRE 書籍的附錄包含一些可協助塑造程序的範本。
驗證及檢查架構
隨著應用程式不斷演進，使用者行為、流量設定檔，甚至是業務優先順序都可能有所變動。同樣地，應用程式所依賴的其他服務或基礎架構也可能會有所變動。因此，請務必定期測試並驗證應用程式的復原力和可擴充性。
測試復原力
請務必測試應用程式是否會以您預期的方式回應失敗。總體而言，避免失敗的最佳方式就是引入失敗，並從中學習。
模擬及引入失敗情況相當複雜。除了驗證應用程式或服務的行為外，您還必須確保系統會產生預期的警示，並產生適當的指標。我們建議您採用結構化方法，先引入基本失敗，然後再提報。
舉例來說，您可以按照下列步驟進行，驗證並記錄各個階段的行為：
- 引入間歇性故障。
- 封鎖服務相依項目的存取權。
- 封鎖所有網路通訊。
- 終止主機。
詳情請參閱 Google Cloud Next 2019 的「破壞系統，讓系統變得堅不可摧」影片。
如果您使用 Istio 之類的服務網格來管理應用程式服務，可以在應用程式層注入錯誤，而非刪除 Pod 或機器，也可以在 TCP 層注入毀損封包。您可以引入延遲時間，模擬網路延遲或上游系統過載的情況。您也可以引入中止作業，模擬上游系統中的失敗情形。
測試資源調度行為
建議您使用自動化非功能性測試，確認應用程式可如預期擴充。這項驗證通常會與效能或負載測試搭配使用。您可以使用 hey 等工具，將負載傳送至網路應用程式。如需更詳細的示例，說明如何針對 REST 端點執行負載測試，請參閱「使用 Google Kubernetes Engine 進行分散式負載測試」。
常見的做法之一，就是確保主要指標在不同負載下維持在預期的等級。舉例來說，如果您要測試網頁層級的擴充性，可以評估使用者要求量尖峰的平均要求延遲時間。同樣地，針對後端處理功能，您可能會在工作量突然增加時，評估平均工作處理時間。
此外，您希望測試能評估用於處理測試負載而建立的資源數量是否在預期範圍內。舉例來說，測試可能會驗證用於處理某些後端工作而建立的 VM 數量是否不超過特定值。
測試極端情況也很重要。當達到最大縮放限制時，應用程式或服務的行為為何？如果服務縮減後，負載又突然增加，會發生什麼情況？
一律進行架構設計
科技領域的發展速度極快，雲端技術更是如此。新產品和功能不斷推出，新模式不斷出現，使用者和內部利害關係人的需求也持續增加。
如同「雲端原生架構的設計原則」部落格文章所定義，請隨時尋找方法來精進、簡化及改善應用程式架構。軟體系統是活生生物，需要隨著您變更的優先順序進行調整。
後續步驟
- 閱讀「雲端原生架構的設計原則」網誌文章。
- 請參閱 SRE 書籍，進一步瞭解 Google 正式環境的管理方式。
- 進一步瞭解 Google Cloud 上的DevOps如何提升軟體品質和可靠性。
- 探索 Google Cloud 的參考架構、圖表和最佳做法。歡迎瀏覽我們的雲端架構中心。