了解工作負載

若要套用架構，請先了解您要分析的工作負載。系統架構圖為記錄系統最相關的細節提供了一個起點。但是，嘗試分析整個工作負載可能很複雜，因為許多系統都有許多元件和互動。相反，我們建議您專注於用戶故事，這是從最終使用者的角度撰寫的軟體功能的非正式、一般說明。他們的目的是說明軟件功能如何為客戶提供價值。然後，您可以使用架構圖和資料流程圖來建立這些使用者故事的模型，以便更輕鬆地評估提供上述業務功能的技術元件。例如，應用內移動遊戲購買解決方案可能有兩個用戶故事：「購買應用內點數」和「獲得應用內退款」，如下圖所示。（此示例架構突出顯示如何將系統分解為用戶故事；它不是為了表示高度彈性的應用程序。）

每個使用者故事都包含四個常見元件：程式碼和設定、基礎架構、資料存放區和外部相依性。您的圖表應包括所有這些組件，並反映組件之間的相互作用。例如，如果 Amazon API 閘道端點上有過多的負載，請考慮該如何將串聯載入系統中的其他元件，例如AWS Lambda函數或亞馬遜動態 B 表。追蹤這些互動可協助您瞭解失敗模式如何影響使用者故事。您可以使用資料流程圖或在架構圖中使用簡單的流程箭頭，以視覺化方式擷取此流程，如上圖所示。對於每個元件，請考慮擷取詳細資料，例如正在傳輸的資訊類型、接收的資訊、通訊是同步還是非同步，以及跨越哪些故障界限。在此範例中，DynamoDB 表會在兩個使用者故事中共用，如箭頭所示，指出應用程式內退款內文中的 Lambda 元件可存取應用程式內購買故事中的 DynamoDB 表格。這意味著由於應用內購買用戶故事導致的失敗可能會由於共享命運而級聯到應用內退款用戶故事中。

此外，瞭解每個元件的基準組態也很重要。基準配置可識別條件約束，例如每秒交易的平均和最大數量、有效負載的大小上限、用戶端逾時，以及資源的預設或目前服務配額。如果您要建立新設計的模型，建議您記錄設計的功能需求並考慮限制。這可協助您瞭解失敗模式如何在元件中顯示出來。

最後，您應該根據用戶故事提供的商業價值來確定用戶故事的優先級。此優先順序可協助您首先專注於工作負載最重要的功能。然後，您可以將分析集中在作為該功能關鍵路徑一部分的工作負載元件上，並更快地利用架構來實現價值。當您遍歷該過程時，您可以按照不同的優先級檢查其他用戶故事。