架構究竟是什麼？來聽程序老兵怎麼說！

熱文索引，堅持原創不易，請小夥伴們不吝「推薦」支持：

1. 如何設計出優美的Web API？

2. 程序員必須掌握的性能調優 X Y Z

3. 程序員必須懂的架構入門課 1 2 3

4. 如何把單體式應用拆解成微服務？【上】

5. 如何把單體式應用拆解成微服務？【下】

架構師，老兵哥剛參加工做那些年業界尚未這個職位，那時候跟技術相關的崗位就是開發工程師、測試工程師和系統工程師，後來隨着軟件規模不斷增加而產生的，尤爲是在互聯網浪潮下用戶數和訪問量都是海量化的。在各類機緣巧合下，老兵哥結合我的喜愛選擇了走架構師路徑，從懵懵懂懂邊作邊學，到如今總算摸出了些門道，回顧這個過程仍是有不少經驗能夠分享的，接下來我準備把這些內容梳理後分享出來，給須要的小夥伴參考。今天咱們先來看看什麼是軟件架構？它對軟件研發來講有什麼獨特的價值？

• 1. 教科書式定義

軟件體系結構，又稱軟件架構，目前業界尚無統一的定義，常見定義以下：

在必定的設計原則基礎上，從不一樣角度對組成系統的各個部分進行搭配和安排，由造成系統的多個結構組成了架構。它包括該系統的各個組件，組件的外部可見屬性及組件之間的相互關係。組件的外部可見屬性，指其餘組件對該組件所作的假設。軟件架構，還包括符合系統完整性、經濟約束條件、審美需求和樣式，它並不只注重對內部的考慮，並且還在用戶環境和中對系統進行總體考慮，即同時注重對外部的考慮。軟件架構，輸出系統總體結構與組件的抽象描述，一系列關聯的抽象模式，一個系統的草圖，用於指導大型軟件系統構建的各個方面設計。

通常而言，軟件架構是一個軟件系統從總體到部分的最高層次的劃分。一般，一個系統是由元件組成的，而這些元件如何造成、相互之間如何發生做用，則是關於這個系統自己結構的重要信息，主要包括：

• 架構組件（Architecture Component）：組成系統的核心元素。
• 聯結器（Connector）：描述組件之間通信的路徑、機制和預期結果。
• 任務流（Task-flow）：描述系統如何使用這些組件和聯結器完成某一項需求。

軟件架構，是構建系統時所作出的最高層次的決定，以後很難被更改，這個決定不僅僅是技術維度的，還包括商業維度的。在建造一個系統以前，許多重要決定須要事先做出，而一旦系統開始詳細設計甚至進行建造，那這些決定就很難被更改，甚至沒法被更改。顯然，這樣的決定一定是有關係統設計成敗的最重要決定，必須通過很是慎重的研究和考察。

• 2. 大神們怎麼說

上述教科書式的定義是很是專業、抽象和完整的，但對於缺少架構工做經驗的人來講，這類風格的定義是難以理解吸取的，讀仍是能夠讀懂，可是無感。接下來，咱們先聽一聽行業內的大神是怎麼定義軟件架構的。Mary Shaw、David Garlan，經典書籍《軟件體系結構》的做者，曾給出相對簡化的定義：

軟件體系結構 = { 構件（Component），鏈接件（Connector），約束（Constrain）}。

軟件體系結構，以構件、構件之間的關係、構件與環境之間的關係爲內容的某一系統的基本組織結構，以及指導上述內容設計與演化的原理。在軟件設計過程當中，它是超越算法和數據結構設計的一個層次。體系結構問題包括各個方面的組織和全局控制結構，通訊協議，同步機制，數據存儲，給設計元素分配特定功能，設計元素的組織、規模和性能，在各設計方案之間進行選擇等。

• 3. 接地氣的闡述

最近這些年，老兵哥我常常要給應屆生同事培訓應用架構，起初我就採用教科書上的定義，再附上大神的闡述，心想新同事們應該可以理解。但後來有機會給非計算機專業的學員介紹架構師相關工做職責時，我才發現人家沒法理解這麼專業抽象的答案，畢竟人家沒有專業背景，也不曾作過相關工做。雖然上述定義都很好，但若是學員們沒法體會理解並使用它的話，再正確也毫無心義。基於這層考慮，我開始採用學員們有親身體驗的案例來作類比。

計算機軟件，是構成虛擬世界的基本元素。它的歷史開始於二十世紀五十年代，很是短暫，而構成物理世界的建築從石器時代就開始出現了，人類在幾千年的建築實踐中積累了豐富的經驗和教訓。若是將軟件比做虛擬世界的建築，而軟件架構就是建築的主體框架。建造土坯房不須要複雜的框架，就是在地基上不斷壘土，一樣小型軟件也不須要太過複雜的架構，面向過程、面向對象等就能知足須要了。但建造高樓大廈、小區樓盤等現代建築就離不開復雜的框架，不然就建造不出來，即便建造出來了，但會存在坍塌的危險，大規模軟件也依賴複雜的架構，不然沒法化解其複雜度，沒法持續更新升級、運維等。從這個角度看，架構師就至關於建築設計師，這是須要創新創造的工做。

像構件、鏈接件和約束等軟件架構概念，它們在建築這個領域也可以找到對應，例如：建築中的構件就是磚塊、水泥立柱、預製板等，鏈接件就是連通每一個樓層的樓道、樓梯和電梯等，而約束就是根據所在地域位置的天然和社會條件來肯定建築設計內容，可見咱們人類建造虛擬世界的經驗主要源自改造物理世界的過程。

• 4. 高大上的闡述

程序員是最喜歡自黑的一羣人，咱們經常用「碼農」、「搬磚」來標榜本身，上面這種接地氣的架構定義特別適合自黑的咱們，從「搬磚」、「砌牆」的建築工人轉型升級至設計師，這應該也算比較天然、優化的選擇。對程序員新人來講，上述闡述是比較形象易懂的，可是若是面向其餘行業領域的人去解釋，有沒有更加高大上的闡述呢？老兵哥我常常要到外面作些職業發展類的培訓授課，不論是學員仍是合做夥伴都是非技術人員，爲了讓他們也可以理解個人本職工做職責，我常常用組織架構來類比軟件架構。咱們知道，組織架構是人力資源管理的重要工具，對於初創小企業來講，組織架構應該是簡單實用的，但對於中大規模的企業來講，組織架構必須可以解決上規模員工的管理。

首先，人力資源可以爲組織架構選擇招聘合適的人才，並可以識別每一個人才的優劣勢，而後將其安排到能夠發揮其特長的崗位，最後讓其在具體的業務項目當中創造價值，這是否是有點像古代戰場上的選人用人、調兵遣將？那麼軟件架構跟組織架構是相似的，不一樣是組織架構是用於人的，而軟件架構是用於軟件系統的。架構師要了解熟悉各類主流的技術棧、中間件產品等，知道它們身上的優劣勢，並在系統設計中引用它們來解決特定問題，讓每一個構件都可以發揮出最大的效用，最後經過優點互補、緊密協做來化解業務的各類挑戰。這種闡述是否更高大上？俗話說學而優則仕，若是咱們可以把架構工做作好作到極致，那麼等之後你晉升至管理層，這套方法論也是通用的。

看山是山，看山不是山，看山仍是山，好像這也是咱們學習技術的三重境界，穿越這三重境界離不開對軟件架構這個領域作深刻專業的學習和實踐，這也是老兵哥正在努力作的。今天暫時先分享到這裏，接下來咱們還要繼續剖析軟件架構，看看架構是怎樣演進變化的，都通過了哪幾代迭代，每種類型的架構都有什麼優缺點。

若是你以爲有價值，麻煩動動手指點下文 「 推薦 」按鈕，讓更多小夥伴能夠看到，我也會更加有動力堅持分享。另外，老兵哥我後續還會分享職業規劃、應聘面試、技能提高、影響力打造等經驗，歡迎 關注 本專欄或歪信公主號 「 IT老兵哥 」！

關注「 IT老兵哥 」，賦能程序人生！

• 軟技能-熱門文章：（首發於公衆號）

1. 「花式」裁人套路深，你知道嗎？
2. 遭遇裁人，如何渡過心理危機？
3. 如何在寒冬中找到好工做？
4. 2C 仍是 2B，跟找工做有什麼關係？
5. 大公司 vs 小公司，你會選哪一個？
6. 記住這一點，不怕找不到好工做！
7. 跳槽，跳仍是不跳，該怎麼跳？
8. 程序員「求包養」攻略揭祕
9. 很努力了，爲何我還在原地踏步？
10. 從程序員到架構師，有捷徑嗎？

 

• 硬技能-熱門文章：

1. 圖解 Spring：HTTP 請求的處理流程與機制【1】
2. 圖解 Spring：HTTP 請求的處理流程與機制【2】
3. 圖解 Spring：HTTP 請求的處理流程與機制【3】
4. 圖解 Spring：HTTP 請求的處理流程與機制【4】
5. 圖解 Spring：HTTP 請求的處理流程與機制【5】
6. 如何正確使用 Spring Cloud？【上】
7. 如何正確使用 Spring Cloud？【中】
8. 如何正確使用 Spring Cloud？【下】
9. Spring 核心技術與產品理念剖析【上】
10. Spring 核心技術與產品理念剖析【下】