【淺談架構14/100】架構的緣起與目標

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. 架構的目標

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

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

做者：猿碼道 連接：https://juejin.im/post/5b3b425ef265da0f98312f14 來源：掘金 著做權歸做者全部。商業轉載請聯繫做者得到受權，非商業轉載請註明出處。