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