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

我們已經(jīng)確定了一組在云應(yīng)用程序中常見的體系結(jié)構(gòu)樣式。每種風(fēng)格的文章包括:

1. 樣式的描述和邏輯關(guān)系圖。

2. 建議何時(shí)選擇這種風(fēng)格。

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

4. 推薦使用相關(guān)Azure服務(wù)進(jìn)行部署。

快速瀏覽一下這些風(fēng)格

本節(jié)將快速介紹我們已經(jīng)確定的體系結(jié)構(gòu)樣式，以及使用它們的一些高級注意事項(xiàng)。閱讀相關(guān)主題的更多細(xì)節(jié)。

n層

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

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

Web-Queue-Worker

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

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

Microservices

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

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

事件驅(qū)動(dòng)架構(gòu)

事件驅(qū)動(dòng)的體系結(jié)構(gòu)使用發(fā)布-訂閱(發(fā)布-訂閱)模型，生產(chǎn)者發(fā)布事件，消費(fèi)者訂閱事件。生產(chǎn)者獨(dú)立于消費(fèi)者，消費(fèi)者相互獨(dú)立。

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

大數(shù)據(jù)，大計(jì)算

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

作為約束的體系結(jié)構(gòu)樣式

體系結(jié)構(gòu)樣式對設(shè)計(jì)施加約束，包括可以出現(xiàn)的元素集和這些元素之間允許的關(guān)系。約束通過限制選擇的范圍來指導(dǎo)架構(gòu)的“形狀”。當(dāng)架構(gòu)符合特定樣式的約束時(shí)，就會(huì)出現(xiàn)某些需要的屬性。

例如，微服務(wù)的約束包括:

1. 服務(wù)代表單一職責(zé)。

2. 每一種服務(wù)都是相互獨(dú)立的。

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

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

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

下表總結(jié)了每種樣式如何管理依賴項(xiàng)，以及最適合每種樣式的域類型。

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

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

以下是一些選擇架構(gòu)風(fēng)格時(shí)需要考慮的挑戰(zhàn)類型:

1. 復(fù)雜性。體系結(jié)構(gòu)的復(fù)雜性是否適合您的領(lǐng)域?相反，這種風(fēng)格對您的域來說太簡單了嗎?在這種情況下，您可能會(huì)得到一個(gè)“大泥球”，因?yàn)轶w系結(jié)構(gòu)不能幫助您干凈地管理依賴項(xiàng)。

2. 異步消息傳遞和最終的一致性。異步消息傳遞可以用來解耦服務(wù)，提高可靠性(因?yàn)橄⒖梢灾卦?和可伸縮性。然而，這也給處理最終的一致性以及重復(fù)消息的可能性帶來了挑戰(zhàn)。

3. 服務(wù)間的通信。在將應(yīng)用程序分解為單獨(dú)的服務(wù)時(shí)，存在這樣的風(fēng)險(xiǎn):服務(wù)之間的通信將導(dǎo)致不可接受的延遲或造成網(wǎng)絡(luò)擁塞(例如，在微服務(wù)體系結(jié)構(gòu)中)。

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