針對簡單和效率進行設計的建議
適用於此 Azure 架構完善框架的可靠性檢查清單建議：
| RE：01 | 將工作負載設計集中於簡單與效率。 使用實用的方法來避免不必要的複雜度，同時符合您的商務目標和需求。 |
|---|
本指南說明將不必要的複雜度和額外負荷降至最低的建議，讓您的工作負載保持簡單且有效率。 選擇最佳元件來執行必要的工作負載工作，以優化工作負載的可靠性。 若要減輕您的開發和管理負擔，請利用平臺提供服務所提供的效率。 此設計可協助您建立可復原、可重複、可調整且可管理的工作負載架構。
定義
| 術語 | 定義 |
|---|---|
| 工作負載 | 您可以以邏輯方式與其他工作分開的離散功能或計算工作。 |
關鍵設計策略
設計可靠性的關鍵原則是讓事情保持簡單且有效率。 將工作負載設計的重點放在符合商務需求上，以降低不必要的複雜度或額外負荷的風險。 請考慮本文中的建議，以協助您決定設計以建立精簡、有效率且可靠的工作負載。 不同的工作負載對於可用性、延展性、數據一致性和災害復原可能會有不同的需求。
您必須使用商務需求來證明每個設計決策的合理性。 此設計原則看起來可能很明顯，但對於工作負載設計而言非常重要。 您的應用程式是否支持數百萬個使用者，或數千個使用者？ 是否有大型流量突增，或是穩定的工作負載？ 可接受的應用程式中斷層級為何？ 商務需求會推動這些設計考慮。
取捨：複雜的解決方案可以提供更多的功能和彈性，但它可能會影響工作負載的可靠性，因為需要更多的協調、溝通和元件管理。 或者，較簡單的解決方案可能無法完全滿足使用者的期望，或可能會隨著工作負載的發展而對延展性和擴充性產生負面影響。
在設計練習上與項目關係人共同作業
請與項目關係人合作：
定義並指派關鍵性層級給工作負載的使用者流程和系統流程。 將設計焦點放在重要流程上，以協助您判斷必要的元件，以及達到所需復原層級的最佳方法。
定義功能和非功能需求。 請考慮功能需求，以判斷應用程式是否執行工作。 請考慮非功能需求，以判斷應用程式執行工作的方式。 請確定您瞭解非功能性需求，例如延展性、可用性和延遲。 這些需求會影響設計決策和技術選擇。
將工作負載分解成元件。 排定設計中的簡單性、效率和可靠性的優先順序。 確定支援您的流程所需的元件。 某些元件支援多個流程。 識別元件在概念上解決哪些挑戰，並考慮從個別流程中移除元件，以簡化整體設計，同時仍提供完整的功能。 如需詳細資訊，請參閱 執行失敗模式分析的建議。
使用失敗模式分析 來識別單一失敗點和潛在風險。 請考慮您是否需要應對不太可能發生的情況，例如一個地區發生重大自然災害，導致影響該地區所有可用性區域。 成本高昂，涉及重大取捨，以減輕這些罕見的風險。 清楚瞭解您企業對風險承受能力。 如需詳細資訊，請參閱 執行失敗模式分析的建議。
定義流程的可用性和復原目標 ，以通知工作負載的架構。 商務計量包括服務等級目標（SLA）、服務等級協定（SLA）、平均復原時間（MTTR）、平均失敗時間（MTBF）、恢復時間目標（RTO）和恢復點目標（RPO）。 定義這些計量的目標值。 此練習可能需要技術與商務小組之間的妥協和相互瞭解，以確保每個小組的目標符合商務目標，而且都是現實的。 如需詳細資訊，請參閱 定義可靠性目標的建議。
偏好更簡單的設計選擇
您可以執行下列建議，而不需要項目關係人參與：
努力在設計中求簡單明瞭 。 針對您的元件和服務，使用適當的抽象和粒度層級。 避免解決方案的過度設計或設計不足。 例如，如果您將程式代碼細分成多個小型函式，則很難瞭解、測試和維護。
確實所有成功的應用程式都會隨著時間變化，無論是修正程式錯誤、實作新功能或新技術，還是讓現有系統更具擴展性和彈性。
盡可能使用平臺即服務 （PaaS） 選項 ，而不是基礎結構即服務 （IaaS）。 IaaS 如同擁有一箱組件。 您可以建造任何東西，但必須自己組裝。 PaaS 選項較容易進行設定和管理。 您不需要設定虛擬機（VM）或虛擬網路。 您也不需要執行維護工作，例如安裝修補程式和更新。
使用異步傳訊 將訊息產生者與取用者分離。
將基礎結構抽象化，遠離領域邏輯。 請確定網域邏輯不會干擾基礎結構相關功能，例如傳訊或持續性。
將橫切關注點移交給個別的服務。 將跨不同函式重複程序代碼的需求降到最低，偏好使用定義完善的介面重複使用服務，這些介面可由不同元件輕鬆取用。 例如，如果數個服務需要驗證要求，您可以將此功能移至它自己的服務。 然後，您可以發展驗證服務。 例如，您可以新增驗證流程，而不需要觸及任何使用該流程的服務。
評估常見模式和做法對您需求的適用性。 請避免遵循可能不適合您內容或需求的趨勢或建議。 例如，微服務並不是每個應用程式的最佳選項，因為它們可能會帶來複雜度、額外負荷和相依性問題。
開發足夠的程序代碼
簡單、效率和可靠性的原則也適用於您的開發做法。 在鬆散結合的元件化工作負載中，判斷元件所提供的功能。 開發您的流程以利用該功能。 請針對您的開發實務考慮這些建議：
當平臺功能符合您的業務需求時，請加以利用。 例如，若要卸除開發和管理，請使用雲端提供者所提供的低程式碼、無程式代碼或無伺服器解決方案。
使用程式庫和架構。
將結對編程或專門的程式碼審查會議作為開發實作方式。
實施辨識死代碼的方法。 對自動化測試未涵蓋的程式代碼持懷疑態度。
選取正確的數據存放區
過去，許多組織會將所有數據儲存在大型關係型 SQL 資料庫中。 關係資料庫可為關聯資料交易提供原子性、一致性、隔離性及持久性（ACID）的保證。 但這些資料庫有缺點：
查詢可能需要昂貴的連接。
您需要正規化數據，並針對寫入上的架構進行重組。
鎖定爭用可能會影響性能。
關係資料庫的替代方案
在大型解決方案中，單一數據存放區技術可能不符合您的所有需求。 關聯資料庫的替代方案包括：
鍵值存儲系統
文件資料庫
搜尋引擎資料庫
時間序列資料庫
列族資料庫
圖形資料庫
每個選項都有優缺點。 不同的數據類型更適合不同的資料存放區類型。 挑選最適合您數據的儲存技術，以及其使用方式。
例如，您可以將產品目錄儲存在文件資料庫中，例如支援彈性架構的 Azure Cosmos DB。 每個產品描述都是獨立的檔。 對於整個目錄的查詢，您可以編製目錄的索引，並將索引儲存在 Azure 認知搜尋 中。 產品清查可能會進入 SQL 資料庫，因為該數據需要 ACID 保證。
建議
請考慮其他數據存放區。 關係資料庫不一定適合。 如需詳細資訊，請參閱 瞭解資料儲存模型。
請記住，數據不僅包含保存的應用程式數據。 它也包含應用程式記錄、事件、訊息和快取。
採用多語言持久性或使用多種資料庫技術組合的解決方案。
請考慮您擁有的數據類型。 例如，儲存：
SQL 資料庫中的事務數據。
文件資料庫中的 JSON 文件。
時間序列資料庫中的遙測。
Azure 認知搜尋中的應用程式日誌。
Azure Blob 儲存體 中的 Blob。
將可用性置於一致性之上。 CAP 定理表示您必須在分散式系統中的可用性與一致性之間進行取捨。 您無法完全避免網路分割，這是 CAP 定理的另一個元件。 但您可以採用最終一致性模型來達到更高的可用性。
請考慮開發小組的技能組合。 使用多語持久性有優點，但有可能過度使用。 它需要新的技能集來採用新的數據儲存技術。 若要充分利用技術，您的開發小組必須：
優化查詢。
優化效能表現。
使用適當的使用模式。
當您選擇記憶體技術時，請考慮這些因素：
使用補償交易。 使用多語言持久性時，單筆交易可能會將資料寫入多個資料庫。 如果發生失敗，請使用補償交易來復原任何已完成的步驟。
請考慮限定內容，這是網域導向的設計概念。 限定內容是定義域模型周圍的明確界限。 限定內容會定義模型所套用之定義域的哪些部分。 在理想情況下，限定內容會對應至商務網域的子域。 考慮在系統中的限定上下文中使用 polyglot persistence。 例如，產品可能會出現在產品目錄子域和產品庫存子域。 但最可能，這兩個子域對於儲存、更新和查詢產品有不同的需求。
Azure 支援服務
Azure 提供下列服務：
Azure Functions 是無伺服器計算服務，可讓您使用最少的程式代碼來建置協調流程。
Azure Logic Apps 是無伺服器工作流程整合平臺，可讓您使用 GUI 或編輯組態檔來建置協調流程。
Azure 事件網格 是高度可擴展且完全受控的發佈-訂閱消息分發服務，提供使用 MQTT 和 HTTP 協議的彈性消息消費模式。 使用事件方格，您可以使用裝置資料建置數據管線、建置事件驅動的無伺服器架構，以及整合應用程式。
如需詳細資訊，請參閱
範例
如需根據需求決定元件及其功能的範例工作負載，請參閱 Reliable Web App 模式。
相關連結
可靠性檢查清單
請參閱一組完整的建議。
可靠性檢查清單