0 前言

在軟體研發這個領域，程式設計師的終極目標都是想成為一名合格的架構師。然而夢想很美好，但現實卻很曲折。

在實際工作中，程式設計師會分很多種，有的擅長編碼實現，有的擅長底層原理，有的擅長邏輯實現等等，在各自的領域都表現不俗、擔當核心，然而，面臨更高層架構設計時，很多優秀的程式設計師卻折戟沙場，未能完成華麗轉身。

架構的真諦是什麼呢？架構真的如此難把控嗎？難道真的只有天資聰慧、天賦異能的程式設計師才能駕馭架構嗎？

不要氣餒，平常心，其實人人都是架構師，可能你做的任一一件事已無形中用到了架構。

本篇文章將帶您慢慢走進架構，揭祕架構的真諦。正如，架構不是神祕物，吸取真諦即瞭然。

1 架構的背景

如果想要深入理解某一事物的本質，最好的方式就是去追尋這個事物出現的歷史背景和推動因素。所以我們先來梳理一下軟體開發的進化史，探索一下軟體架構出現的歷史背景。

1.1 機器語言

最早的軟體開發使用的是“機器語言”，其直接使用二進位制碼0和1來表示機器可以識別的指令和資料。

比如：為了完成“將暫存器 BX 的內容送到 AX 中”，機器語言如下：

1000100111011000
複製程式碼

面對上面的1&0的字串，不用多說，程式設計師心裡肯定會萬馬奔騰吧，更別說輸入錯誤要去定位問題，求程式設計師的心裡陰影面積？

歸納一下，機器語言的主要問題是三難：

太難寫、太難讀、太難改！

1.2 組合語言

為了解決機器語言編寫、閱讀、修改複雜的問題，組合語言應運而生。組合語言又叫“符號語言”，用助記符代替機器指令的操作碼，用地址符號（Symbol）或標號（Label），代替指令或運算元的地址。

比如：為了完成“將暫存器 BX 的內容送到 AX 中”，組合語言如下：

mov ax,bx
複製程式碼

相比機器語言來說，組合語言就清晰得多了。組合語言雖然解決了機器語言讀寫複雜的問題，但本質上還是面向機器的，因為寫組合語言需要我們精確瞭解計算機底層的知識。

面向機器的語言，帶來的問題就是：

組合語言需要針對不同 CPU 的彙編指令和結構，程式碼編寫多份。

1.3 高階語言

為了解決組合語言的問題，前輩們又設計出了一個“高階語言”。為什麼會叫“高階語言”呢？原因在於這些語言讓程式設計師不需要關注機器底層的低階結構和指令，只需要關注具體的問題和業務即可。

比如：以4+6=?這個加法為例，如果用Lisp語言，只需要簡單一行程式碼：

(+ 4 6)
複製程式碼

除此以外，通過編譯程式的處理，高階語言可以被編譯為適合不同CPU指令的機器語言。程式設計師只要寫一次程式，就可以在不同的機器上編譯執行，無須根據不同的機器指令重寫整個程式。

1.4 兩次軟體危機

1. 第一次軟體危機與結構化程式設計

   高階語言的出現，解放了程式設計師，但好景不長，隨著軟體的規模和複雜度的大大增加，軟體質量低下，質量把控難度高，專案無法如期完成，嚴重超支等現象。例如，1963 年美國的 水手一號火箭發射失敗事故，就是因為一行 FORTRAN 程式碼錯誤導致的。

   所以，為了解決上面的問題，針對性的提出瞭解決方法“軟體工程”，雖然“軟體工程”提出之後也曾被視為軟體領域的銀彈，但後來事實證明，軟體工程同樣無法根除軟體危機，只能在一定程度上緩解軟體危機。

   差不多同一時間，“結構化程式設計” 作為另外一種解決軟體危機的方案被提了出來。結構化程式設計的主要特點是拋棄 goto 語句，採取“自頂向下、逐步細化、模組化”的指導思想。

   結構化程式設計本質上還是一種程式導向的設計思想，但通過“自頂向下、逐步細化、模組化”的方法，將軟體的複雜度控制在一定範圍內，從而從整體上降低了軟體開發的複雜度。

2. 第二次軟體危機與物件導向

   結構化程式設計的風靡在一定程度上緩解了軟體危機，然而隨著硬體的快速發展，業務需求越來越複雜，以及程式設計應用領域越來越廣泛，第二次軟體危機很快就到來了。

   第二次軟體危機的根本原因還是 在於軟體生產力遠遠跟不上硬體和業務的發展。

   第一次軟體危機的根源在於 軟體的“邏輯”變得非常複雜；

   第二次軟體危機主要體現在 軟體的“擴充套件”變的非常複雜；

   結構化程式設計雖然能夠緩解軟體邏輯的複雜性，但是對於業務變化帶來的軟體擴充套件卻無能為力。軟體領域迫切希望找到新的銀彈來解決軟體危機，在這種背景下，物件導向的思想開始流行起來。

   雖然物件導向開始也被當做解決軟體危機的銀彈，在一定程度上解決了軟體“擴充套件”帶來的複雜性。但事實證明，和軟體工程、結構化程度設計一樣，物件導向也不是銀彈，而只是一種新的軟體方法而已。

1.5 軟體架構的產生

與之前的各種新方法或者新理念不同的是，“軟體架構”出現的背景並不是整個行業都面臨類似相同的問題，“軟體架構”也不是為了解決新的軟體危機而產生的，這是怎麼回事呢？

隨著軟體系統規模的增加，計算相關的演算法和資料結構不再構成主要的設計問題。當系統由許多部分組成時，整個系統的組織，也就是所說的“軟體架構”，產生了一系列新的設計問題。比如：

1. 系統規模龐大，內部耦合嚴重，開發效率低；
2. 系統耦合嚴重，牽一髮動全身，後續修改和擴充套件困難；
3. 系統邏輯複雜，容易出問題，出問題後很難排查和修復；

“軟體架構”的出現有其歷史必然性。第一次軟體危機引出了“結構化程式設計”，創造了“模組”概念；第二次軟體危機引出了“物件導向程式設計”，創造了“物件”概念；直到“軟體架構”的產生，創造了“元件”概念。

“模組”、“物件”和“元件”本質上都是對達到一定規模的軟體進行拆分，差別只是在於隨著軟體的複雜度不斷增加，拆分的粒度越來越粗，拆分的層次越來越高。

2 架構指什麼

對於技術人員來說，“架構”是一個再常見不過的詞了。當提起“架構”這個詞時，如果去深究一下：“架構”到底指什麼？大部分人也許並不一定能夠準確地回答。1000個人心中可能有1001種架構的含義。

那麼如何才能準確的理解架構呢？理解架構首先理解三個有關係而又相似的概念，包括：系統與子系統、模組與元件、框架與架構。

2.1 系統與子系統

關於“系統”的定義，我們先來看維基百科的定義：

系統泛指由一群 有關聯 的個體組成，根據某種 規則運作，能完成 個別元件不能單獨完成的工作的群體。它的意思是“總體”、“整體”或“聯盟”。

來提煉下里面的關鍵資訊：

1. 關聯：系統是由一群有關聯的個體組成的，沒有關聯的個體堆在一起不能成為一個系統，例如：把一個發動機和一臺PC放在一起不能稱之為一個系統，把發動機、底盤、輪胎、車架組合起來才能成為一臺汽車。
2. 規則：系統內的個體需要按照指定的規則運作，而不是單個個體各自為政。規則規定了系統內個體分工和協作的方式。例如：汽車發動機負責產生動力，然後通過變速器和傳動軸，將動力輸出到輪胎上，從而驅動汽車前進。
3. 能力：系統能力和個體能力有本質的差別，系統能力也不是個體能力之和，而是產生了新的能力。例如：汽車能夠載重前進，而發動機、變速器、傳動軸、車輪本身都不具備這樣的能力。

再來看下子系統的定義：

子系統也是由一群有關聯的個體所組成的系統，多半會是更大系統中的一部分。

其實子系統和系統的定義是一樣的，只是觀察的角度有差異，一個系統可能是另外一個更大系統的子系統。

按照這個定義，系統和子系統比較容易理解。以微信為例來做一個分析：

1. 微信本身是一個系統，包含聊天、登入、支付、朋友圈等子系統；
2. 朋友圈這個系統又包括動態、評論、點贊等子系統；
3. 評論這個系統可能又包括防刷子系統、稽核子系統、釋出子系統、儲存子系統等；
4. 評論稽核子系統不再包含業務意義上的子系統，而是包括各個模組或者元件，這些模組或者元件本身也是另外一個維度上的系統，例如：MySQL、Redis等儲存系統，但不是業務子系統。

2.2 模組與元件

從邏輯的角度來拆分系統，得到的單元就是“模組”；從物理的角度來拆分系統，得到的單元就是“元件”。劃分模組的主要目的是職責分離；劃分元件的主要目的是單元複用。其實，“元件”的英文“component”也可以翻譯成中文的“零件”一詞，“零件”更容易理解一些，“零件”是一個物理的概念，並且具備“獨立且可替換”的特點。

2.3 框架與架構

單純從定義的角度來看，框架關注的是“規範”，架構關注的是“結構”。框架的英文是“Framework”，架構的英文是“Architecture”。

我們經常會說，比如：“工程採用的是MVC架構”、“工程使用的是SSH框架”等。所以，第一句話是站在結構的層面來說明，第二句話是站在規範的層面來說明。

同時，如果是以不同的角度來說明結構，會得出不同的架構描述，比如：

1. 從業務邏輯的角度分解，“學生管理系統”的架構

   

2. 從物理部署的角度分解，“學生管理系統”的架構

   

3. 從開發結構的角度分解，“學生管理系統”的架構

   

2.4 重新定義架構

軟體架構指軟體系統的頂層結構。

首先，“系統是一群關聯個體組成”，這些“個體”可以是“子系統”、“模組”、“元件”等；架構需要明確系統包含哪些“個體”。

其次，系統中的個體需要“根據某種規則”運作，架構需要明確個體運作和協作的規則。

3. 架構的目標

架構其實就是為了應對軟體系統複雜度而提出的解決方案。架構關鍵思維即為判斷與取捨。

正如，在一個有約束的盒子裡去求解或接近最合適的解。這個約束的盒子可能會包含團隊經驗、成本、資源、時間、業務階段等因素摻雜在一起的綜合體，針對這個綜合體，分析出系統架構的複雜度，進行合適的判斷與取捨，從而設計出恰當的架構用在合適的軟體系統中。