針對簡單和效率進行設計的建議
適用於此 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 模式。
相關連結
可靠性檢查清單
請參閱一組完整的建議。