一篇文章告訴你什么是架構(gòu)模式和架構(gòu)風格

本文探討如下幾個問題：

• 架構(gòu)模式和架構(gòu)風格有區(qū)別嗎？
• 什么是架構(gòu)模式？
• 什么是架構(gòu)風格？
• 架構(gòu)模式和架構(gòu)風格的區(qū)別是什么？
• 有哪些架構(gòu)模式？
• 有哪些架構(gòu)風格？

架構(gòu)模式=架構(gòu)風格？

如果你搜索「架構(gòu)模式和架構(gòu)風格的區(qū)別」，你會發(fā)現(xiàn)答案千差萬別：

• 有的觀點認為架構(gòu)模式和架構(gòu)風格是一個東西，只是叫法不同
• 有的觀點認為架構(gòu)風格是架構(gòu)模式的外在表現(xiàn)
• 有的觀點認為架構(gòu)模式和架構(gòu)風格是不同的兩個概念（具體有什么不同，又有不同的觀點）
• 有的觀點認為架構(gòu)模式解決問題，架構(gòu)風格不解決問題(例如：建房子有建房子的模式，而無論是建成哥特風還是現(xiàn)代風，都還是房子)
• 有的觀點認為架構(gòu)風格是高層級的架構(gòu)模式

我個人的觀點是：架構(gòu)模式是特定問題域下，架構(gòu)風格的具體應用！

我們來一個個的說！

什么是架構(gòu)模式？

在說架構(gòu)模式之前，我們先來看看我們常掛在嘴邊的設計模式是怎么定義的！

GOF在《Design Patterns》這本書的「What is a Design Pattern?」小節(jié)，對設計模式下了一個明確的定義：

The design patterns in this book are descriptions of communicating objects and classes that are customized to solve a general design problem in a particular context.

設計模式描述了一組類和對象的關系，用以解決特定上下文內(nèi)的某個常見的設計問題！

那我們可以這么定義架構(gòu)模式：架構(gòu)模式描述了一組組件之間的關系，用以解決特定上下文內(nèi)的某個常見的架構(gòu)問題！

Wiki上也給架構(gòu)模式做了類似的定義：

An architectural pattern is a general, reusable solution to a commonly occurring problem in software architecture within a given context

架構(gòu)模式是一個通用的、可重用的解決方案，用以解決特定上下文內(nèi)的某個常見的架構(gòu)問題！

什么是架構(gòu)風格?

Roy Thomas Fielding博士，在他的REST論文中，對架構(gòu)風格做出了定義：

An architectural style is a coordinated set of architectural constraints that restricts the roles/features of architectural elements and the allowed relationships among those elements within any architecture that conforms to that style.

一種架構(gòu)風格是一組協(xié)作的架構(gòu)約束，這些約束限制了架構(gòu)元素的角色和功能，以及在任何一個遵循該風格的架構(gòu)中允許存在的元素之間的關系。

Martin Flower在微服務文章中的說明，也間接支持了此定義。文中首先明確「微服務」是一種架構(gòu)風格，然后給出了微服務所具有的特征（就是約束），具有這些約束的系統(tǒng)就可以說是使用了微服務架構(gòu)風格！

微軟的Azure文檔也給出了類似的定義：架構(gòu)風格即約束！

架構(gòu)模式和架構(gòu)風格的區(qū)別

上面我們分別給「架構(gòu)模式」和「架構(gòu)風格」下了定義！那么「架構(gòu)模式」和「架構(gòu)風格」到底有什么區(qū)別呢？

我們來看架構(gòu)模式的定義，可以抽出幾個關鍵詞：

• 模式：描述的是一種關系（類與類的關系、組件與組件的關系）！并且這種關系是可復用的！
• 特定上下文：說明這種關系的適用場景是有限制的，只能在特定場景下才能適用！
• 常見問題：說明這種關系是解決某個問題或某類問題的解決方案，是有針對性的！

我們再看架構(gòu)風格的定義，它僅僅就是約束！約束了組件之間的關系！

所以「架構(gòu)模式」和「架構(gòu)風格」的區(qū)別就在這里：

• 架構(gòu)模式是針對某個特定上下文的某類問題的解決方案
• 架構(gòu)風格是一個解決方案

舉個例子

如果你仔細看看Wiki中列出的架構(gòu)風格和架構(gòu)模式，你就能看出點端倪了！

你會發(fā)現(xiàn)，架構(gòu)風格中有「Multilayered」這個架構(gòu)風格，架構(gòu)模式里也有「Multilayered」架構(gòu)模式！好像分層架構(gòu)既是架構(gòu)風格，也是架構(gòu)模式！實際上架構(gòu)模式中的「分層架構(gòu)」是架構(gòu)風格中的「分層架構(gòu)」的實際應用。

更具有說服力的是CS架構(gòu)風格，可以看到此架構(gòu)風格后面有個闡述「2-tier, 3-tier, n-tier exhibit this style」，意思是兩層架構(gòu)、三層架構(gòu)、n層架構(gòu)都是CS架構(gòu)風格的一種表現(xiàn)形式。而可以看到，三層架構(gòu)是一個架構(gòu)模式！

你有沒有一個疑問？兩層架構(gòu)、三層架構(gòu)、N層架構(gòu)為什么不是分層架構(gòu)風格的表現(xiàn)形式？而是CS架構(gòu)風格的一種表現(xiàn)形式？

這個問題在后面的CS架構(gòu)和分層架構(gòu)中會具體闡述。

再具體一點，我們看看CS架構(gòu)的約束：

• Server組件提供了一組服務,并監(jiān)聽對這些服務的請求。
• Client組件通過一個連接器將請求發(fā)送到Server,希望執(zhí)行一個服務。
• Server可以拒絕這個請求,也可以執(zhí)行這個請求并將響應發(fā)送回Client

可以看到，這里只是約束了系統(tǒng)分為Client和Server，以及Server和Client之間的行為。

再來看三層架構(gòu)模式，三層架構(gòu)一般分為：

• Presentation tier 展現(xiàn)層
• Logic tier 業(yè)務邏輯層
• Data access tier 數(shù)據(jù)訪問層

可以看到，三層架構(gòu)模式比CS架構(gòu)風格更具體，描述了每一層的作用。

當系統(tǒng)有如下需求時，就可以考慮三層架構(gòu)：

• 需要提供用戶界面（不論是本地應用這樣的富客戶端、還是瀏覽器，亦或手機APP）
• 需要訪問持久層數(shù)據(jù)
• 解耦（視圖，業(yè)務、數(shù)據(jù)可獨立進化）

總結(jié)

用Renan Johannsen de Paula Venilton FalvoJr在《Architectural Patterns and Styles》中對架構(gòu)模式和架構(gòu)風格的區(qū)別來總結(jié)一下：

• Architecture Pattern: { problem, context } → architecture approach;
• Architecture Style: architecture approach.

實際工作中，我們一般會說「架構(gòu)」，而沒有具體到是「架構(gòu)風格」還是「架構(gòu)模式」。這么做其實有幾點好處：

• 理解的偏差，不影響討論和使用：雖然可能每個人對「架構(gòu)風格」和「架構(gòu)模式」的理解是有偏差的，但是并不會影響系統(tǒng)的討論。反而，如果具體到風格還是模式，那可能就變成對「風格」還是「模式」的討論，而不是對業(yè)務的討論
• 有些情況下，風格和模式的差異并不大：「架構(gòu)風格」和「架構(gòu)模式」的主要區(qū)別就是是否是針對某個「問題域」和「上下文」的！當一個「架構(gòu)風格」應用到了某個「問題域」和「上下文」，且這個「問題域」和「上下文」也比較常見，那么這個「架構(gòu)風格」在這個「問題域」和「上下文」的應用就是「架構(gòu)模式」！