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

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

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

定義

關鍵設計策略

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

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

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

在設計練習上與項目關係人共同作業

請與項目關係人合作：

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

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

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

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

• 定義流程的可用性和復原目標 ，以通知工作負載的架構。 商務計量包括服務等級目標（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 協議的彈性消息消費模式。 使用事件方格，您可以使用裝置資料建置數據管線、建置事件驅動的無伺服器架構，以及整合應用程式。

如需詳細資訊，請參閱

• 選擇 Azure 計算服務
• 選擇微服務的計算選項
• 檢閱您的數據選項

範例

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

相關連結

• Azure 無伺服器
• 雲端原生應用程式
• Azure 上的資料庫類型

可靠性檢查清單

請參閱一組完整的建議。