架構風格是一系列具有某些共同特征的架構。例如，n層是一種常見的體系結構樣式。最近，微服務體系結構開始受到青睞。架構風格不需要使用特定的技術，但是有些技術非常適合特定的架構。例如，容器自然適合于微服務。

我們已經確定了一組在云應用程序中常見的體系結構樣式。每種風格的文章包括:

1. 樣式的描述和邏輯關系圖。

2. 建議何時選擇這種風格。

3. 好處、挑戰(zhàn)和最佳實踐。

4. 推薦使用相關Azure服務進行部署。

快速瀏覽一下這些風格

本節(jié)將快速介紹我們已經確定的體系結構樣式，以及使用它們的一些高級注意事項。閱讀相關主題的更多細節(jié)。

n層

n層是企業(yè)應用程序的傳統(tǒng)體系結構。依賴項是通過將應用程序劃分為執(zhí)行邏輯功能(如表示、業(yè)務邏輯和數(shù)據訪問)的層來管理的。一個層只能調用它下面的層。然而，這種水平分層可能是一種不利因素。在不觸及應用程序其余部分的情況下，在應用程序的一部分中引入更改是很困難的。這使得頻繁的更新成為一個挑戰(zhàn)，限制了新功能添加的速度。

N-tier非常適合遷移已經使用分層架構的現(xiàn)有應用程序。由于這個原因，n層最常出現(xiàn)在基礎設施即服務(IaaS)解決方案中，或使用IaaS和托管服務組合的應用程序中。

Web-Queue-Worker

對于純粹的PaaS解決方案，可以考慮web隊列工作人員體系結構。在這種風格中，應用程序有一個處理HTTP請求的web前端和一個執(zhí)行cpu密集型任務或長時間運行操作的后端工作者。前端通過異步消息隊列與工作人員通信。

Web-queue-worker適用于一些相對簡單的域，這些域具有一些資源密集型任務。與n層一樣，體系結構很容易理解。托管服務的使用簡化了部署和操作。但是對于復雜的域，可能很難管理依賴關系。前端和工作人員很容易變成大型的、難以維護和更新的單片組件。與N-tier一樣，這可以減少更新頻率并限制創(chuàng)新。

Microservices

如果您的應用程序具有更復雜的域，則考慮遷移到微服務體系結構。微服務應用程序由許多小型的獨立服務組成。每個服務實現(xiàn)單個業(yè)務功能。服務是松散耦合的，通過API契約進行通信。

每個服務都可以由一個小型的、專注的開發(fā)團隊構建。單個服務的部署不需要團隊之間的大量協(xié)調，這鼓勵了頻繁的更新。微服務體系結構的構建和管理比n層或web隊列工作人員更復雜。它需要成熟的開發(fā)和DevOps文化。但是如果處理得當，這種風格可以導致更高的發(fā)布速度、更快的創(chuàng)新和更有彈性的架構。

事件驅動架構

事件驅動的體系結構使用發(fā)布-訂閱(發(fā)布-訂閱)模型，生產者發(fā)布事件，消費者訂閱事件。生產者獨立于消費者，消費者相互獨立。

考慮一個事件驅動的架構，用于以極低延遲攝取和處理大量數(shù)據的應用程序，如IoT解決方案。當不同的子系統(tǒng)必須對相同的事件數(shù)據執(zhí)行不同類型的處理時，這種樣式也很有用。

大數(shù)據，大計算

大數(shù)據和大計算是適用于特定配置文件的特定工作負載的特定體系結構樣式。大數(shù)據將非常大的數(shù)據集劃分為塊，在整個集合上執(zhí)行并行處理，用于分析和報告。大計算，也稱為高性能計算(HPC)，在大量(數(shù)千個)核上進行并行計算。領域包括模擬、建模和3-D渲染。

作為約束的體系結構樣式

體系結構樣式對設計施加約束，包括可以出現(xiàn)的元素集和這些元素之間允許的關系。約束通過限制選擇的范圍來指導架構的“形狀”。當架構符合特定樣式的約束時，就會出現(xiàn)某些需要的屬性。

例如，微服務的約束包括:

1. 服務代表單一職責。

2. 每一種服務都是相互獨立的。

3. 數(shù)據對于擁有它的服務是私有的。服務不共享數(shù)據。

通過遵守這些約束，出現(xiàn)的是一個可以獨立部署服務、隔離故障、可能頻繁更新并且很容易將新技術引入應用程序的系統(tǒng)。

在選擇體系結構樣式之前，請確保了解該樣式的基本原則和約束。否則，您可能最終得到的設計在表面上符合該風格，但并沒有實現(xiàn)該風格的全部潛力。務實也很重要。有時候，放松約束比堅持建筑的純粹性更好。

下表總結了每種樣式如何管理依賴項，以及最適合每種樣式的域類型。

考慮挑戰(zhàn)和好處

約束也會帶來挑戰(zhàn)，因此在采用任何一種樣式時，理解其中的利弊是很重要的。對于這個子域和有限的上下文，體系結構風格的好處是否大于挑戰(zhàn)?

以下是一些選擇架構風格時需要考慮的挑戰(zhàn)類型:

1. 復雜性。體系結構的復雜性是否適合您的領域?相反，這種風格對您的域來說太簡單了嗎?在這種情況下，您可能會得到一個“大泥球”，因為體系結構不能幫助您干凈地管理依賴項。

2. 異步消息傳遞和最終的一致性。異步消息傳遞可以用來解耦服務，提高可靠性(因為消息可以重試)和可伸縮性。然而，這也給處理最終的一致性以及重復消息的可能性帶來了挑戰(zhàn)。

3. 服務間的通信。在將應用程序分解為單獨的服務時，存在這樣的風險:服務之間的通信將導致不可接受的延遲或造成網絡擁塞(例如，在微服務體系結構中)。

4. 可管理性。管理應用程序、監(jiān)視、部署更新等有多難?