系統架構（ ），軟件架構（Soft ）是 IT 領域常見的名詞，架構設計是軟件系統構建過程中極其關鍵的一部分。
系統架構為什么重要？常見的架構模式又有哪些呢？
一起來看下常見的架構模式：-、Peer to Peer、MVC、、-、Micro-、Even-、逐個擊破。
，原意建筑學，其實軟件架構的概念就是源于建筑學。建筑學是建筑物設計和建造相關的藝術和技術的綜合。建筑學是一門橫跨工程技術和人文藝術的學科。它研究的是建筑物可資使用的空間、可供欣賞的形象cs架構有哪些管理系統，以及圍繞空間、形象如何產生確立、調整美化等的一系列問題。并且其所研究的對象不僅是建筑物本身，更主要的是研究人們對建筑物的要求及其如何得以滿足，研究建筑物實體從無到有的產生過程中相應的策劃、設計、實施等。
建筑學研究建筑的規劃、設計和實施。軟件架構研究軟件的規劃、設計和實施。
在架構設計中，根據業務、技術、組織、靈活性、可擴展性以及可維護性等因素，將應用系統劃分成不同的部分，使這些部分之間相互分工、相互協作，從而完成特定的需求。架構貫穿系統實現的整個過程，是軟件系統實現的主要參考，是軟件系統實現的藍圖。軟件系統的規劃、設計和實施依架構的設計而組織實施。
系統架構為什么重要
我們知道摩爾定律——計算機硬件的能力大致每兩年提高一倍的速度發展。然而軟件開發的流程卻沒有這樣的提速過程，開發成本也沒有下降，系統架構的設計方法論和設計模式不斷變化，而這個重要的流程依舊沒有一個完全可靠和一勞永逸的解決方案。為什么？軟件開發過程有什么特別的難題？有下面幾點：
復雜性（）
軟件可以說是人類創造的最復雜的系統類型。軟件的各個模塊之間有各種顯性或隱性的依賴關系，隨著系統的成長和模塊的增多，這些關系的數量往往以幾何級數的速度增長。而理解運用這些復雜性的人并沒有太多的變化。
不可見性（）
軟件工程師能直接看見源代碼，但是源代碼不是軟件本身。并且靜態的源代碼和運行的系統也不一樣，軟件運行環境的復雜性也增加了軟件系統的不可預測性。軟件系統不能以簡單的方式描述出來，設計文檔，描述說明，流程圖，架構圖這些也不過是讓復雜的軟件系統以更易于理解和易于交流的方式展示，卻依舊不能完全描述系統的全貌。
易變性（）
修改軟件看似很容易，修改軟件比修改硬件容易多了，修改軟件系統也比修改一座巍立建筑物容易的多。所以人們自然地期待軟件系統能夠適應未來的變化。但變化卻是復雜的，環境也是復雜的，這些復雜的情況往往讓一個易于修改的事情卻變成一件越來越困難的事情。
服從性（）
軟件系統不能獨立存在，它總是運行在硬件上面，也總是要服從系統中其他組成部分的要求，也要服從用戶的要求、行業的要求。
軟件系統的以上特性使得系統架構的設計顯得尤其重要。系統架構設計通過以下方式來解決上面的軟件難題：
幾種架構模式-
cs
有了互聯網就有了 - 模式。- 模式以請求-響應方式工作，客戶端發送請求信息，服務端接受請求，作出相應處理，然后發回響應信息。所有我們訪問的互聯網網站都是這種架構。在桌面程序流行的時代，互聯網還沒有當前這么發達的時代。- 還只代表 - 模式，使用瀏覽器的方式稱之為 B-S 模式，即 - 模式。如今 、 、 、 Web 等統稱為 。
因此我們當前訪問的大部分網站，如新聞咨詢網站、博客網站等等都屬于這種模式。
Peer to Peer
p2p
端對端服務模式（Peer to Peer，簡稱 P2P），亦稱為“點對點模式”，是指通過互聯網將個人與個人連接起來，繞開中心平臺而直接提供服務、完成交易的模式。P2P 的早期含意是計算機通信領域中的“對等網絡協議”，它打破了傳統的 /(C/S)模式，使得成千上萬臺彼此連接的計算機都處于對等地位，網絡的參與者直接共享他們所擁有的一部分硬件資源（包括處理能力、存儲能力、網絡連接能力、打印機等），這些共享資源通過互聯網cs架構有哪些管理系統，能被其它對等節點(Peer)直接訪問而無需經過統一的中間體。在該網絡中的參與者既是資源（服務或內容）提供者（），又是資源獲取者（）。
P2P 模式流行于文件分享與下載、計算與存儲、即時通信和協同共享等領域。
MVC
mvc
Model-View-，MVC 架構是面向對象編程的一大進步。服務將邏輯劃分為三個不同的組建：Model——模型，即數據，通常存儲在數據庫中，在內存中進行邏輯操作。View——用戶可見的組建，用于用戶交互和數據展示，如 Web GUI。——邏輯操作，連接 Model 和 View 的組件，操作 Model 邏輯和 View 交互展示邏輯。
MVC 模式在客戶端和 H5 前端都比較流行。也一直是 Web 后端流行的架構模式，在 Java Web 領域催生的 、 MVC 等 Web 后臺框架，讓曾經復雜的 Web 開發變成一種異常簡單的開發。
隨著前后端漸漸分離，之前的后臺 MVC 已經將 View 完全交于前端，前后端通過相關協議通信，完成 View 數據的傳輸。
分層架構是運用最為廣泛的架構模式，幾乎每個軟件系統都需要通過層（Layer）來隔離不同的關注點（ Point），以此應對不同需求的變化，使得這種變化可以獨立進行。
單一職責原則，是系統設計開發重要的原則。分層架構就時時遵循單一職責原則。不同的層次相互隔離，承擔不同的職責。
說起分層架構，最讓人熟知的就是經典的三層架構。經典三層架構自頂向下由用戶界面層（User Layer）、業務邏輯層（ Logic Layer）與數據訪問層（Data Layer）組成。三層架構是簡單 - 架構的升級。
three-layer
三層架構的經典和流行，以及大量 Web 后臺框架對三層架構的靠近，使得 Web 后臺開發簡單到一個剛剛入門的開發人員就可以進行 web 開發。也正因為此，使得大部分 web 開發人員的思維受限于此，從而成為人人調侃的 CRUD-Boy。隨著 MIS 系統時代的漸遠，三層架構也開始在一些領域無法成為“銀彈“。
除去經典的三層架構。在領域驅動設計中，Eric Evans 設計了一種經典的四層架構，其在用戶界面層與業務邏輯層之間引入了新的一層，即應用層（ Layer）。其余幾層也相應的有所調整。
-
之上所提的架構都是在單體架構之下。單體架構和多服務架構是從服務的部署模式、運行模式來考慮。
單體架構有如下優勢：
單體應用的劣勢：
分布式系統拆分：
-scale
隨著互聯網的快速發展，一方面互聯網應用訪問量級大增，數據量大增。另一方面，應用的迭代速度也不斷變快。單體應用的模式已經不適合互聯網的快速發展。這樣，后臺分布式集群架構越來越流行。
Micro-
微服務并沒有一個嚴格的定義。以下是 描述的微服務：
微服務架構是一種架構模式，它提倡將單一應用程序劃分成一組小的服務，服務之間相互協調、相互配合，為用戶提供最終價值。每個服務運行在其獨立的進程中，服務與服務間采用輕量級的通信機制互相溝通（通常基于 HTTP 的 API）。每個服務都圍繞著具體業務進行構建，并且能夠被獨立地部署到生產環境。
微服務通常具有以下特性：
一切選擇都是權衡的過程。微服務解決了單體應用的許多問題，自然也會帶來相應的問題。分布式和集群的環境是復雜的，基于此的微服務架構也將具有相應的復雜度。
隨著微服務的流行，微服務的很多問題也被越來越多的框架和服務解決掉了。我們以 Cloud 技術棧為例：
micro--
事件溯源是最新流行一種應用程序體系結構模式。事件源將應用程序進行的狀態更改建模為事件的不可變序列或“日志”。事件源不是在現場修改應用程序的狀態，而是將觸發狀態更改的事件存儲在不可變的日志中，并將狀態更改建模為對日志中事件的響應。
event-
CQRS 模式通常基事件溯源模式。在傳統的體系結構中，使用同一數據模型查詢和更新數據庫。這十分簡單，非常適用于基本的 CRUD 操作。但是，在更復雜的應用程序中，此方法會變得難以操作。例如，在讀取方面，應用程序可能執行大量不同的查詢，返回具有不同形狀的數據傳輸對象 (DTO)。對象映射可能會變得復雜。在寫入方面，模型可能實施復雜驗證和業務邏輯。結果，模型執行太多操作，過度復雜。
CQRS（命令查詢的責任分離 Query ）將讀取和寫入操作分成不同的模型，使用命令更新數據，并使用查詢來讀取數據。
六邊形架構又稱“端口和適配器模式”，是 提出的一種具有對稱性特征的架構風格。在這種架構中，系統通過適配器的方式與外部交互，將應用服務與領域服務封裝在系統內部。
六邊形架構由以下三個組件組成：
六邊形架構的核心理念是：應用通過"端口"跟外部進行交互。在傳統的分層架構中很容易跨越層間的邊界，把業務邏輯滲透到其它層中去。六邊形架構重要的就是“邊界”和“領域”。六邊形架構的初衷是為了解決技術與業務系統的解耦合問題，以及技術與技術間的解耦合問題，這一架構從設計模式中來，從業務的實體服務出發，將面向接口的設計具體化的端口協議和適配器實現，服務自身實現獨立性和完備性。
參考：
《系統架構——復雜系統的產品設計與開發》丹尼爾·塞爾瓦
《構建之法——現代工程》鄒欣
《微服務架構與實現》王磊
《領域驅動設計——軟件核心復雜性應對之道》Eric Evans
《實現領域驅動設計》
《 Cloud 微服務實戰》翟永超
《工程學——無盡的前沿》歐陽瑩之
《人月神話》 P. , Jr.
往期資源 需要請自取
總結
每天進步一點點
慢一點才能更快