對於技術人員來說，“架構”是一個再常見不過的詞了。我們會對新員工培訓整個系統的架構，參加架構設計評審，學習業界開源系統（例如，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 視圖”的原因。
重新定義架構
參考維基百科的定義，我將架構重新定義爲：軟件架構指軟件系統的頂層結構。
這個定義看似很簡單，但包含的信息很豐富，基本上把系統、子系統、模塊、組件、架構等概念都串起來了，我來詳細解釋一下。
首先，“系統是一羣關聯個體組成”，這些“個體”可以是“子系統”“模塊”“組件”等；架構需要明確系統包含哪些“個體”。
其次，系統中的個體需要“根據某種規則”運作，架構需要明確個體運作和協作的規則。
第三，維基百科定義的架構用到了“基礎結構”這個說法，我改爲“頂層結構”，可以更好地區分系統和子系統，避免將系統架構和子系統架構混淆在一起導致架構層次混亂。
小結
今天我爲你梳理了與架構有關的幾個容易混淆的概念，包括系統與子系統、模塊與組件、框架與架構，解釋了架構的定義，希望對你有所幫助。
這就是今天的全部內容，留一道思考題給你吧。你原來理解的架構是如何定義的？對比我今天講的架構定義，你覺得差異在哪裏？