作者 | 猿碼架構

來源 | 云時代架構

頭圖 | 下載于視覺中國

前言：

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

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

架構的真諦是什么呢？架構真的如此難把控嗎？難道真的只有天資聰慧、天賦異能的程序員才能駕馭架構嗎？

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

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

架構的背景

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

1、機器語言

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

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

1000100111011000

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

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

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

2、匯編語言

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

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

mov?ax,bx

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

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

匯編語言需要針對不同 CPU 的匯編指令和結構，代碼編寫多份。

3、高級語言

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

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

(+ 4 6)

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

4、兩次軟件危機

第一次軟件危機與結構化程序設計

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

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

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

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

第二次軟件危機與面向對象

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

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

第一次軟件危機的根源在于?軟件的“邏輯”變得非常復雜；

第二次軟件危機主要體現在?軟件的“擴展”變的非常復雜。

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

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

5、軟件架構的產生

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

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

系統規模龐大，內部耦合嚴重，開發效率低；

系統耦合嚴重，牽一發動全身，后續修改和擴展困難；

系統邏輯復雜，容易出問題，出問題后很難排查和修復；

“軟件架構”的出現有其歷史必然性。第一次軟件危機引出了“結構化編程”，創造了“模塊”概念；第二次軟件危機引出了“面向對象編程”，創造了“對象”概念；直到“軟件架構”的產生，創造了“組件”概念。

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

架構指什么

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

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

1、系統與子系統

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

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

來提煉下里面的關鍵信息：

關聯：系統是由一群有關聯的個體組成的，沒有關聯的個體堆在一起不能成為一個系統，例如：把一個發動機和一臺PC放在一起不能稱之為一個系統，把發動機、底盤、輪胎、車架組合起來才能成為一臺汽車。

規則：系統內的個體需要按照指定的規則運作，而不是單個個體各自為政。規則規定了系統內個體分工和協作的方式。例如：汽車發動機負責產生動力，然后通過變速器和傳動軸，將動力輸出到輪胎上，從而驅動汽車前進。

能力：系統能力和個體能力有本質的差別，系統能力也不是個體能力之和，而是產生了新的能力。例如：汽車能夠載重前進，而發動機、變速器、傳動軸、車輪本身都不具備這樣的能力。

再來看下子系統的定義：

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

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

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

微信本身是一個系統，包含聊天、登錄、支付、朋友圈等子系統；

朋友圈這個系統又包括動態、評論、點贊等子系統；

評論這個系統可能又包括防刷子系統、審核子系統、發布子系統、存儲子系統等；

評論審核子系統不再包含業務意義上的子系統，而是包括各個模塊或者組件，這些模塊或者組件本身也是另外一個維度上的系統，例如：MySQL、Redis等存儲系統，但不是業務子系統。

2、模塊與組件

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

3、框架與架構

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

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

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

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

“學生管理系統”的架構

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

“學生管理系統”的架構

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

“學生管理系統”的架構

4、重新定義架構

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

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

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

總結

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

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

何為“邊緣計算”？編程祖師爺尼古拉斯?威茨：算法+數據結構=程序“一學就會”的微服務架構模式除了 k8s，留給 k 和 s 中間的數字不多了！到底是誰發明了物聯網？再見 Nacos，我要玩 Service Mesh?了！點分享點收藏點點贊點在看

總結

以上是生活随笔為你收集整理的一文说透架构设计的本质的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。