架構師，老兵哥剛參加工作那些年業界還沒有這個職位，那時候跟技術相關的崗位就是開發工程師、測試工程師和系統工程師，後來隨著軟體規模不斷增長而產生的，尤其是在互聯網浪潮下用戶數和訪問量都是海量化的。在各種機緣巧合下，老兵哥結合個人喜好選擇了走架構師路徑，從懵懵懂懂邊做邊學，到現在總算摸出了些門道，回顧這... ...
熱文索引，堅持原創不易，請小伙伴們不吝「推薦」支持：
架構師，老兵哥剛參加工作那些年業界還沒有這個職位，那時候跟技術相關的崗位就是開發工程師、測試工程師和系統工程師，後來隨著軟體規模不斷增長而產生的，尤其是在互聯網浪潮下用戶數和訪問量都是海量化的。在各種機緣巧合下，老兵哥結合個人喜好選擇了走架構師路徑，從懵懵懂懂邊做邊學，到現在總算摸出了些門道，回顧這個過程還是有很多經驗可以分享的，接下來我準備把這些內容梳理後分享出來，給需要的小伙伴參考。今天我們先來看看什麼是軟體架構？它對軟體研發來說有什麼獨特的價值？
- 1. 教科書式定義
軟體體繫結構，又稱軟體架構，目前業界尚無統一的定義，常見定義如下：
在一定的設計原則基礎上，從不同角度對組成系統的各個部分進行搭配和安排，由形成系統的多個結構組成了架構。它包括該系統的各個組件，組件的外部可見屬性及組件之間的相互關係。組件的外部可見屬性，指其他組件對該組件所做的假設。軟體架構，還包括符合系統完整性、經濟約束條件、審美需求和樣式，它並不僅註重對內部的考慮，而且還在用戶環境和中對系統進行整體考慮，即同時註重對外部的考慮。軟體架構，輸出系統整體結構與組件的抽象描述，一系列關聯的抽象模式，一個系統的草圖，用於指導大型軟體系統構建的各個方面設計。
一般而言，軟體架構是一個軟體系統從整體到部分的最高層次的劃分。通常，一個系統是由元件組成的，而這些元件如何形成、相互之間如何發生作用，則是關於這個系統本身結構的重要信息，主要包括：
- 架構組件（Architecture Component）：組成系統的核心元素。
- 聯結器（Connector）：描述組件之間通訊的路徑、機制和預期結果。
- 任務流（Task-flow）：描述系統如何使用這些組件和聯結器完成某一項需求。
軟體架構，是構建系統時所做出的最高層次的決定，之後很難被更改，這個決定不單單是技術維度的，還包括商業維度的。在建造一個系統之前，許多重要決定需要事先作出，而一旦系統開始詳細設計甚至進行建造，那這些決定就很難被更改，甚至無法被更改。顯然，這樣的決定必定是有關係統設計成敗的最重要決定，必須經過非常慎重的研究和考察。
- 2. 大神們怎麼說
上述教科書式的定義是非常專業、抽象和完整的，但對於缺乏架構工作經驗的人來說，這類風格的定義是難以理解吸收的，讀還是可以讀懂，但是無感。接下來，我們先聽一聽行業內的大神是怎麼定義軟體架構的。Mary Shaw、David Garlan，經典書籍《軟體體繫結構》的作者，曾給出相對簡化的定義：
軟體體繫結構 = { 構件（Component），連接件（Connector），約束（Constrain）}。
軟體體繫結構，以構件、構件之間的關係、構件與環境之間的關係為內容的某一系統的基本組織結構，以及指導上述內容設計與演化的原理。在軟體設計過程中，它是超越演算法和數據結構設計的一個層次。體繫結構問題包括各個方面的組織和全局控制結構，通信協議，同步機制，數據存儲，給設計元素分配特定功能，設計元素的組織、規模和性能，在各設計方案之間進行選擇等。
- 3. 接地氣的闡述
最近這些年，老兵哥我經常要給應屆生同事培訓應用架構，起初我就採用教科書上的定義，再附上大神的闡述，心想新同事們應該能夠理解。但後來有機會給非電腦專業的學員介紹架構師相關工作職責時，我才發現人家無法理解這麼專業抽象的答案，畢竟人家沒有專業背景，也未曾做過相關工作。雖然上述定義都很好，但如果學員們無法體會理解並使用它的話，再正確也毫無意義。基於這層考慮，我開始採用學員們有親身體驗的案例來做類比。
電腦軟體，是構成虛擬世界的基本元素。它的歷史開始於二十世紀五十年代，非常短暫，而構成物理世界的建築從石器時代就開始出現了，人類在幾千年的建築實踐中積累了豐富的經驗和教訓。如果將軟體比作虛擬世界的建築，而軟體架構就是建築的主體框架。建造土坯房不需要複雜的框架，就是在地基上不斷壘土，同樣小型軟體也不需要太過複雜的架構，面向過程、面向對象等就能滿足需要了。但建造高樓大廈、小區樓盤等現代建築就離不開複雜的框架，否則就建造不出來，即使建造出來了，但會存在坍塌的危險，大規模軟體也依賴複雜的架構，否則無法化解其複雜度，無法持續更新升級、運維等。從這個角度看，架構師就相當於建築設計師，這是需要創新創造的工作。
像構件、連接件和約束等軟體架構概念，它們在建築這個領域也能夠找到對應，例如：建築中的構件就是磚塊、水泥立柱、預製板等，連接件就是連通每個樓層的樓道、樓梯和電梯等，而約束就是根據所在地域位置的自然和社會條件來確定建築設計內容，可見我們人類建造虛擬世界的經驗主要源自改造物理世界的過程。
- 4. 高大上的闡述
程式員是最喜歡自黑的一群人，我們常常用“碼農”、“搬磚”來標榜自己，上面這種接地氣的架構定義特別適合自黑的我們，從“搬磚”、“砌牆”的建築工人轉型升級至設計師，這應該也算比較自然、優化的選擇。對程式員新人來說，上述闡述是比較形象易懂的，但是如果面向其他行業領域的人去解釋，有沒有更加高大上的闡述呢？老兵哥我經常要到外面做些職業發展類的培訓授課，不管是學員還是合作伙伴都是非技術人員，為了讓他們也能夠理解我的本職工作職責，我經常用組織架構來類比軟體架構。我們知道，組織架構是人力資源管理的重要工具，對於初創小企業來說，組織架構應該是簡單實用的，但對於中大規模的企業來說，組織架構必須能夠解決上規模員工的管理。
首先，人力資源能夠為組織架構選擇招聘合適的人才，並能夠識別每個人才的優劣勢，然後將其安排到可以發揮其特長的崗位，最後讓其在具體的業務項目當中創造價值，這是不是有點像古代戰場上的選人用人、調兵遣將？那麼軟體架構跟組織架構是類似的，不同是組織架構是用於人的，而軟體架構是用於軟體系統的。架構師要瞭解熟悉各種主流的技術棧、中間件產品等，知道它們身上的優劣勢，併在系統設計中引用它們來解決特定問題，讓每個構件都能夠發揮出最大的效用，最後通過優勢互補、緊密協作來化解業務的各種挑戰。這種闡述是否更高大上？俗話說學而優則仕，如果我們能夠把架構工作做好做到極致，那麼等以後你晉升至管理層，這套方法論也是通用的。
看山是山，看山不是山，看山還是山，好像這也是我們學習技術的三重境界，穿越這三重境界離不開對軟體架構這個領域做深入專業的學習和實踐，這也是老兵哥正在努力做的。今天暫時先分享到這裡，接下來我們還要繼續剖析軟體架構，看看架構是怎樣演進變化的，都經過了哪幾代迭代，每種類型的架構都有什麼優缺點。
如果你覺得有價值，麻煩動動手指點下文 「 推薦 」按鈕，讓更多小伙伴可以看到，我也會更加有動力堅持分享。另外，老兵哥我後續還會分享職業規劃、應聘面試、技能提升、影響力打造等經驗，歡迎 關註 本專欄或歪信公主號 「 IT老兵哥 」！
關註「 IT老兵哥 」，賦能程式人生！
- 軟技能-熱門文章：（首發於公眾號）
- “花式”裁員套路深，你知道嗎？
- 遭遇裁員，如何渡過心理危機？
- 如何在寒冬中找到好工作？
- 2C 還是 2B，跟找工作有什麼關係？
- 大公司 vs 小公司，你會選哪個？
- 記住這一點，不怕找不到好工作！
- 跳槽，跳還是不跳，該怎麼跳？
- 程式員“求包養”攻略揭秘
- 很努力了，為什麼我還在原地踏步？
- 從程式員到架構師，有捷徑嗎？
- 硬技能-熱門文章：
- 圖解 Spring：HTTP 請求的處理流程與機制【1】
- 圖解 Spring：HTTP 請求的處理流程與機制【2】
- 圖解 Spring：HTTP 請求的處理流程與機制【3】
- 圖解 Spring：HTTP 請求的處理流程與機制【4】
- 圖解 Spring：HTTP 請求的處理流程與機制【5】
- 如何正確使用 Spring Cloud？【上】
- 如何正確使用 Spring Cloud？【中】
- 如何正確使用 Spring Cloud？【下】
- Spring 核心技術與產品理念剖析【上】
- Spring 核心技術與產品理念剖析【下】
