架構樣式是共用特定特性的一系列架構。 例如， 多層 式是常見的架構樣式。 最近， 微服務架構 開始受到青睞。 架構樣式不需要使用特定技術，但某些技術更適合特定架構。 例如，容器非常適合微服務。
我們確定了一組在雲端應用程式中常見的架構樣式。 每種樣式的文章包括以下組件：
- 樣式的描述和邏輯圖
- 何時選擇這種款式的建議
- 優勢、挑戰和最佳實踐
- 使用相關 Azure 服務的建議部署
樣式快速導覽
本節快速介紹我們識別的架構樣式，以及使用它們的一些高階考量。 這份清單並不完整。 在鏈接的文章中閱讀更多詳細信息。
N 層架構
N 層 是企業應用程式的傳統架構，它將應用程式分為邏輯層和實體層。 每一層都有其特定責任，並且各層透過僅呼叫其下方層次來管理相依關係。 典型層包括簡報、業務邏輯和資料存取。
N 層架構非常適合移轉已使用分層架構的現有應用程式。 這種做法在你遷移到 Azure 時只需最小的改動，並且支援結合本地與雲端元件的混合環境。 但水平分層可能會使在不影響應用程式多個部分的情況下引入更改變得困難，這限制了頻繁更新的敏捷性。
網路佇列工作者
Web-Queue-Worker 是一種架構，由 Web 前端、訊息佇列和後端工作者組成。 Web 前端處理 HTTP 請求和使用者交互，而工作者則執行資源密集型任務、長時間運行的工作流程或批次操作。 前端和工作者之間的通訊是透過非同步訊息佇列進行的。
此架構非常適合具有具有一些資源密集型處理需求的相對簡單網域的應用程式。 使用 App Service 和 Azure Functions 等受控 Azure 服務很容易理解和部署。 您可以獨立擴展前端和工作程式，以提供資源分配的靈活性。 但如果不仔細設計，這兩個組件都可能變得龐大且單一。
微服務
微服務架構將應用程式分解為小型自治服務的集合。 每個服務都會在有限環境定義內實作單一商務功能，並具有自己的資料儲存體。 服務透過定義明確的 API 進行通信，並且可以獨立開發、部署和擴展。
微服務使團隊能夠自主工作，並以更高的發布速度支援頻繁更新。 這種架構非常適合需要頻繁更改和創新的複雜領域。 但它在服務發現、資料一致性和分散式系統管理等領域帶來了顯著的複雜性。 成功需要成熟的開發和DevOps實踐，這使得它更適合擁有先進技術能力的組織。
事件驅動架構
事件驅動架構 使用發佈-訂閱模型，其中事件生產者產生事件串流，而事件取用者則近乎即時地回應這些事件。 生產者和消費者彼此解耦，透過事件管道或代理進行通訊。 此體系結構支持簡單的事件處理和復雜的事件模式分析。
事件驅動架構在需要即時處理且延遲最小的場景中表現出色。 一些範例是 IoT 解決方案、金融交易系統或需要處理大量串流資料的應用程式。 事件驅動架構提供出色的可擴展性和故障隔離，但在保證交付、事件排序和分散式元件的最終一致性方面帶來了挑戰。
巨量數據
大數據 架構處理對傳統資料庫系統來說太大或過複雜的資料的擷取、處理和分析。 這些架構通常包括資料儲存元件（如資料湖）、用於歷史分析的批次處理、用於即時洞察的串流處理，以及用於報告和視覺化的分析資料存放區。
大數據架構對於需要從大量資料集中提取見解、使用機器學習支援預測分析或處理來自物聯網裝置的即時串流資料的組織至關重要。 新式實作通常會使用 Microsoft Fabric 等受控服務來簡化建置和維護巨量數據解決方案的複雜性。
大型計算
大型運算 架構支援需要數百或數千個核心進行運算密集型作業的大規模工作負載。 工作可以拆分為同時跨多個核心運行的離散任務，每個任務都接受輸入、處理輸入並產生輸出。 任務可以是獨立的（令人尷尬的並行），也可以是需要高速通信的緊密耦合。
大計算對於模擬、金融風險建模、科學計算、工程應力分析和 3D 渲染至關重要。 Azure 提供 Azure Batch 等選項，用於受控大型計算工作負載，或 HPC Pack 用於更傳統的叢集管理。 這些架構可以按需突增容量，並在需要時擴展到數千個核心。
架構樣式作為條件約束
架構樣式會將條件約束放在設計上，包括一組可以出現的元素，以及這些元素之間的允許關聯性。 條件約束會藉由限制選擇的宇宙來引導架構的「形狀」。 當架構符合特定樣式的條件約束時，會出現某些理想的屬性。
例如，微服務中的條件約束包括：
- 服務代表特定單一責任。
- 每個服務都與其他服務無關。
- 數據是專屬於擁有它的服務。 服務不會共享數據。
當您遵守這些限制時，您將獲得一個系統，可讓您採取以下操作：
- 獨立部署服務。
- 隔離故障。
- 推送更頻繁的更新。
- 更輕鬆地將新技術引入應用程序。
每個架構樣式都有自己的取捨。 選擇架構樣式之前，請務必瞭解基本原則和條件約束。 如果不瞭解，您有可能建立一個設計，表面上符合樣式，而不會實現其完整優點。 將焦點放在您選取特定樣式的原因，而不是如何實作它。 實事求是。 有時候放寬限制比追逐建築純潔更好。
在理想情況下，應該使用知情工作負載項目關係人的輸入來選擇架構樣式。 工作負載小組應從識別所要解決的問題本質開始。 然後，它們應該定義主要業務驅動因素和對應的架構特性，也稱為 非功能需求，並排定優先順序。 例如，如果上市時機至關重要，團隊可能會優先考慮維護性、可測試性和可靠性，以實現快速部署。 如果小組有嚴格的預算限制，可行性和簡單性可能會優先。 選取並維持架構樣式不是一次性工作。 其需要持續測量、驗證和精簡。 因為稍後變更架構方向的成本可能很高，因此通常值得先投入更多精力來支持長期效率並降低風險。
下表摘要說明每個樣式如何管理相依性，以及最適合每個樣式的網域類型。
| 架構樣式 | 相依性管理 | 網域類型 |
|---|---|---|
| N層架構 | 水平層由子網劃分 | 傳統商務領域。 更新的頻率很低。 |
| Web-Queue-Worker | 前端和後端工作以異步消息進行解耦。 | 相對簡單的領域，具有一些資源密集型任務。 |
| 微服務 | 垂直和功能性分解的服務通過 API 互相呼叫。 | 複雜的網域。 經常更新。 |
| 事件驅動架構 | 生產者或取用者。 每個子系統的獨立視圖。 | 物聯網 （IoT） 和即時系統。 |
| 巨量數據 | 將大型數據集分割成小區塊。 本機數據集上的並行處理。 | 批次和實時數據分析。 使用機器學習進行預測分析。 |
| 大型計算 | 數據分配至數千個核心。 | 計算密集的領域，例如模擬。 |
考慮挑戰和優點
限制也會帶來挑戰，因此了解採用這些風格時的權衡非常重要。 判斷架構樣式的優點是否超過挑戰，適用於 此子網域和有界內容。
當您選取架構樣式時，請考慮下列類型的挑戰：
複雜： 架構的複雜性必須與網域相符。 如果它過於簡單化，可能會導致大泥球架構，依賴關係沒有得到很好地管理，導致結構崩壞。
非同步傳訊和最終一致性： 非同步傳訊可用來解耦服務並增進可靠性，因為可以重試訊息。 它也會增強延展性。 不過，異步傳訊也會在處理最終一致性和重複訊息的可能性方面產生挑戰。
跨業務通信： 將應用程式分解為個別服務可能會增加通訊額外負荷。 在微服務架構中，此額外負荷通常會導致延遲問題或網路壅塞。
可管理性： 管理應用程式包括監視、部署更新和維護作業健康情況等工作。
相關資源
- Azure 應用程式的十項設計原則