1. 程式人生 > >什麼是架構模式和架構風格

什麼是架構模式和架構風格

本文探討如下幾個問題:

  • 架構模式和架構風格有區別嗎?
  • 什麼是架構模式?
  • 什麼是架構風格?
  • 架構模式和架構風格的區別是什麼?
  • 有哪些架構模式?
  • 有哪些架構風格?

架構模式=架構風格?

如果你搜索「架構模式和架構風格的區別」,你會發現答案千差萬別:

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

我個人的觀點是:架構模式是特定問題域下,架構風格的具體應用

我們來一個個的說!

什麼是架構模式?

在說架構模式之前,我們先來看看我們常掛在嘴邊的設計模式是怎麼定義的!

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

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. 設計模式描述了一組類和物件的關係,用以解決特定上下文內的某個常見的設計問題!

那我們可以這麼定義架構模式:架構模式描述了一組元件之間的關係,用以解決特定上下文內的某個常見的架構問題

Wiki上也給架構模式做了類似的定義:

An architectural pattern is a general, reusable solution to a commonly occurring problem in software architecture within a given context 架構模式是一個通用的、可重用的解決方案,用以解決特定上下文內的某個常見的架構問題!

什麼是架構風格?

Roy Thomas Fielding博士,在他的REST論文中,對架構風格做出了定義:

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. 一種架構風格是一組協作的架構約束,這些約束限制了架構元素的角色和功能,以及在任何一個遵循該風格的架構中允許存在的元素之間的關係。

Martin Flower在微服務文章中的說明,也間接支援了此定義。文中首先明確「微服務」是一種架構風格,然後給出了微服務所具有的特徵(就是約束),具有這些約束的系統就可以說是使用了微服務架構風格!

微軟的Azure文件也給出了類似的定義:架構風格即約束

架構模式和架構風格的區別

上面我們分別給「架構模式」和「架構風格」下了定義!那麼「架構模式」和「架構風格」到底有什麼區別呢?

我們來看架構模式的定義,可以抽出幾個關鍵詞:

  • 模式:描述的是一種關係(類與類的關係、元件與元件的關係)!並且這種關係是可複用的!
  • 特定上下文:說明這種關係的適用場景是有限制的,只能在特定場景下才能適用!
  • 常見問題:說明這種關係是解決某個問題或某類問題的解決方案,是有針對性的!

我們再看架構風格的定義,它僅僅就是約束!約束了元件之間的關係!

所以「架構模式」和「架構風格」的區別就在這裡:

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

舉個例子

如果你仔細看看Wiki中列出的架構風格和架構模式,你就能看出點端倪了!

架構模式 架構風格
Three-Tier Multilayered architecture Model-View-Controller(MVC) Domain Driven Design Micro-KernelBlackboard PatternSensor-Controller-Actuator Presentation–Abstraction–Control CQRS Component-based Monolithic application Layered (or multilayered architecture) Pipes and Filters Database-Centric Blackboard Rule-based Event-driven aka implicit invocation Publish-subscribe Asynchronous Messaging Plug-Ins Microkernel Reflection Domain Specific Languages(DSL) Client-Server (2-tier, 3-tier, n-tier exhibit this style) Shared Nothing Architecture Space-based Architecture Object Request Broker Peer-to-Peer Representational State Transfer (REST) Service-Oriented Cloud Computing Patterns MicroServices

你會發現,架構風格中有「Multilayered」這個架構風格,架構模式裡也有「Multilayered」架構模式!好像分層架構既是架構風格,也是架構模式!實際上架構模式中的「分層架構」是架構風格中的「分層架構」的實際應用。

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

你有沒有一個疑問?兩層架構、三層架構、N層架構為什麼不是分層架構風格的表現形式?而是CS架構風格的一種表現形式? 這個問題在後面的CS架構和分層架構中會具體闡述。

再具體一點,我們看看CS架構的約束:

  • Server元件提供了一組服務,並監聽對這些服務的請求。
  • Client元件通過一個聯結器將請求傳送到Server,希望執行一個服務。
  • Server可以拒絕這個請求,也可以執行這個請求並將響應傳送回Client

可以看到,這裡只是約束了系統分為Client和Server,以及Server和Client之間的行為。

再來看三層架構模式,三層架構一般分為:

  • Presentation tier 展現層
  • Logic tier 業務邏輯層
  • Data access tier 資料訪問層

可以看到,三層架構模式比CS架構風格更具體,描述了每一層的作用。 當系統有如下需求時,就可以考慮三層架構:

  • 需要提供使用者介面(不論是本地應用這樣的富客戶端、還是瀏覽器,亦或手機APP)
  • 需要訪問持久層資料
  • 解耦(檢視,業務、資料可獨立進化)

總結

用Renan Johannsen de Paula Venilton FalvoJr在《Architectural Patterns and Styles》中對架構模式和架構風格的區別來總結一下:

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

實際工作中,我們一般會說「架構」,而沒有具體到是「架構風格」還是「架構模式」。這麼做其實有幾點好處:

  • 理解的偏差,不影響討論和使用:雖然可能每個人對「架構風格」和「架構模式」的理解是有偏差的,但是並不會影響系統的討論。反而,如果具體到風格還是模式,那可能就變成對「風格」還是「模式」的討論,而不是對業務的討論
  • 有些情況下,風格和模式的差異並不大:「架構風格」和「架構模式」的主要區別就是是否是針對某個「問題域」和「上下文」的!當一個「架構風格」應用到了某個「問題域」和「上下文」,且這個「問題域」和「上下文」也比較常見,那麼這個「架構風格」在這個「問題域」和「上下文」的應用就是「架構模式」!
  • 可以少說兩個字

參考資料