應用程式的災難復原情境

本文是系列文章之一，旨在探討災難復原 (DR) Google Cloud。本單元旨在探索應用程式通用的災難復原情境。

本系列包含以下單元：

• 災難復原規劃指南
• 災難復原的構成要素
• 資料的災難復原情境
• 應用程式的災難復原情境 (本文)
• 為位置受限的工作負載建立災難復原架構
• 災難復原用途：受地域限制的資料分析應用程式
• 為雲端基礎架構中斷建立災難復原架構

簡介

本文依據 DR 模式建構應用程式的 DR 情境。從 DR 模式中，可看出應用程式從災難事件中復原的難易度。我們藉由「DR 構成要素」一文討論的概念，說明如何實作適合您的復原目標的端對端 DR 方案。

首先，讓我們來看看一些典型的工作負載，藉此說明復原目標和架構的設計會如何直接影響您的 DR 計畫。

批次處理工作負載

批次處理工作負載往往不是關鍵業務，所以您通常不需要花錢設計高可用性 (HA) 架構，以最大化運作時間；一般來說，批次處理工作負載可以應付作業中斷的情況。這類型的工作負載可利用成本效益高的產品，例如 Spot VM 和先占 VM 執行個體。建立和執行這類執行個體的費用比一般執行個體低很多。(不過，如果 Compute Engine 需要存取這些資源以執行其他工作，可能會預先停止或刪除這些執行個體。

若您在處理工作中實行定期查核點，則新的 VM 啟動時，會從失敗點開始繼續處理工作。如果您使用 Dataproc，則會由代管的執行個體群組管理啟動先占工作站節點的程序。由於在等待替代的 VM 繼續進行處理程序時，作業會短暫停止，因此這可以視為暖模式。

電子商務網站

在電子商務網站中，應用程式的某些部分可能會有較大的復原時間目標 (RTO) 值。 例如，實際採購管道需要高可用性，但傳送訂單通知給客戶的電子郵件程序可以容忍幾小時的延遲。客戶知道其採購項目，因此他們雖然預期會收到確認電子郵件，但通知並不是此程序的重要部分。這個程序混和了熱模式 (採購) 和暖/冷模式 (通知)。

應用程式的交易部分需要高運作時間，但 RTO 值要在最低，因此您會使用 HA 提高這部分應用程式的可用性。您可以將這個方法視為熱模式。

電子商務情境說明如何在同一個應用程式中使用不同的 RTO 值。

影片串流

從搜尋體驗到將內容串流給使用者的實際程序，影片串流解決方案的許多元件都需要高可用性。此外，系統需要低延遲以提供令人滿意的使用者體驗。如果解決方案的任一部分無法提供出色的體驗，對供應商及客戶而言都不利。而且，現今的顧客可輕易地改用競爭對手的產品。

在此情境中，HA 架構和極小的 RTO 值為必備要素，此外，您也必須將熱模式用於應用程式的整個架構，才在災難發生時，將影響降至最小。

內部部署實際工作環境的 DR 和 HA 架構

本節說明在內部部署執行應用程式，而 DR 解決方案位於Google Cloud上時，如何實行冷、暖、熱這三種模式。

冷模式：復原至 Google Cloud

在冷模式中，您在 DR 專案中的資源最少，只剛好夠用來啟用復原情境。 Google Cloud當發生讓實際工作環境無法執行實際運作的工作負載問題時，容錯移轉策略需要在 Google Cloud中啟動實際工作環境鏡像。然後，用戶端會開始從 DR 環境使用服務。

我們將在本節檢視這個模式的範例。在範例中，Cloud Interconnect 設定了自行管理的 (非Google Cloud) VPN 解決方案，以提供連至 Google Cloud的連線能力。資料會複製到 Cloud Storage，做為實際工作環境的一部分。

這個模式使用下列 DR 構成要素：

• Cloud DNS
• Cloud Interconnect
• 自行管理的 VPN 解決方案
• Cloud Storage
• Compute Engine
• Cloud Load Balancing
• Deployment Manager

下圖說明此範例架構：

下列步驟大致說明如何設定環境：

1. 建立虛擬私人雲端網路。
2. 設定連線以連結內部部署網路與 Google Cloud 網路。
3. 建立 Cloud Storage bucket，做為資料備份的目標。
4. 建立服務帳戶。
5. 建立 IAM 政策，限制可存取值區和物件的對象。請納入專為這項作業所建立的服務帳戶。此外，也請將使用者帳戶或群組加入作業員或系統管理員的政策中，向這些身分授予相關權限。如要進一步瞭解 Cloud Storage 的存取權限，請參閱適用於 Cloud Storage 的 Cloud IAM 權限。
6. 使用服務帳戶模擬功能，為本機 Google Cloud使用者 (或服務帳戶) 提供存取權，模擬您先前建立的服務帳戶。或者，您也可以專門為此建立新使用者。
7. 進行測試，確認您可以在目標值區中上傳與下載檔案。
8. 建立資料移轉指令碼。
9. 建立排程工作以執行指令碼。您可以使用 Linux crontab 和 Windows 工作排程器等工具。

10. 建立自訂映像檔，針對實際工作環境的各部伺服器進行設定。每個映像檔的設定應與內部部署的對應伺服器相同。

    在資料庫伺服器的自訂映像檔設定中，建立開機指令碼，從 Cloud Storage 值區將最新的備份自動複製到執行個體，然後叫用復原程序。

11. 設定 Cloud DNS 為指向連結到網際網路的網路服務。

12. 建立 Deployment Manager 範本，使用先前設定的自訂映像檔，在 Google Cloud 網路中建立應用程式伺服器。這個範本也應視需要設定適當的防火牆規則。

您必須實作這些程序，以確保自訂映像檔的應用程式版本與內部部署相同。請務必在您的標準升級週期中納入升級到自訂映像檔的程序，並確保 Deployment Manager 範本使用最新的自訂映像檔。

容錯移轉程序和重新啟動後工作

如果發生災難，您可以復原到Google Cloud上執行的系統。如要這麼做，請啟動復原程序，以使用您建立的 Deployment Manager 範本來建立復原環境。當復原環境中的執行個體準備好接受實際工作流量時，請調整 DNS 以指向Google Cloud中的網路伺服器。

復原順序通常為：

1. 使用 Deployment Manager 範本，在Google Cloud中建立部署。
2. 遵循資料庫系統的復原備份檔案操作說明，將 Cloud Storage 中的最新資料庫備份套用到在 Google Cloud 中執行的資料庫伺服器。
3. 套用 Cloud Storage 中最新的交易記錄。
4. 在已復原的環境中模擬使用者情境，測試應用程式是否如預期運作。
5. 測試成功後，請設定 Cloud DNS 以指向 Google Cloud上的網路伺服器。(例如，您可以使用 Google Cloud 負載平衡器後面的 Anycast IP 位址，在該負載平衡器後面使用數個網路伺服器)。

下圖顯示已復原的環境：

當實際工作環境重新在內部部署中執行，且環境支援實際工作負載時，您可以反向執行容錯移轉至 Google Cloud 復原環境時所採取的步驟，返回實際工作環境。順序通常為：

1. 備份在 Google Cloud上執行的資料庫。
2. 將備份檔案複製到實際工作環境。
3. 將備份檔案套用到實際工作環境的資料庫系統。
4. 不要連結到 Google Cloud中的應用程式。例如，不要連結全域負載平衡器。從這時開始到您完成還原實際工作環境前，應用程式將無法使用。
5. 將所有交易記錄檔案複製到實際工作環境，並套用到資料庫伺服器。
6. 設定 Cloud DNS 為指向內部部署網路服務。
7. 確定您的程序會如預期運作，將資料複製到 Cloud Storage。
8. 刪除部署。

暖待命：復原到 Google Cloud

通常實行暖模式是為了在不花錢設定完整的 HA 的情況下，最小化 RTO 和 RPO 值。RTO 和 RPO 的值愈小，費用愈高，因為此方法使用可處理來自兩個環境的流量的完全備援環境。因此，在 DR 情境實行暖模式可在預算和可用性之間取得良好平衡。

舉例來說，您可以透過自行管理的 VPN 解決方案設定 Cloud Interconnect，以提供 Google Cloud的連線。多層式應用程式在內部部署環境中執行，同時在 Google Cloud上使用最少的復原套件。復原套件包含 Google Cloud上的作業資料庫伺服器執行個體。這個執行個體必須隨時執行，才能透過非同步或半同步複製技術接收複製的交易。若要降低費用，您可以使用執行資料庫服務的最小機器類型來執行資料庫。因為您可以使用長時間執行的執行個體，因此適用續用折扣。

這個模式使用下列 DR 構成要素：

• Cloud DNS
• Cloud Interconnect
• 自行管理的 VPN 解決方案
• Compute Engine
• Deployment Manager

Compute Engine 快照可讓您建立備份，並使用該備份復原到之前的狀態。本範例之所以使用快照，是因為更新的網頁和應用程式二進位檔會頻繁地寫入實際工作環境網路和應用程式伺服器。這些更新會定期複製到 Google Cloud上的參考網路伺服器和應用程式伺服器執行個體。(參考伺服器是用來建立快照的，因此不接受實際工作流量。)

下圖說明實行此方法的架構。圖中未顯示複製目標。

下列步驟大致說明如何設定環境：

1. 建立虛擬私人雲端網路。
2. 設定連線以連結內部部署網路與 Google Cloud 網路。
3. 將內部部署伺服器複製到 Google Cloud VM 執行個體。您可以選擇使用夥伴解決方案；使用的方法須視您的情況而定。
4. 在 Google Cloud 上建立資料庫伺服器的自訂映像檔，此映像檔的設定要與內部部署資料庫伺服器相同。
5. 為網路伺服器和應用程式伺服器執行個體建立快照。
6. 使用您稍早建立的自訂映像檔，在 Google Cloud 中啟動資料庫執行個體。使用可從內部部署實際工作環境資料庫接受複製資料的最小機器類型。
7. 連結永久磁碟與 Google Cloud 資料庫執行個體，以儲存資料庫和交易記錄。
8. 遵循資料庫軟體的操作說明，設定在內部部署資料庫伺服器和 Google Cloud 中資料庫伺服器之間的複製作業。
9. 將連結到資料庫執行個體的永久磁碟的自動刪除標記設為 no-auto-delete。
10. 設定排程工作，定期為 Google Cloud上資料庫執行個體的永久磁碟建立快照。
11. 建立預留項目，確保網路伺服器和應用程式伺服器有足夠的容量。
12. 測試建立永久磁碟快照，以及從快照建立執行個體的程序。
13. 使用稍早建立的快照，建立網路伺服器和應用程式伺服器的執行個體。
14. 建立指令碼，只要對應的內部部署伺服器有更新，就會將更新複製到網路應用程式和應用程式伺服器。編寫指令碼，為更新的伺服器建立快照。
15. 設定 Cloud DNS 以指向連結到網際網路的內部部署網路服務。

容錯移轉程序和重新啟動後工作

若要管理容錯移轉，通常需使用監控和快訊系統來叫用自動容錯移轉程序。內部部署應用程式需要容錯移轉時，您可以在 Google Cloud 上設定資料庫系統，讓該系統接受實際工作流量。您也可以啟動網路和應用程式伺服器的執行個體。

下圖顯示容錯移轉至Google Cloud 後的設定，可讓Google Cloud處理實際工作負載：

復原順序通常為：

1. 針對資料庫伺服器執行個體調整大小，使其能夠處理實際工作負載。
2. 使用 Google Cloud上的網路伺服器和應用程式快照，以建立新的網路伺服器和應用程式執行個體。
3. 在已復原的環境中模擬使用者情境，測試應用程式是否如預期運作。
4. 測試成功後，請設定 Cloud DNS 以指向 Google Cloud上的網路服務。

當實際工作環境重新在內部部署中執行並能支援實際工作負載時，您可以反向執行容錯移轉至 Google Cloud 復原環境時所採取的步驟，返回實際工作環境。順序通常為：

1. 備份在 Google Cloud上執行的資料庫。
2. 將備份檔案複製到實際工作環境。
3. 將備份檔案套用到實際工作環境的資料庫系統。
4. 不要連結到 Google Cloud中的應用程式。其中一個方式是透過修改防火牆規則，避免連結到網路伺服器。從這時開始到您完成還原實際工作環境前，應用程式將無法使用。
5. 將所有交易記錄檔案複製到實際工作環境，並套用到資料庫伺服器。
6. 在實際工作環境中模擬使用者情境，以測試應用程式是否按照預期運作。
7. 設定 Cloud DNS 為指向內部部署網路服務。
8. 刪除在Google Cloud中執行的網路伺服器和應用程式伺服器執行個體。讓參考伺服器保持執行。
9. 將 Google Cloud 上的資料庫伺服器大小調整回可接受內部部署實際運作資料庫中複製的資料的最小執行個體大小。
10. 遵循資料庫軟體的操作說明，設定在內部部署資料庫伺服器和 Google Cloud 中資料庫伺服器之間的複製作業。

跨內部部署和 Google Cloud

如果您的 RTO 和 RPO 值較小，只要在實際工作環境和 Google Cloud 並行執行 HA，就能獲得這些值。這個方法是熱模式，因為內部部署和 Google Cloud都在處理實際工作流量。

而與暖模式間的主要差異為兩種環境的資源都是在實際運作模式中執行，並處理實際工作流量。

這個模式使用下列 DR 構成要素：

• Cloud Interconnect
• Cloud VPN
• Compute Engine
• 代管執行個體群組
• Cloud Monitoring
• Cloud Load Balancing

下圖說明此範例架構。實作這個架構後，發生災難時您的 DR 計劃只需要最少的人為操作。

下列步驟大致說明如何設定環境：

1. 建立虛擬私人雲端網路。
2. 設定連線以連結內部部署網路與 Google Cloud 網路。
3. 在 Google Cloud 中建立自訂映像檔，針對內部部署實際工作環境的各部伺服器進行設定。每個 Google Cloud 映像檔的設定應與內部部署的對應伺服器相同。

4. 遵循資料庫軟體的操作說明，設定在內部部署資料庫伺服器和 Google Cloud 中資料庫伺服器之間的複製作業。

   設定複製作業時，由於許多資料庫系統只允許一個可寫入的資料庫執行個體，因此您可能需要確定其中一個資料庫備用資源將做為唯讀伺服器。

5. 建立個別的執行個體範本，在應用程式伺服器和網路伺服器使用映像檔。

6. 設定應用程式和網路伺服器的地區代管執行個體群組。

7. 使用 Cloud Monitoring 設定健康狀態檢查。

8. 使用稍早設定的地區代管執行個體群組，設定負載平衡。

9. 設定排程工作，定期建立永久磁碟快照。

10. 設定 DNS 服務，分配內部部署環境和 Google Cloud 環境之間的流量。

如要使用這種混合式方法，就必須使用可加權轉送到這兩個實際工作環境的 DNS 服務，才能從這兩個環境提供相同的應用程式。

您必須針對只在環境中的一小部分發生失敗 (部分失敗) 的情況來設計系統。在此情況下，流量應轉送到另一個備份環境中的相等服務。例如，如果内部部署網路伺服器變成無法使用，您可以停用以該環境為目的地的 DNS 轉送。如果 DNS 服務支援健康狀態檢查，則在健康狀態檢查判定無法連結其中一個環境的網路伺服器時，即會自動停用該轉送功能。

如果您使用的資料庫系統只允許一個可寫入的執行個體，在許多情況下，資料庫系統會在原始可寫入資料庫和讀取備用資源之間的活動訊號中斷時，自動將唯讀備用資源升級成可寫入的主要執行個體。請確定您瞭解這方面的資料庫複製作業，以防您在災難發生後需要介入操作。

您必須實行這些程序，以確保Google Cloud 中的自訂 VM 映像檔的應用程式版本與內部部署版本相同。請在標準升級週期中納入升級到自訂映像檔的程序，並確保 Deployment Manager 範本使用最新的自訂映像檔。

容錯移轉程序和重新啟動後工作

本文說明的熱情境設定中，災難是指兩個環境中有一個無法使用。暖情境或冷情境所使用的容錯移轉程序都不相同，您在此程序中必須移動資料，或將資料處理到第二個環境。但您可能需要處理下列設定變更：

• 如果 DNS 服務無法在健康狀態檢查失敗時自動重新轉送流量，您必須手動設定 DNS 轉送，將流量傳送到仍在作用中的系統。
• 如果資料庫系統無法在失敗時將唯讀備用資源自動升級成可寫入的主要執行個體，您必須介入操作，以確保備用資源能夠升級。

當第二個環境再次執行且可以處理實際工作流量時，您必須重新同步處理資料庫。因為這兩個環境都支援實際工作負載，所以您不需要採取任何變更主要資料庫的動作。資料庫同步後，您可以調整 DNS 設定，就能再次在這兩個環境之間分配實際工作流量。

在 Google Cloud上執行實際工作時的 DR 和 HA 架構

針對Google Cloud上的實際工作負載設計應用程式架構時，平台的 HA 功能會直接影響 DR 架構。

備份和災難復原服務是集中式雲端原生解決方案，可備份及還原雲端和混合式工作負載。可快速復原資料，協助您迅速恢復重要業務營運。

如要進一步瞭解如何使用備份和災難復原服務，在Google Cloud上處理應用程式情境，請參閱下列文章：

• Compute Engine 適用的備份和災難復原服務一文說明瞭使用 Google Cloud 備份和災難復原服務 Google Cloud 的概念和詳細資料，這項服務可在執行個體層級逐步備份永久磁碟中的資料。

• Google Cloud VMware Engine 的備份和災難復原服務一文說明瞭使用 Google Cloud 備份和災難復原服務 Google Cloud ，以 VM 層級從 VMDK 增量備份資料的概念和詳細資料。

• Filestore 和檔案系統的備份和災難復原服務一文說明如何使用 Google Cloud 備份和災難復原服務 Google Cloud ，從實際工作環境的 SMB、NFS 和 Filestore 檔案系統擷取及備份資料。

冷：可復原的應用程式伺服器

在需要單一主動伺服器執行個體的冷容錯移轉情境中，只有一個執行個體應寫入磁碟。在內部部署環境中，您通常會使用主動 / 被動叢集。在Google Cloud上執行正式環境時，您可以在代管執行個體群組中建立 VM，該 VM 只會執行一個執行個體。

這個模式使用下列 DR 構成要素：

• Compute Engine
• 代管執行個體群組

下圖顯示這個冷備援情境的範例架構：

以下步驟概述如何設定這個冷備援情境：

1. 建立虛擬私人雲端網路。
2. 建立設定應用程式網路服務的自訂 VM 映像檔。
   1. 設定 VM，將應用程式服務處理的資料寫入連結的永久磁碟。
3. 從連結的永久磁碟建立快照。
4. 建立執行個體範本，參照網路伺服器的自訂 VM 映像檔。
   1. 設定開機指令碼，從最新的快照建立永久磁碟及掛接磁碟。這個指令碼必須取得磁碟的最新快照。
5. 建立代管執行個體群組和健康狀態檢查，目標大小為一，並參照執行個體範本。
6. 建立排程工作，定期建立永久磁碟快照。
7. 設定外部應用程式負載平衡器。
8. 使用 Cloud Monitoring 設定快訊，在服務失敗時傳送快訊。

這個冷容錯移轉情境會運用 Google Cloud提供的一些 HA 功能。如果 VM 發生故障，代管執行個體群組會嘗試自動重新建立 VM。您不必啟動這項容錯移轉步驟，外部應用程式負載平衡器可確保即使需要替換 VM，應用程式伺服器前面還是會使用相同的 IP 位址。執行個體範本和自訂映像檔可確保替換 VM 的設定與被替換的執行個體完全相同。

您的 RPO 由最近一次取得的快照決定。取得快照的頻率愈密集，RPO 值就愈小。

代管執行個體群組提供深度的 HA，代管執行個體群組提供因應應用程式或 VM 層級錯誤的方法。如果發生上述任一情境，您不需要手動介入。將目標大小設為 1，可確保您永遠都只會有一個執行個體在代管執行個體群組中執行，並處理流量。

永久磁碟屬於區域層級，因此在發生區域失敗時，必須建立快照才能重建磁碟。您也可以跨地區使用快照，將磁碟還原到其他地區，就像在同一地區還原一樣輕鬆。

萬一發生區域故障，您必須手動介入才能復原，詳情請見下一節。

容錯移轉程序

如果 VM 發生故障，代管執行個體群組會自動嘗試在同一區域中重新建立 VM。執行個體範本中的開機指令碼會從最新的快照建立永久磁碟，並將其附加至新的 VM。

不過，如果區域發生故障，大小為 1 的代管執行個體群組無法復原。如果區域發生故障，您必須在服務失敗時，對 Cloud Monitoring 快訊或其他監控平台採取因應措施，並在其他區域手動建立執行個體群組。

這項設定的變化是使用地區永久磁碟，而非區域永久磁碟。如果使用這個方法，您不需要在執行復原步驟的過程中使用快照來還原永久磁碟。但這個變化版本會使用兩倍儲存空間，您要有這樣的預算才能執行。

您選擇的方法取決於您的預算以及 RTO 和 RPO 值。

暖：靜態網站容錯移轉

如果 Compute Engine 執行個體失敗，您可以讓以 Cloud Storage 為基礎的靜態網站處於待命狀態，以減輕服務中斷問題。如果您的網路應用程式大多時間是靜態時，可以選擇這種模式。

在此情境下，主要應用程式會在 Compute Engine 執行個體上執行。這些執行個體分成代管執行個體群組，以及做為 HTTPS 負載平衡器後端服務的執行個體群組。HTTP 負載平衡器會依據負載平衡器設定、每個執行個體群組的設定及每個執行個體的健康狀態，將連入流量引導到執行個體。

這個模式使用下列 DR 構成要素：

• Compute Engine
• Cloud Storage
• Cloud Load Balancing
• Cloud DNS

下圖說明此範例架構：

以下步驟概述如何設定這個情境：

1. 建立虛擬私人雲端網路。
2. 建立設定應用程式網路服務的自訂映像檔。
3. 建立使用網路伺服器映像檔的執行個體範本。
4. 為網路伺服器設定代管執行個體群組。
5. 使用 Monitoring 設定健康狀態檢查。
6. 使用您稍早設定的代管執行個體群組，設定負載平衡。
7. 建立以 Cloud Storage 為基礎的靜態網站。

在實際工作環境設定中，Cloud DNS 設定為指向這個主要應用程式，且待命靜態網站處於休眠狀態。如果 Compute Engine 應用程式故障，您可以將 Cloud DNS 設定為指向這個靜態網站。

容錯移轉程序

如果一或多個應用程式伺服器故障，復原順序會是設定 Cloud DNS 以指向您的靜態網站。下圖顯示復原模式中的架構：

當應用程式 Compute Engine 執行個體再次執行並能支援實際工作負載時，請反向執行復原步驟：設定 Cloud DNS 以指向在執行個體前面的負載平衡器。

或者，您也可以使用永久磁碟非同步複製。這項功能提供區塊儲存空間複製功能，可進行跨區域主動-被動式災難復原，並提供低復原點目標 (RPO) 和低復原時間目標 (RTO)。您可以使用這項儲存空間選項，在基礎架構層級管理 Compute Engine 工作負載的複製作業，而非在工作負載層級管理。

熱：HA 網路應用程式

當實際工作環境在 Google Cloud上執行時，使用熱模式的目的是要建立架構良好的 HA 部署。

這個模式使用下列 DR 構成要素：

• Compute Engine
• Cloud Load Balancing
• Cloud SQL

下圖說明此範例架構：

這個情境利用了 Google Cloud提供的 HA 功能。您不需要啟動任何容錯移轉步驟，因為它們會在發生災難時自動執行。

如圖所示，此架構會使用地區代管執行個體群組，搭配全域負載平衡和 Cloud SQL 一起使用。這裡提供的範例使用地區代管執行個體群組，因此執行個體會分佈在三個區域。

使用這個方法，您就能獲得深度 HA。地區代管執行個體群組提供的機制可因應應用程式、執行個體或區域層級的錯誤，其中任何情境發生時，您都不需要手動介入。

若要在設定代管執行個體群組的過程中處理應用程式層級復原，請設定 HTTP 健康狀態檢查，確認服務在該群組的執行個體上正常運作。如果健康狀態檢查確定執行個體上的服務失敗，則群組會自動重建該執行個體。

如要進一步瞭解如何在Google Cloud上建構可擴充且具彈性的應用程式，請參閱可擴充及具有彈性的應用程式模式 。

後續步驟

• 參閱Google Cloud 地理位置與地區一文。

• 參閱本 DR 系列的其他文件：

  • 災難復原規劃指南
  • 災難復原的構成要素
  • 資料的災難復原情境
  • 為位置受限的工作負載建立災難復原架構
  • 災難復原用途：受地域限制的資料分析應用程式
  • 為雲端基礎架構中斷建立災難復原架構

• 探索 Google Cloud 的參考架構、圖表和最佳做法。 歡迎瀏覽我們的雲端架構中心。