對於技術人員來說，「架構」是一個再常見不過的詞了。我們會對新員工培訓整個系統的架構，參加架構設計評審，學習業界開源系統（例如，MySQL、Hadoop）的架構，研究大公司的架構實現（例如，微信架構、淘寶架構）……雖然「架構」這個詞常見，但如果深究一下「架構」到底指什麼，大部分人也許並不一定能夠準確地回答。例如：
架構和框架是什麼關係？有什麼區別？
Linux 有架構，MySQL 有架構，JVM 也有架構，使用 Java 開發、MySQL 儲存、跑在 Linux 上的業務系統也有架構，應該關注哪個架構呢？
微信有架構，微信的登入系統也有架構，微信的支付系統也有架構，當我們談微信架構時，到底是在談什麼架構？
要想準確地回答這幾個問題，關鍵在於梳理幾個有關係而又相似的概念，包括：系統與子系統、模組與元件、框架與架構。
系統與子系統
我們先來看維基百科定義的「系統」。
系統泛指由一群有關聯的個體組成，根據某種規則運作，能完成個別元件不能單獨完成的工作的群體。它的意思是「總體」「整體」或「聯盟」。
我來提煉一下里面的關鍵內容：
關聯：系統是由一群有關聯的個體組成的，沒有關聯的個體堆在一起不能成為一個系統。例如，把一個發動機和一臺 PC 放在一起不能稱之為一個系統，把發動機、底盤、輪胎、車架組合起來才能成為一臺汽車。
規則：系統內的個體需要按照指定的規則運作，而不是單個個體各自為政。規則規定了系統內個體分工和共同作業的方式。例如，汽車發動機負責產生動力，然後通過變速器和傳動軸，將動力輸出到車輪上，從而驅動汽車前進。
能力：系統能力與個體能力有本質的差別，系統能力不是個體能力之和，而是產生了新的能力。例如，汽車能夠載重前進，而發動機、變速器、傳動軸、車輪本身都不具備這樣的能力。
我們再來看子系統的定義。
子系統也是由一群有關聯的個體所組成的系統，多半會是更大系統中的一部分。
其實子系統的定義和系統定義是一樣的，只是觀察的角度有差異，一個系統可能是另外一個更大系統的子系統。
按照這個定義，系統和子系統比較容易理解。我們以微信為例來做一個分析。
微信本身是一個系統，包含聊天、登入、支付、朋友圈等子系統。
朋友圈這個系統又包括動態、評論、點贊等子系統。
評論這個系統可能又包括防刷子系統、稽核子系統、釋出子系統、儲存子系統。
評論稽核子系統不再包含業務意義上的子系統，而是包括各個模組或者元件，這些模組或者元件本身也是另外一個維度上的系統。例如，MySQL、Redis 等是儲存系統，但不是業務子系統。
模組與元件
模組和元件兩個概念在實際工作中很容易混淆，我們經常能夠聽到類似這樣的說法：
MySQL 模組主要負責儲存資料，而 ElasticSearch 模組主要負責資料搜尋。
我們有安全加密元件、有稽核元件。
App 的下載模組使用了第三方的元件。
造成這種現象的主要原因是，模組與元件的定義並不好理解，也不能很好地進行區分。我們來看看這兩者在維基百科上的定義。
軟體模組（Module）是一套一致而互相有緊密關連的軟體組織。它分別包含了程式和資料結構兩部分。現代軟體開發往往利用模組作為合成的單位。模組的介面表達了由該模組提供的功能和呼叫它時所需的元素。模組是可能分開被編寫的單位。這使它們可再用和允許人員同時共同作業、編寫及研究不同的模組。
軟體元件定義為自包含的、可程式化的、可重用的、與語言無關的軟體單元，軟體元件可以很容易被用於組裝應用程式中。
可能你看完這兩個定義後一頭霧水，還是不知道這兩者有什麼區別。造成這種現象的根本原因是，模組和元件都是系統的組成部分，只是從不同的角度拆分系統而已。
從邏輯的角度來拆分系統後，得到的單元就是「模組」；從物理的角度來拆分系統後，得到的單元就是「元件」。劃分模組的主要目的是職責分離；劃分元件的主要目的是單元複用。其實，「元件」的英文 component 也可翻譯成中文的「零件」一詞，「零件」更容易理解一些，「零件」是一個物理的概念，並且具備「獨立且可替換」的特點。
我以一個最簡單的網站系統來為例。假設我們要做一個學生資訊管理系統，這個系統從邏輯的角度來拆分，可以分為「登入註冊模組」「個人資訊模組」「個人成績模組」；從物理的角度來拆分，可以拆分為 Nginx、Web 伺服器、MySQL。
框架與架構
框架是和架構比較相似的概念，且兩者有較強的關聯關係，所以在實際工作中，這兩個概念有時我們容易分不清楚。參考維基百科上框架與架構的定義，我來解釋兩者的區別。
軟體框架（Software framework）通常指的是為了實現某個業界標準或完成特定基本任務的軟體元件規範，也指為了實現某個軟體元件規範時，提供規範所要求之基礎功能的軟體產品。
我來提煉一下其中關鍵部分：
框架是元件規範：例如，MVC 就是一種最常見的開發規範，類似的還有 MVP、MVVM、J2EE 等框架。
框架提供基礎功能的產品：例如，Spring MVC 是 MVC 的開發框架，除了滿足 MVC 的規範，Spring 提供了很多基礎功能來幫助我們實現功能，包括註解（@Controller 等）、Spring Security、Spring JPA 等很多基礎功能。
軟體架構指軟體系統的「基礎結構」，創造這些基礎結構的準則，以及對這些結構的描述。
單純從定義的角度來看，框架和架構的區別還是比較明顯的，框架關注的是「規範」，架構關注的是「結構」。框架的英文是 Framework，架構的英文是 Architecture。Spring MVC 的英文檔案標題就是「Web MVC framework」。
雖然如此，在實際工作中我們卻經常碰到一些似是而非的說法。例如，「我們的系統是 MVC 架構」「我們需要將 android app 重構為 MVP 架構」「我們的系統基於 SSH 框架開發」「我們是 SSH 的架構」「XX 系統是基於 Spring MVC 框架開發，標準的 MVC 架構」……
究竟什麼說法是對的，什麼說法是錯的呢？
其實這些說法都是對的，造成這種現象的根本原因隱藏於架構的定義中，關鍵就是「基礎結構」這個概念並沒有明確說是從什麼角度來分解的。採用不同的角度或者維度，可以將系統劃分為不同的結構，其實我在「模組與元件」中的「學生管理系統」範例已經包含了這點。
從業務邏輯的角度分解，「學生管理系統」的架構是：
從物理部署的角度分解，「學生管理系統」的架構是：
從開發規範的角度分解，「學生管理系統」可以採用標準的 MVC 框架來開發，因此架構又變成了 MVC 架構：
這些「架構」，都是「學生管理系統」正確的架構，只是從不同的角度來分解而已，這也是 IBM 的 RUP 將軟體架構檢視分為著名的「4+1 檢視」的原因。
重新定義架構
參考維基百科的定義，我將架構重新定義為：軟體架構指軟體系統的頂層結構。
這個定義看似很簡單，但包含的資訊很豐富，基本上把系統、子系統、模組、元件、架構等概念都串起來了，我來詳細解釋一下。
首先，「系統是一群關聯個體組成」，這些「個體」可以是「子系統」「模組」「元件」等；架構需要明確系統包含哪些「個體」。
其次，系統中的個體需要「根據某種規則」運作，架構需要明確個體運作和共同作業的規則。
第三，維基百科定義的架構用到了「基礎結構」這個說法，我改為「頂層結構」，可以更好地區分系統和子系統，避免將系統架構和子系統架構混淆在一起導致架構層次混亂。
小結
今天我為你梳理了與架構有關的幾個容易混淆的概念，包括系統與子系統、模組與元件、框架與架構，解釋了架構的定義，希望對你有所幫助。
這就是今天的全部內容，留一道思考題給你吧。你原來理解的架構是如何定義的？對比我今天講的架構定義，你覺得差異在哪裡？