共用方式為

針對簡單和效率進行設計的建議

  • 發行項

適用於此 Azure 架構完善的架構可靠性檢查清單建議：

RE：01 設計您的工作負載以符合商務目標，並避免不必要的複雜度或額外負荷。 使用實用且平衡的方法，制定可提供所需結果的設計決策。 包含您的設計，以降低效率低下和潛在問題。

本指南說明將不必要的複雜度和額外負荷降至最低的建議，讓您的工作負載保持簡單且有效率。 選擇最佳元件來執行必要的工作負載工作，以優化工作負載的可靠性。 若要減輕您的開發和管理負擔，請利用平臺提供服務所提供的效率。 此設計可協助您建立可復原、可重複、可調整且可管理的工作負載架構。

定義

詞彙 定義
工作負載 您可以以邏輯方式與其他工作分開的離散功能或計算工作。

關鍵設計策略

設計可靠性的關鍵原則是讓事情保持簡單且有效率。 將工作負載設計的重點放在符合商務需求上，以降低不必要的複雜度或額外負荷的風險。 請考慮本文中的建議，以協助您決定設計以建立精簡、有效率且可靠的工作負載。 不同的工作負載對於可用性、延展性、數據一致性和災害復原可能會有不同的需求。

您必須使用商務需求來證明每個設計決策的合理性。 此設計原則看起來可能很明顯，但對於工作負載設計而言非常重要。 您的應用程式是否支持數百萬個使用者，或數千個使用者？ 是否有大型流量高載或穩定的工作負載？ 可接受的應用程式中斷層級為何？ 商務需求會推動這些設計考慮。

取捨：複雜的解決方案可以提供更多的功能和彈性，但它可能會影響工作負載的可靠性，因為它需要更多的協調、通訊和管理元件。 或者，較簡單的解決方案可能無法完全滿足使用者的期望，或可能會隨著工作負載的發展而對延展性和擴充性產生負面影響。

共同作業設計練習

請與項目關係人合作：

  • 定義並指派關鍵性層級給工作負載的使用者流程和系統流程。 將設計焦點放在重要流程上，以協助您判斷必要的元件，以及達到所需復原層級的最佳方法。

  • 定義功能和非功能需求。 請考慮功能需求，以判斷應用程式是否執行工作。 請考慮非功能需求，以判斷應用程式執行工作的方式。 請確定您瞭解非功能性需求，例如延展性、可用性和延遲。 這些需求會影響設計決策和技術選擇。

  • 將工作負載分解成元件。 排定設計中的簡單性、效率和可靠性的優先順序。 判斷您需要支援流程的元件。 某些元件支援多個流程。 識別元件在概念上解決哪些挑戰，並考慮從個別流程中移除元件，以簡化整體設計，同時仍提供完整的功能。 如需詳細資訊，請參閱 執行失敗模式分析的建議。

  • 使用失敗模式分析 來識別單一失敗點和潛在風險。 請考慮您是否需要考慮不太可能的情況，例如遇到影響該區域所有可用性區域的地理區域。 成本高昂，涉及重大取捨，以減輕這些罕見的風險。 清楚瞭解您企業對風險承受能力。 如需詳細資訊，請參閱 執行失敗模式分析的建議。

  • 定義流程的可用性和復原目標 ，以通知工作負載的架構。 商務計量包括服務等級目標（SLA）、服務等級協定（SLA）、平均復原時間（MTTR）、平均失敗時間（MTBF）、恢復時間目標（RTO）和恢復點目標（RPO）。 定義這些計量的目標值。 此練習可能需要技術與商務小組之間的妥協和相互瞭解，以確保每個小組的目標符合商務目標，而且都是現實的。 如需詳細資訊，請參閱 定義可靠性目標的建議。

其他設計建議

您可以執行下列建議，而不需要項目關係人參與：

  • 努力在設計中求簡單明瞭 。 針對您的元件和服務，使用適當的抽象和粒度層級。 避免過度工程或工程不足您的解決方案。 例如，如果您將程式代碼細分成多個小型函式，則很難瞭解、測試和維護。

  • 承認所有成功的應用程式都會隨著時間變更、修正 Bug、實作新功能或技術，或讓現有系統更具延展性和彈性。

  • 盡可能使用平臺即服務 （PaaS） 選項 ，而不是基礎結構即服務 （IaaS）。 IaaS 如同擁有一箱組件。 您可以建置任何專案，但您必須自行組合。 PaaS 選項較容易進行設定和管理。 您不需要設定虛擬機（VM）或虛擬網路。 您也不需要執行維護工作，例如安裝修補程式和更新。

  • 使用異步傳訊 將訊息產生者與取用者分離。

  • 將基礎結構抽象化，遠離領域邏輯。 請確定網域邏輯不會干擾基礎結構相關功能，例如傳訊或持續性。

  • 將跨領域考慮卸除至個別的服務。 將跨不同函式重複程序代碼的需求降到最低，偏好使用定義完善的介面重複使用服務，這些介面可由不同元件輕鬆取用。 例如，如果數個服務需要驗證要求，您可以將此功能移至它自己的服務。 然後，您可以發展驗證服務。 例如，您可以新增驗證流程，而不需要觸及任何使用該流程的服務。

  • 評估您需求的常見模式和做法 的適用性。 請避免遵循可能不適合您內容或需求的趨勢或建議。 例如，微服務並不是每個應用程式的最佳選項，因為它們可能會帶來複雜度、額外負荷和相依性問題。

開發足夠的程序代碼

簡單、效率和可靠性的原則也適用於您的開發做法。 在鬆散結合的元件化工作負載中，判斷元件所提供的功能。 開發您的流程以利用該功能。 請針對您的開發實務考慮這些建議：

  • 符合您的商務需求時，請使用平臺功能。 例如，若要卸除開發和管理，請使用雲端提供者所提供的低程式碼、無程式代碼或無伺服器解決方案。

  • 使用連結庫和架構。

  • 將配對程式設計或專用程式代碼檢閱會話介紹為開發實務。

  • 實作識別 無效程序代碼的方法。 對自動化測試未涵蓋的程式代碼持懷疑態度。

使用數據的最佳數據存放區

過去，許多組織會將所有數據儲存在大型關係型 SQL 資料庫中。 關係資料庫可為關係型數據交易提供不可部分完成、一致、隔離且持久的 （ACID） 保證。 但這些資料庫有缺點：

  • 查詢可能需要昂貴的聯結。

  • 您需要正規化數據，並針對寫入上的架構進行重組。

  • 鎖定爭用可能會影響效能。

關係資料庫的替代方案

在大型解決方案中，單一數據存放區技術可能不符合您的所有需求。 關聯資料庫的替代方案包括：

  • 機碼值存放區

  • 檔資料庫

  • 搜尋引擎資料庫

  • 時間序列資料庫

  • 數據列系列資料庫

  • 圖形資料庫

每個選項都有優缺點。 不同的數據類型更適合不同的資料存放區類型。 挑選最適合您數據的儲存技術，以及其使用方式。

例如，您可以將產品目錄儲存在文件資料庫中，例如支援彈性架構的 Azure Cosmos DB。 每個產品描述都是獨立的檔。 對於整個目錄的查詢，您可以編製目錄的索引，並將索引儲存在 Azure 認知搜尋 中。 產品清查可能會進入 SQL 資料庫，因為該數據需要 ACID 保證。

建議

  • 請考慮其他數據存放區。 關係資料庫不一定適合。 如需詳細資訊，請參閱 瞭解數據存放區模型。

  • 請記住，數據不僅包含保存的應用程式數據。 它也包含應用程式記錄、事件、訊息和快取。

  • 採用使用數據存放區技術組合的 polyglot 持續性或解決方案。

  • 請考慮您擁有的數據類型。 例如，儲存：

    • SQL 資料庫中的事務數據。

    • 檔資料庫中的 JSON 檔。

    • 時間序列資料庫中的遙測。

    • Azure 認知搜尋 中的應用程式記錄。

    • Azure Blob 儲存體 中的 Blob。

  • 將可用性設定為一致性的優先順序。 CAP 定理表示您必須在分散式系統中的可用性與一致性之間進行取捨。 您無法完全避免網路分割，這是 CAP 定理的另一個元件。 但您可以採用最終一致性模型來達到更高的可用性。

  • 請考慮開發小組的技能集。 使用 polyglot 持續性有優點，但有可能過度使用。 它需要新的技能集來採用新的數據儲存技術。 若要充分利用技術，您的開發小組必須：

    • 優化查詢。

    • 調整效能。

    • 使用適當的使用模式。

當您選擇記憶體技術時，請考慮這些因素：

  • 使用補償交易。 使用 polyglot 持續性時，單一交易可能會將數據寫入多個存放區。 如果發生失敗，請使用補償交易來復原任何已完成的步驟。

  • 請考慮限定內容，這是網域導向的設計概念。 限定內容是定義域模型周圍的明確界限。 限定內容會定義模型所套用之定義域的哪些部分。 在理想情況下，限定內容會對應至商務網域的子域。 針對系統中的限定內容，請考慮polyglot持續性。 例如，產品可能會出現在產品目錄子域和產品庫存子域。 但最可能，這兩個子域對於儲存、更新和查詢產品有不同的需求。

Azure 便利化

Azure 提供下列服務：

  • Azure Functions 是無伺服器計算服務，可讓您使用最少的程式代碼來建置協調流程。

  • Azure Logic Apps 是無伺服器工作流程整合平臺，可讓您使用 GUI 或編輯組態檔來建置協調流程。

  • Azure 事件方格 是高度可調整且完全受控的發佈-訂閱訊息散發服務，可提供使用 MQTT 和 HTTP 通訊協定的彈性訊息耗用量模式。 使用事件方格，您可以使用裝置資料建置數據管線、建置事件驅動的無伺服器架構，以及整合應用程式。

如需詳細資訊，請參閱

範例

如需根據需求決定元件及其功能的範例工作負載，請參閱 Reliable Web App 模式。

可靠性檢查清單

請參閱一組完整的建議。

可靠性檢查清單