讓應用程式可調整

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

建築評論

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

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

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

Azure 架構中心有豐富的資源，可協助您在雲端建構應用程式，而且您可以在下列連結的應用程式架構指南中找到許多延展性建議：

Azure 架構中心

案例：Tailwind Traders 架構

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

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

它們已將應用程式分解為較小的微服務，其中一些服務會作為 Azure Kubernetes Service 上的容器，或者它們可能在 VM 或 App Service 上執行。 您使用一些 固有可調整 的服務，例如 Functions 和 Logic Apps。

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

產品目前在連線到單一 Azure SQL 資料庫的單一 VM 上執行。 您需要啟用此 VM 以向外擴展。您可以使用 Azure 虛擬機擴展集來完成這項操作，這樣您就可以建立和管理一組相同且負載平衡的 VM。 因為您現在有多個 VM，因此您需要引進負載平衡器，以將流量分散到 VM。

虛擬機器擴展集

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

• 您可以根據主機計量、客體計量、應用程式見解或依排程自動縮放。
• 您可以使用可用性區域 （AZ），這是 Azure 區域內的獨立資料中心。 透過 AZ 支援，您可以將 VM 分散到多個 AZ，讓您的應用程式更可靠，並防止資料中心失敗。 擴展集內的新執行個體會自動平均分散到各 AZ。
• 新增負載平衡器會變得更容易。 虛擬機擴展集支援使用 Azure Load Balancer 進行基本第 4 層流量分配。 它們也支援 Azure 應用程式閘道，以實現更高階的 L7 流量分配和 SSL 卸載。

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

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

縮減

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

在我們的情境中，產品服務有一項工作。 它會取得產品圖片，然後上傳該圖片。 它會轉碼該影像，並將其儲存為數個不同大小，以用於縮圖、目錄中的圖片等。 映像處理需要大量CPU，但一般使用量會耗用記憶體。

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

使用佇列調整規模

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

• Azure 服務總線佇列 是一種更為先進的佇列選擇，屬於 Azure 服務總線產品的一部分，提供發布/訂閱和更高級的整合模式。
• Azure 記憶體佇列 建置在 Azure 記憶體之上的簡單 REST 型佇列介面。 它提供可靠且持續性的傳訊。

在此案例中的需求很簡單，因此您可以使用 Azure 記憶體佇列。 您的產品層級不需要有任何調整，因為您已將此背景工作分離。

記憶體緩存

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

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

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

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

調整資料庫規模

既然您已讓計算資源更具延展性，請看一下您的資料庫。 在此案例中，您會使用 Azure SQL 資料庫，這是來自 Azure 的受控 SQL 伺服器供應專案。

關係資料庫比非關係資料庫更難向外延展。 您擴大資料庫的第一步可能是增加資料庫的容量。 您可以輕鬆地完成這項調整大小的作業，平均停機時間不超過四秒。 在 Azure SQL 中使用簡單的 API 呼叫，或在入口網站中使用滑桿。

如果此擴容不符合您的需求，視流量特性而定，可能會適合將讀取操作擴展至資料庫。 讓您將讀取流量路由至讀取複本。

此變更必須在程式代碼中實作。 以下是如何做到這一點。

#Azure SQL Connection String

#Master Connection String
ApplicationIntent=ReadWrite

#Read Replica Connection String
ApplicationIntent=ReadOnly

#Full Example
Server=tcp:<server>.database.windows.net;Database=<mydatabase>;ApplicationIntent=ReadOnly;User ID=<myLogin>;Password=<myPassword>;Trusted_Connection=False; Encrypt=True;

ApplicationIntent更新資料庫連接字串中的屬性，以指定要連線的伺服器。 如果您要連線到複本，請使用 ReadOnly；如果您要連線到主伺服器，請使用 ReadWrite。

由於此命令必須在程式代碼中實作，因此可能不適合您的情況。 如果每個產品服務都需要讀取和寫入的能力，該怎麼辦？

在此情況下，您可以考慮使用分片技術來擴展 SQL DB。

資料庫分區化

若在擴大或實作讀取複本之後，資料庫資源仍不符合您系統的需求，則下一個選項就是「分區化」。

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

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

您的應用程式會將相關數據新增至相關的分區，因此讓您的系統可擴充到個別資料庫的限制。

Azure SQL 提供 Azure 彈性資料庫工具。 這些工具可協助您從應用程式邏輯在 Azure 中建立、維護及查詢分區化 SQL 資料庫。