讓應用程式可調整

既然您已瞭解準備成長的基本概念，並瞭解容量規劃中需要考慮的因素，您可以承擔讓應用程式盡可能調整的挑戰。

建築評論

要記住的重點是，您應該對系統執行一般架構檢閱。

您知道您可以套用基礎結構即程式代碼等做法，以改善部署雲端資源的方式。 您可以定期更新和改善應用程式程序代碼，而且您應該使用基礎平台資源執行相同的動作。

執行架構檢閱可協助您識別需要改進的區域。

Azure架構中心擁有豐富的資源，協助你在雲端架構設計應用程式，且在以下連結的應用程式架構指南中，有許多可擴展性的建議可供參考：

Azure 架構中心

案例：Tailwind Traders 架構

第一個步驟是評估架構和應用程式，不僅要判斷其弱點的位置，還能辨識其優勢。 這有什麼好處？

再次查看您在上一個單元中看到的情境。 以下再次是組織架構的示意圖。

他們將應用程式拆解成較小的微服務，其中一些服務以容器形式存在於 Azure Kubernetes Service，或是運行在虛擬機或 App Service 上。 他們也使用一些 本質上可擴展 的服務，如 Functions 和 Logic Apps。

這項變更很好，但有一些改善可讓應用程式更具延展性。 例如，現在將焦點放在產品服務上。 在圖中，產品服務是在 Kubernetes 中執行，但我們假設它在 Azure 的虛擬機上運行。 您可以將擴展的概念應用到應用程式中，不論這些應用程式是在伺服器、App Service 還是容器中執行，即使實作方式可能會稍有不同。

目前該產品運行於單一虛擬機上，並連接到單一 Azure SQL 資料庫。 你需要啟用這個虛擬機才能擴展。你可以利用 Azure 虛擬機擴展集來達成這點，這可以讓你建立和管理一組相同且負載平衡的虛擬機。 因為您現在有多個 VM，因此您需要引進負載平衡器，以將流量分散到 VM。

虛擬機器擴展集

透過將虛擬機擴展集套用至單一 VM，您會獲得一些優點：

• 您可以根據主機計量、客體計量、應用程式見解或依排程自動縮放。
• 你可以使用 可用性區域（AZ），這是 Azure 區域內物理上獨立的地點，每個區域由一個或多個資料中心組成。 有了 AZ 支援，你可以將虛擬機分散在多個 AZ，讓應用程式更可靠，並防止資料中心故障。 擴展集內的新執行個體會自動平均分散到各 AZ。
• 新增負載平衡器會變得更容易。 虛擬機規模集支援使用 Azure Load Balancer 進行基本的第 4 層流量分配。 他們也支援 Azure 應用程式閘道，用於更進階的 L7 流量分配和 SSL 終止。

在實作規模集之前，您需要考慮一些重要因素。 具體說來：

• 避免實例黏連，以確保客戶端不會被綁定到特定的後端。
• 從虛擬機移除持久資料，並將它們存放在其他地方，例如Azure 儲存體或資料庫中。
• 相應縮小的設計。 確保您的應用程式也能輕鬆縮減規模同樣重要。 它必須優雅地處理不僅將更多實例新增至伺服器集群以處理流量，還有在負載下降時實例的突然終止。 調整規模時，縮小層面經常會受到忽略。

縮減

您已使用擴展集新增更多 VM。 向外擴充是「我們需要調整規模」的典型答案。但您只能依單一計量進行調整規模，所以這個答案可能與您產品服務執行的所有工作無關。

在我們的情境中，產品服務有個任務：當產品圖片上傳時，它會轉碼該圖片並以多種不同尺寸儲存，用於縮圖、目錄中的圖片等等。 映像處理需要大量CPU，但一般使用量會耗用記憶體。

影像處理是一項異步工作，可以分成背景工作。 您可以使用佇列將影像處理服務分離，以執行此作業。 縮減可讓您獨立調整這兩項服務 – 一個在記憶體 (產品服務)，另一個 (影像處理服務) 在 CPU 或甚至是佇列長度，然後讓另一個擴展集取用這些訊息及處理影像。

使用佇列調整規模

Azure 有兩種類型的佇列服務：

• Azure 服務匯流排 隊列 更進階的佇列服務，屬於更廣泛的 Azure 服務匯流排 產品，提供發佈/訂閱及更進階的整合模式。
• Azure 儲存體 佇列 建立在 Azure 儲存體 之上，是一個簡單的基於 REST 的佇列介面。 它提供可靠且持續性的傳訊。

在這種情況下，你的需求很簡單，所以你可以使用 Azure 儲存體 Queues。 您的產品層級不需要有任何調整，因為您已將此背景工作分離。

記憶體緩存

改善應用程式效能的另一種方式是實作記憶體內部快取。

現在您知道效能並不完全等於延展性，但藉由改善應用程式的效能，您可以減少其他資源的負載。 這項改進表示您可能不必儘快調整規模。

Azure Managed Redis（前稱 Azure Cache for Redis）是一款管理式 Redis 產品。 Redis 可用於許多模式和使用案例。 針對您在此案例中的產品服務，您可能會實作另行快取模式。 在此模式中，您會視需要將資料庫的專案載入快取，讓您的應用程式更具效能，並減少資料庫的負載。

Redis 也可用作訊息佇列、快取網頁內容或使用者會話快取。 這種類型的快取可能更適合系統中的其他服務，例如購物車服務，您可以在 Redis 中儲存每個會話的購物車數據，而不是使用 Cookie。

調整資料庫規模

既然你已經讓運算資源更具可擴展性，不妨看看你的資料庫。 在這種情況下，你使用的是 Azure SQL Database，這是 Azure 提供的託管式 SQL Server。

關係資料庫比非關係資料庫更難向外延展。 您擴大資料庫的第一步可能是增加資料庫的容量。 只需短暫的連線中斷，即可輕鬆完成此調整大小作業，方法是在 Azure SQL 中使用簡單的 API 呼叫，或在入口網站中使用滑桿。

如果此擴大作業不符合您的需求，視流量特性而定，可能適合向外擴展資料庫的讀取，讓您能夠將讀取流量路由傳送至讀取複本。

此變更必須在程式代碼中實作。 你可以在資料庫連接字串中設定 ApplicationIntent 屬性來指定路由意圖。 用 ReadOnly 來連接複本，或 ReadWrite 連接主節點。

建議做法是使用受管理身份來進行認證，並將任何必要的設定儲存在 Azure Key Vault：

#Read Replica Connection String (recommended: managed identity)
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;Authentication=Active Directory Default;Encrypt=True;

#Primary Connection String (recommended: managed identity)
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadWrite;Authentication=Active Directory Default;Encrypt=True;

因為這項變更必須以程式碼實作，可能不適合你的情況。 如果每個產品服務都需要讀取和寫入的能力，該怎麼辦？

在這種情況下，你可以考慮用分片來擴展 Azure SQL Database。

資料庫分區化

如果在擴大規模或實作讀取副本後，資料庫資源仍無法滿足系統需求，下一個選項就是 分片。

分區化是一種將大量相同結構化數據分散到許多獨立資料庫的技術。 需要分區化的原因有很多。 例如：

• 數據總量太大，無法符合個別資料庫的條件約束。
• 整體工作負載的交易輸送量超過個別資料庫的功能。
• 基於合規性原因，不同的租用戶必須位於不同的實體資料庫上 (這項需求和調整規模較無關係，但這是需要使用分區化的另一種情況)。

你的應用程式會將相關資料加入相關分片，從而使系統能超越單一資料庫的限制。

Azure SQL 提供 Azure Elastic Database 工具。 這些工具幫助你從應用程式邏輯建立、維護及查詢 Azure 中的分片 SQL 資料庫。