架構師之路一-架構師入門指引

• 2020 年 3 月 12 日
• 筆記

導讀：本系列文章教你怎麼樣成為一名架構師，而本篇文章則帶你先認識一下什麼是架構師，架構師的工作是什麼？

為什麼需要架構師

為什麼需要架構師或者說架構師能解決什麼樣的問題，我們不妨先從兩個不同的視角來看一下。

技術高手的視角

小張作為一名擁有3-5年開發經驗的技術高手，他經常會思考以下幾個問題： • 我已經工作好幾年了，將來如何發展？是要一直寫程式碼嗎？ • 是不是要往上走就得做管理？ • 在中國35歲之後不能再做技術了嗎？ • 繼續做技術是不是待遇上不如做管理？ • 如果繼續做技術我還要學習什麼？ • 如果改做管理我應該如何轉型？ • 我適合做技術還是做管理，還是別的什麼？

軟體企業的視角

軟體企業在的產品開發過程中也經常會思考以下幾個問題： • 為什麼我們的產品交付周期為什麼需要那麼長時間？競爭對手可能只要半年，為什麼我們需要1年？ • 為什麼我們的產品總有這樣那樣的品質問題？程式設計師在開發的時候為什麼不好好把控品質，上完線出這樣那樣的問題？ • 為什麼當初這個產品會選擇這樣的技術路線，技術選型的時候為什麼不慎重？導致現在要用另一種技術推翻重做，帶來巨大的人力成本？ • 網站的用戶越來越多，性能非常吃緊，想擴展卻很難？ • 為什麼這個產品的程式碼這麼難維護，找誰改都說不敢動？ • 究竟誰能在技術上保證我們的產品或項目取得成功？

從不同的角度出發會引發出一連串的疑惑，那麼能解決以上疑惑的角色就是系統架構師，也可以說我們需要系統架構師來解決這些問題。

架構、架構設計與架構師的相關概念

架構

架構，又名軟體架構，也稱為軟體體系結構。軟體架構就是一個系統的藍圖，是一種設計方案，將客戶的不同需求抽象成為抽象組件，並且能夠描述這些抽象組件之間的通訊和調用，及包括一些內部的關鍵機制。它有下面三個關鍵概念：

• 組件 通常是指開發或部署的一個單元，根據考查對象的大小，組件的粒度也有所區別。在做架構的時候我們需要把握好這個力度，不能陷入程式碼細節，如果過度的關注程式碼層面的力度，那對系統的整體把握可能會出問題。
• 組件與組件之間的關係 是架構要考慮的重要因素，來自系統外部的請求通常是由多個組件協作完成的，系統內部結構是否良好，很大程度上取決於組件之間的關係。
• 關鍵機制 是指影響到系統可用性、安全性、性能等重要非功能特性的一些技術方案，比如技術選型、關鍵設計、處理流程等等。

系統架構 vs 架構設計

系統架構 是指系統在運行期的實際內部結構，架構設計是對這種內部結構的書面描述。

架構設計 是以需求分析為輸入，通過架構師的分析，產出架構設計資料，用於指導後續概要設計、詳細設計、開發、測試、部署、上線運行。所以說如果架構設計做的不好或者沒做架構設計，那麼後面環節的開發測試部署可能會出各種各樣的問題。

架構設計 vs 概要設計

架構設計是以組件的視角來思考系統如何分解，並定義分解出來的組件之間的關係。概要設計是從功能模組的視角來對系統進行分解，並定義這些功能模組之間的關係。現在提的比較少，一般做完架構設計直接做詳細設計即可！

以用戶登錄為例，從架構設計的角度可能就只是一個用戶服務組件，而從概要設計的角度可能就是前端頁面、用戶介面、資料庫等一系列功能的設計。

架構師

架構師是負責系統架構的人、團隊或組織，架構師是團隊技術領導，從技術角度，承擔項目技術的成功或失敗的責任。在其領域內能夠全局把握的人，能夠給出其負責範圍內的總體設計，並能解決關鍵問題、指導其他人員落實設計。

往往後端開發出生的架構師對後台開發這一塊有很豐富的相關經驗，但是還需要對前端，APP端、測試、部署等領域也需要了解掌握，需要能做到掌控全局，這也是成為架構師需要去修鍊的地方。

註解：架構師在一個團隊中的權利很大，在技術上大家都要聽你的，但是同時你也要承擔相應的義務，一旦項目由於技術原因失敗，那你就是第一責任人

架構師的價值

李智慧老師在《大型網站技術架構 核心原理與案例分析》說過軟體架構師的最大價值不在於掌握多少先進的技術，而在於具有將一個大系統切分成N個低耦合的子模組的能力，這些子模組包含橫向的業務模組，也包含縱向的基礎技術模組。這種能力一部分源自專業的技術和經驗，還有一部分源自於架構師對業務場景的理解、對人性的把握、甚至對世界的認知。」

上面這張圖表示未經過架構設計的系統，大家想怎麼建就怎麼建，用過幾年後系統之間的關係沒人能理清楚，自然自然程式設計師不敢隨便改其中的程式碼。

而經過良好的架構設計後系統之間邏輯清晰，可以很容易進行擴展。

架構、架構師、架構設計之間的關係

下面一張圖很容易看出架構、架構師以及架構設計之間的關係

架構師能力模型

作為架構師需要擁有以下12個能力模型：

• 溝通協作： 架構師需要經常跟產品經理、項目經理甚至客戶打交道，所以溝通能力對架構師來說非常重要，能力總結如下 ① 具備優秀的口頭、書面及表達技巧 ② 優先的聆聽者和觀察者 ③ 傳達和激發團隊，共享架構，確保達成一致 ④ 個人品牌，值得信任 ⑤ 推動良好的團隊協作，合作共贏
• 自我驅動： 架構師為什麼能夠成為架構師？因為他們都會有強大的自我驅動力，總結如下 ① 積極主動，承擔職責以外的事情 ② 持之以恆，長期保持 ③ 嚴格要求自己，不滿足現狀
• 高效學習： 這個能力所有做開發的都需要具備 ① 發現自身知識結構的優劣 ② 形成自己的學習模式 ③ 目標導向，學習目標要明確 ④ 學習需要反覆強化，不斷實踐運用
• 良好心態： ① 開放心態，能夠取長補短，要多與分歧者溝通 ② 責任心，敢於決策，為決策結果負責 ③ 嚴於利己，寬以待人，積極向上
• 識別問題： 公司花錢聘請你來的目的是讓你來解決問題，而解決問題的前提是先識別問題，而架構師需要快速準確的識別問題，主要分為以下幾個方面 ① 識別問題以及問題的主體，把問題本身先搞清楚 ② 發現問題永遠比解決問題更加重要 ③ 可以通過利益者全面溝通、競爭對手分析等手段來識別問題 ④ 問題的優先順序，可以用錢或者對業務的影響面來衡量
• 抽象思維： 作為架構師這個能力尤其重要 ① 能夠分解出共性和個性，提煉出共性 ② 需求概念化（由實到虛總結升華）並歸類（核心/非核心等），然後分而治之 ③ 抽象的前提是對個性的深入理解
• 認識深度 ① 深層次挖掘（由虛到實）問題的本質 ② 技術的本質 ③ 業務的本質 ④ 利益相關者的本質
• 平衡取捨 這個能力也非常重要，畢竟公司給你資源是有限的。如果給你無限的資源，那就不需要做架構了，架構師就是需要在有限的資源中最大化經濟效益。往往做架構設計就是一個取捨的過程。 ① 利益者之間利益程度的的平衡取捨 ② 確保架構在現有有限資源約束下最合理，最大化經濟效益
• 業務能力 不了解業務肯定做不出良好的架構設計的，需要了解業務的現狀以及未來的發展趨勢。 ① 對於所在業務和領域要有較深的理解 ② 能夠對業務需求進行分解和未來判斷 ③ 好的架構師也是好的產品經理
• 技術能力 這是作為架構師最基本的能力 ① 具備編碼/設計/攻關等能力，豐富項目經驗 ② 技術深度，某一個領域的技術專家 ③ 技術廣度，技術知識面比較廣 ④ 技術高度，技術前瞻和判斷力，技術支撐和引導業務
• 想像力 ① 技術創新，以業務為中心的方式識別、評估和注入顛覆性新技術的能力 ② 戰略性規劃，能夠為實現潛在目標設計戰略路線圖並推動落地 ③ 企業執行，企業精神、承擔逾期風險、交付成果
• 架構方法論 ① 多學習掌握業內/公司成熟的方法論，並且實踐體會 ② 自己結合項目循環總結，形成自身的架構方法論體系

架構師修鍊方法

架構師可以從以下幾個角度進行自我修鍊

• 豐富實戰 1、先在一個產品/項目做的比較深入，然後考慮多產品/項目的實踐； 2、積極主動進行可復用模組提煉以及思路和手段的改進，減少無效重複實踐 3、在完成本職工作的前提下，增加影響力在更大範圍實踐
• 深度思考 1、六步思考：確定與定義問題、分析問題、尋找解決問題的方法、做出決定、採取行動、評估結果與控制 2、總結思考，形成自己的知識經驗財富
• 融入圈子 1、融入到部門/公司架構師的圈子，尤其是要找到自己心中的導師； 2、融入行業相同的技術圈子，互相學習交流 3、經常寫部落格、參與開源社區、演講以及培訓等手段
• 不斷學習 1、系統化知識體系的學習，權威書籍/網站/微信公眾號等 2、新技術的感知、運用、分析以及場景運用 3、參加各種培訓、分享以及交流等，與專家講師碰撞學習

架構師成長路徑

架構師的前身是一名中高級開發人員，他們通常會具備以下幾個特徵：

• 工作三五年，精通一兩種程式語言；
• 精通幾個框架，如SSH；
• 能夠搭建項目的程式碼框架，開發核心模組，組織共通類庫，編寫示常式序；
• 能夠解決一些開發過程中的難題；
• 能夠對下級程式設計師進行指導；
• 能夠負責一些中小模組的設計；
• 知識和能力體系與其承擔什麼項目有很大相關性；

在職業發展中他們有以下幾條路徑可走

走管理路線可以成長為項目經理、部門經理 走技術路線可以成為某方面的技術專家、架構師、CTO

成為架構師 意味著需要具備更高的能力，並承擔更大的責任。

架構師工作指南

工作職責

在標準軟體研發流程體系中，軟體研發分為構思階段、設計階段、開發測試階段，運維階段。而架構師需要參與整個開發流程的生命周期。

我們接下來看看架構師在每個階段需要幹什麼事。

• 立項階段的職責（主要是向諮詢或需求分析人員提供技術諮詢）
  • 進行總體架構設想
  • 論證技術可行性
  • 驗證某些關鍵技術問題
• 業務分析和需求分析階段的職責 協助業務分析人員產出業務分析成果，包括以下事項： 協助需求分析人員完成需求分析，包括以下事項：
  • 對產品團隊進行技術支撐，解答產品團隊的技術疑問
  • 把握產品團隊的需求成果，確保形式和內容符合架構設計輸入需要，確保功能可實現，非功能性需求指標合理，成本和工期可接受
  • 完善需求分析
  • 與產品團隊協作完成業務分析文檔
  • 參與系統業務價值討論
• 架構設計階段的職責（獨立完成架構設計）
  • 邏輯架構設計，將系統分解為非技術性的邏輯組件，並定義其間的關係
  • 物理架構設計，將邏輯架構中的組件和關係進行技術化、具體化
  • 對於沒有經驗的技術點，驗證其可行性
  • 性能驗證
  • 技術選型時對多種方案對比驗證
  • 架構評審，設計完成時邀請其他成員、組外專家、領導、高階架構師對自己的工作成果進行評審
  • 軟硬體採購申請，對設計、開發、測試、部署各環節需要的硬體及軟體編寫採購清單，提交申請
• 概要設計和詳細設計階段的職責（與開發組長一起完成概要設計） 與開發組長一同確定詳細設計的範圍，指導中級開發人員完成必要的詳細設計
  • 初期指導，說明架構設計意圖、詳細設計注意事項
  • 設計檢查與評審，確保詳細設計符合架構設計要求
  • 參與資料庫設計，確保資料庫設計符合架構設計要求，主要考慮性能、數據量等問題
  • 參加介面設計評審
  • 功能清單整理，根據系統用例和架構設計中的組件定義推導出功能清單
  • 介面定義，包括組件間的通訊機制定義和功能模組間的介面定義
• 開發階段的職責 指導開發人員落實架構設計中要開發組件的實現，包括以下事項：初期指導： 程式碼檢查與評審：
  • 檢查工程結構是否合理
  • 檢查組件的版本是否合適
  • 檢查介面是否與架構設計一致
  • 檢查主要處理流程的調用關係
  • 檢查關鍵功能的實現
  • 檢查通訊方式
  • 檢查並發處理方式
  • 檢查連接池、執行緒池等資源的利用
  • 檢查快取的實現方式和策略
  • 檢查配置項實現方式
  • 檢查構建腳本
  • 向開發團隊說明開發相關的架構設計意圖
  • 配合開發組長搭建開發環境，建立各組件的程式碼工程
  • 解答開發團隊的疑問
• 測試階段的職責 指導測試人員檢驗架構設計中非功能特性的實現，包括以下事項：

• 運維階段的職責 指導運維人員部署系統以及在後續運維過程中進行指導，包括以下事項：

• 架構師在組織中的職責 架構師是高級技術人員，在項目之外，還需要承擔一定的組織建設職責，包括以下事項：

工作流程

架構師在項目中的活動需要有一定的流程，正常過程如下：

• 制定項目的架構工作計劃
• 完善需求分析
• 進行架構設計
• 指導概要設計
• 指導詳細設計
• 指導開發
• 指導測試
• 指導上線運維
• 管理架構變更

周邊協作

架構師由於需要參與整個項目的生命周期，所以基本需要與所有相關人員進行協作，具體可參看下圖：

資源保障

架構師在工作過程中會有一些資源需求，可通過以下方式進行獲取：

架構師的考核

可以通過以下維度對架構師進行綜合考核：

• 考核架構工作計劃執行的完整性
• 考核架構設計文檔的品質
• 考核指導、檢查和評審的效果
• 考核項目非功能性需求的滿足情況
• 考核架構師知識經驗的分享情況
• 考核架構師對公司產品的改進情況