讓應用程式可延展

  • 8 分鐘

現在您已了解預備成長的基本知識，也了解在容量規劃中要考慮的因素，可以接受盡可能彈性調整應用程式的挑戰了。

架構檢閱

要記住的重點是，您應該定期檢閱系統架構。

您知道您可以套用一些做法，例如將基礎結構做為程式碼，來改進部署雲端資源的方式。 您應該定期更新及改進應用程式程式碼，並對基礎平台資源執行相同的動作。

執行架構檢閱可協助您找出需要改進之處。

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

Azure 架構中心

案例：Tailwind Traders 架構

第一個步驟是評估架構與應用程式 – 不只要判斷其弱點所在，也要辨識其優點。 這樣有什麼好處？

請再看看您在上一個單元中看到的案例。 再看一次組織架構圖。

Full architecture diagram of application with products backend highlighted.

應用程式已分解成較小的微服務，其中一些服務會做為 Azure Kubernetes Service 中的容器，或在 VM 或 App Service 上執行。 您正在使用某些「本身可調整」的服務，例如 Functions 與 Logic Apps。

這項變更很好，但某些改進可讓應用程式調整更具彈性。 現在以產品服務為例。 在此圖表中，產品服務在 Kubernetes 中執行，但我們假設這是在 Azure 的 VM 上執行而加以說明。 無論是在伺服器、App Service 或容器中執行的應用程式，都可以套用調整概念，唯實作可能稍有不同。

此產品目前在連線至單一 Azure SQL 資料庫的單一 VM 上執行。 您必須啟用此 VM 才能相應放大。您可以使用 Azure 虛擬機器擴展集執行此作業，這可讓您建立及管理一組完全相同且負載平衡的 VM。 因為您現在有一部以上的 VM，所以必須引進負載平衡器，將流量分散到各 VM。

虛擬機器擴展集

在單一 VM 上套用虛擬機器擴展集，可以取得幾項優勢：

  • 您可以依據主機計量、客體內部計量、Application Insights 或依排程自動調整。
  • 您可以使用可用性區域 (AZ)，這是 Azure 區域內不受響的獨立資料中心。 有了 AZ 支援，您即可將 VM 分散到多個 AZ，讓您的應用程式更可靠，並防止資料中心失敗。 擴展集內的新執行個體會自動平均分散到各 AZ。
  • 新增負載平衡器變得更容易。 虛擬機器擴展集支援使用 Azure Load Balancer 分散基本的 Layer 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 Server 供應項目。

關聯式資料庫比非關聯式資料庫更難相應放大。 調整資料庫規模的第一件事，就是相應放大資料庫的大小。 您可以輕鬆地完成這項調整大小的作業，平均停機時間不超過四秒。 方法是在 Azure SQL 中使用簡單的 API 呼叫或在入口網站中使用滑桿。

若此增加大小不符合您的需求 (視流量特性而定)，可能適合相應放大資料庫的讀取。 讓您將讀取流量路由至讀取複本。

注意

使用 Azure SQL 時，若您使用 Premium 或業務關鍵層，則根據預設會啟用「讀取相應放大」。 這無法在基本層或標準層上啟用。

這項變更必須在程式碼中實作。 方法如下。

#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 資料庫。

檢定您的知識

1.

您可使用哪一項來管理一組相同且負載平衡的 VM？

2.

下列哪一個產品供應項目，是以 Azure 儲存體為基礎所建置的簡易 REST 式佇列介面？