架構設計是技術人員成長和晉升過程中必須掌握的技能，雖然非常常見，但深究一下“架構”到底指什麼，有多少人能夠準確回答呢？
本文選自《從零開始學架構：照著做，你也能成為架構師》
對於技術人員來說，“架構”是一個再常見不過的詞了：我們會給新員工介紹整個系統的架構，參加架構設計評審，學習業界開源系統（例如，MySQL、Hadoop）的架構，研究大公司的架構實現（例如，微信架構、淘寶架構）……雖然如此常見，但如果深究一下“架構”到底指什麼，大部分人不一定能夠準確地回答。例如：
- 架構和框架是什麼關係？有什麼區別？
- Linux有架構，MySQL有架構，JVM也有架構，使用Java開發、MySQL存儲、跑在Linux上的業務系統也有架構，應該關注哪個架構呢？
- 微信有架構，微信的登錄系統也有架構，微信的支付系統也有架構，當我們談微信架構時，到底在談什麼架構？
要想準確地回答以上問題，關鍵在於梳理幾個有關係而又相似的概念，包括系統、子系統、模塊、組件、框架和架構。
系統與子系統
系統泛指由一群有關聯的個體組成，根據某種規則運作，能完成個別元件不能單獨完成的工作的群體。它的意思是“總體”“整體”或“聯盟”。
提煉維基百科定義的關鍵內容。
（1）關聯：系統是由一群有關聯的個體組成的，沒有關聯的個體堆在一起不能成為一個系統。例如，把一個發動機和一臺PC放在一起不能稱之為一個系統，把發動機、底盤、輪胎、車架組合起來才能成為一臺汽車。
（2）規則：系統內的個體需要按照指定的規則運作，而不是單個個體各自為政。規則規定了系統內個體分工和協作的方式。例如，汽車發動機負責產生動力，然後通過變速器和傳動軸，將動力輸出到車輪上，從而驅動汽車前進。
（3）能力：系統能力與個體能力有本質的差別，系統能力不是個體能力之和，而是產生了新的能力。例如，汽車能夠載重前進，而發動機、變速器、傳動軸、車輪本身都不具備這樣的能力。
子系統的定義其實和系統的定義是一樣的，只是觀察的角度有差異，一個系統可能是另外一個更大系統的子系統。
子系統也是由一群有關聯的個體所組成的系統，多半是更大系統中的一部分。
按照這個定義，系統和子系統比較容易理解。我們以微信為例（以下內容僅僅是舉例，微信不一定這麼設計）：
（1）微信本身是一個系統，包含聊天、登錄、支付、朋友圈等子系統。
（2）朋友圈這個系統又包括動態、評論、點贊等子系統。
（3）評論這個系統可能又包括防刷子系統、審核子系統、發佈子系統、存儲子系統。
（4）評論審核子系統不再包含業務意義上的子系統，而是包括各個模塊或組件，這些模塊或組件本身也是另外一個維度上的系統。例如，MySQL、Redis等是存儲系統，但不是業務子系統。
以下是網上公開的微信朋友圈的架構示意圖。
模塊與組件
模塊和組件兩個概念在實際工作中很容易混淆，我們經常能夠聽到類似如下的說法：
（1）MySQL模塊主要負責存儲數據，而Elasticsearch模塊主要負責數據搜索。
（2）我們有安全加密組件、有審核組件。
（3）App的下載模塊使用了第三方的組件。
造成這種現象的主要原因是兩者的定義並不好理解，也不能很好地進行區分。我們來看看維基百科中兩者的定義。
【模塊】
軟件模塊（Module）是一套一致且互相有緊密關聯的軟件組織，它包含程序和數據結構兩部分。現代軟件開發往往利用模塊作為合成的單位。
模塊的接口表達了由該模塊提供的功能和調用它時所需的元素。
模塊是可能分開被編寫的單位，這使得它們可再用，並允許開發人員同時協作、編寫及研究不同的模塊。
【組件】
軟件組件定義為自包含的、可編程的、可重用的、與語言無關的軟件單元，軟件組件可以很容易地被用於組裝應用程序。
相信大部分人看完這兩個定義還是一頭霧水，看完也不知道到底兩者有什麼區別。造成這種現象的根本原因是模塊和組件都是系統的組成部分，只是從不同的角度拆分系統而已。從邏輯的角度來拆分後得到的單元就是“模塊”，從物理的角度來拆分系統得到的單元就是“組件”；劃分模塊的主要目的是職責分離，劃分組件的主要目的是單元複用。“組件”的英文單詞component對應中文的“零件”一詞，“零件”更容易理解一些，“零件”是一個物理的概念，並且具備“獨立且可替換”的特點。
下面以一個最簡單的網站系統為例，假設我們要做一個學生信息管理系統，這個系統從邏輯的角度來拆分，可以分為“登錄註冊模塊”“個人信息模塊”“個人成績模塊”；從物理的角度來拆分，可以拆分為Nginx、Web服務器、MySQL。
框架與架構
框架是和架構比較相似的概念，且兩者有較強的關聯關係，所以在實際工作中，很多時候這兩個概念並不是區分得很清楚。
參考維基百科，框架的定義如下：
軟件框架（Software Framework）通常指的是為了實現某個業界標準或完成特定基本任務的軟件組件規範，也指為了實現某個軟件組件規範時，提供規範所要求之基礎功能的軟件產品。
提煉維基百科定義的關鍵部分。
（1）框架是組件規範。例如，MVC就是一種最常見的開發規範，類似的還有MVP、MVVM、J2EE等框架。
（2）框架提供基礎功能的產品。例如，Spring MVC是MVC的開發框架，除了滿足MVC的規範，Spring提供了很多基礎功能來幫助我們實現功能，包括註解（@Controller等）、Spring Security、Spring JPA等很多基礎功能。
參考維基百科，架構的定義如下（請搜索英文關鍵字Software Architecture，中文的詞條解釋很粗淺）。
Software architecture refers to the fundamental structures of a software system, the discipline of creating such structures, and the documentation of these structures.
簡單翻譯一下：軟件架構是指軟件系統的“基礎結構”，創造這些基礎結構的準則，以及對這些結構的描述。
單純從定義的角度來看，框架和架構的區別還是比較明顯的，框架關注的是“規範”，架構關注的是“結構”。框架的英文是Framework，架構的英文是Architecture。Spring MVC的英文文檔標題就是“Web MVC Framework”。
雖然如此，在實際工作中我們卻經常碰到一些似是而非的說法。例如，“我們的系統是MVC架構”，“我們需要將Android App重構為MVP架構”，“我們的系統基於SSH框架開發”，“我們是SSH的架構”，“XX系統是基於Spring MVC框架開發，標準的MVC架構”……究竟什麼說法是對的，什麼說法是錯的呢？
其實這些說法都是對的，造成這種現象的根本原因隱藏於架構的定義中，關鍵就是“基礎結構”這個概念並沒有明確說是從什麼角度來分解的。從不同的角度或維度，可以將系統劃分為不同的結構，其實我們在“模塊與組件”中的樣例已經暗含了這點，繼續以學生管理系統為例。
從業務邏輯的角度分解，“學生管理系統”的架構如下圖所示。
從物理部署的角度分解，“學生管理系統”的架構如下圖所示。
從開發規範的角度分解，“學生管理系統”可以採用標準的MVC框架來開發，因此架構又變成了MVC架構，如下圖所示。
以上這些“架構”，都是“學生管理系統”正確的架構，只是從不同的角度來分解而已，這也是IBM的RUP將軟件架構視圖分為著名的“4+1視圖”的原因。
重新定義架構
我們參考維基百科的定義，將架構重新定義為：軟件架構指軟件系統的頂層結構！
這個定義很簡單，但包含的信息很豐富，基本上把系統、子系統、模塊、組件、架構等概念都串起來了，詳細闡述如下。
首先，“系統由一群關聯個體組成”，這些“個體”可以是“子系統”“模塊”“組件”等，架構需要明確系統包含哪些“個體”。
其次，系統中的個體需要“根據某種規則”運作，架構需要明確個體運作和協作的規則。
第三，維基百科的架構定義中用到了“基礎結構”這個說法，我們改為“頂層結構”，可以更好地區分系統和子系統，避免將系統架構和子系統架構混淆導致架構層次混亂。
本文選自《從零開始學架構：照著做，你也能成為架構師》，作者李運華，電子工業出版社9月出版。
現在點擊擴展鏈接，享每滿199-100優惠。
閱讀更多 博文視點Broadview 的文章
