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

為什麼需要架構師

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

技術高手的視角

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

軟體企業的視角

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

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

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

架構

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

• 元件 通常是指開發或部署的一個單元，根據考查物件的大小，元件的粒度也有所區別。在做架構的時候我們需要把握好這個力度，不能陷入程式碼細節，如果過度的關注程式碼層面的力度，那對系統的整體把握可能會出問題。

• 元件與元件之間的關係 是架構要考慮的重要因素，來自系統外部的請求通常是由多個元件協作完成的，系統內部結構是否良好，很大程度上取決於元件之間的關係。

• 關鍵機制 是指影響到系統可用性、安全性、效能等重要非功能特性的一些技術方案，比如技術選型、關鍵設計、處理流程等等。

系統架構 vs 架構設計

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

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

架構設計 vs 概要設計

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

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

架構師

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

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

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

架構師的價值

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

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

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

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

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

架構師能力模型

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

• 溝通協作：
  架構師需要經常跟產品經理、專案經理甚至客戶打交道，所以溝通能力對架構師來說非常重要，能力總結如下
  ① 具備優秀的口頭、書面及表達技巧
  ② 優先的聆聽者和觀察者
  ③ 傳達和激發團隊，共享架構，確保達成一致
  ④ 個人品牌，值得信任
  ⑤ 推動良好的團隊協作，合作共贏

• 自我驅動：
  架構師為什麼能夠成為架構師？因為他們都會有強大的自我驅動力，總結如下
  ① 積極主動，承擔職責以外的事情
  ② 持之以恆，長期保持
  ③ 嚴格要求自己，不滿足現狀

• 高效學習：
  這個能力所有做開發的都需要具備
  ① 發現自身知識結構的優劣
  ② 形成自己的學習模式
  ③ 目標導向，學習目標要明確
  ④ 學習需要反覆強化，不斷實踐運用

• 良好心態：
  ① 開放心態，能夠取長補短，要多與分歧者溝通
  ② 責任心，敢於決策，為決策結果負責
  ③ 嚴於利己，寬以待人，積極向上

• 識別問題：
  公司花錢聘請你來的目的是讓你來解決問題，而解決問題的前提是先識別問題，而架構師需要快速準確的識別問題，主要分為以下幾個方面
  ① 識別問題以及問題的主體，把問題本身先搞清楚
  ② 發現問題永遠比解決問題更加重要
  ③ 可以通過利益者全面溝通、競爭對手分析等手段來識別問題
  ④ 問題的優先順序，可以用錢或者對業務的影響面來衡量

• 抽象思維：
  作為架構師這個能力尤其重要
  ① 能夠分解出共性和個性，提煉出共性
  ② 需求概念化（由實到虛總結昇華）並歸類（核心/非核心等），然後分而治之
  ③ 抽象的前提是對個性的深入理解

• 認識深度
  ① 深層次挖掘（由虛到實）問題的本質
  ② 技術的本質
  ③ 業務的本質
  ④ 利益相關者的本質

• 平衡取捨
  這個能力也非常重要，畢竟公司給你資源是有限的。如果給你無限的資源，那就不需要做架構了，架構師就是需要在有限的資源中最大化經濟效益。往往做架構設計就是一個取捨的過程。
  ① 利益者之間利益程度的的平衡取捨
  ② 確保架構在現有有限資源約束下最合理，最大化經濟效益

• 業務能力
  不瞭解業務肯定做不出良好的架構設計的，需要了解業務的現狀以及未來的發展趨勢。
  ① 對於所在業務和領域要有較深的理解
  ② 能夠對業務需求進行分解和未來判斷
  ③ 好的架構師也是好的產品經理

• 技術能力
  這是作為架構師最基本的能力
  ① 具備編碼/設計/攻關等能力，豐富專案經驗
  ② 技術深度，某一個領域的技術專家
  ③ 技術廣度，技術知識面比較廣
  ④ 技術高度，技術前瞻和判斷力，技術支撐和引導業務

• 想象力
  ① 技術創新，以業務為中心的方式識別、評估和注入顛覆性新技術的能力
  ② 戰略性規劃，能夠為實現潛在目標設計戰略路線圖並推動落地
  ③ 企業執行，企業精神、承擔逾期風險、交付成果

• 架構方法論
  ① 多學習掌握業內/公司成熟的方法論，並且實踐體會
  ② 自己結合專案迴圈總結，形成自身的架構方法論體系

架構師修煉方法

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

• 豐富實戰
  1、先在一個產品/專案做的比較深入，然後考慮多產品/專案的實踐；
  2、積極主動進行可複用模組提煉以及思路和手段的改進，減少無效重複實踐
  3、在完成本職工作的前提下，增加影響力在更大範圍實踐

• 深度思考
  1、六步思考：確定與定義問題、分析問題、尋找解決問題的方法、做出決定、採取行動、評估結果與控制
  2、總結思考，形成自己的知識經驗財富

• 融入圈子
  1、融入到部門/公司架構師的圈子，尤其是要找到自己心中的導師；
  2、融入行業相同的技術圈子，互相學習交流
  3、經常寫部落格、參與開源社群、演講以及培訓等手段

• 不斷學習
  1、系統化知識體系的學習，權威書籍/網站/微信公眾號等
  2、新技術的感知、運用、分析以及場景運用
  3、參加各種培訓、分享以及交流等，與專家講師碰撞學習

架構師成長路徑

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

• 工作三五年，精通一兩種程式語言；

• 精通幾個框架，如SSH；

• 能夠搭建專案的程式碼框架，開發核心模組，組織共通類庫，編寫示例程式；

• 能夠解決一些開發過程中的難題；

• 能夠對下級程式設計師進行指導；

• 能夠負責一些中小模組的設計；

• 知識和能力體系與其承擔什麼專案有很大相關性；

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

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

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

架構師工作指南

工作職責

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

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

• 立項階段的職責（主要是向諮詢或需求分析人員提供技術諮詢）

• • 進行總體架構設想

  • 論證技術可行性

  • 驗證某些關鍵技術問題

• 業務分析和需求分析階段的職責 協助業務分析人員產出業務分析成果，包括以下事項：

  協助需求分析人員完成需求分析，包括以下事項：

• • 對產品團隊進行技術支撐，解答產品團隊的技術疑問

  • 把握產品團隊的需求成果，確保形式和內容符合架構設計輸入需要，確保功能可實現，非功能性需求指標合理，成本和工期可接受

  • 完善需求分析

  • 與產品團隊協作完成業務分析文件

  • 參與系統業務價值討論

• 架構設計階段的職責（獨立完成架構設計）

• • 邏輯架構設計，將系統分解為非技術性的邏輯元件，並定義其間的關係

  • 物理架構設計，將邏輯架構中的元件和關係進行技術化、具體化

  • 對於沒有經驗的技術點，驗證其可行性

  • 效能驗證

  • 技術選型時對多種方案對比驗證

  • 架構評審，設計完成時邀請其他成員、組外專家、領導、高階架構師對自己的工作成果進行評審

  • 軟硬體採購申請，對設計、開發、測試、部署各環節需要的硬體及軟體編寫採購清單，提交申請

• 概要設計和詳細設計階段的職責（與開發組長一起完成概要設計）

  與開發組長一同確定詳細設計的範圍，指導中級開發人員完成必要的詳細設計

• • 初期指導，說明架構設計意圖、詳細設計注意事項

  • 設計檢查與評審，確保詳細設計符合架構設計要求

  • 參與資料庫設計，確保資料庫設計符合架構設計要求，主要考慮效能、資料量等問題

  • 參加介面設計評審

  • 功能清單整理，根據系統用例和架構設計中的元件定義推匯出功能清單

  • 介面定義，包括元件間的通訊機制定義和功能模組間的介面定義

• 開發階段的職責 指導開發人員落實架構設計中要開發元件的實現，包括以下事項：初期指導：

  程式碼檢查與評審：

• • 檢查工程結構是否合理

  • 檢查元件的版本是否合適

  • 檢查介面是否與架構設計一致

  • 檢查主要處理流程的呼叫關係

  • 檢查關鍵功能的實現

  • 檢查通訊方式

  • 檢查併發處理方式

  • 檢查連線池、執行緒池等資源的利用

  • 檢查快取的實現方式和策略

  • 檢查配置項實現方式

  • 檢查構建指令碼

  • 向開發團隊說明開發相關的架構設計意圖

  • 配合開發組長搭建開發環境，建立各元件的程式碼工程

  • 解答開發團隊的疑問

• 測試階段的職責 指導測試人員檢驗架構設計中非功能特性的實現，包括以下事項：

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

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

工作流程

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

• 制定專案的架構工作計劃

• 完善需求分析

• 進行架構設計

• 指導概要設計

• 指導詳細設計

• 指導開發

• 指導測試

• 指導上線運維

• 管理架構變更

周邊協作

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

資源保障

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

架構師的考核

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

• 考核架構工作計劃執行的完整性

• 考核架構設計文件的質量

• 考核指導、檢查和評審的效果

• 考核專案非功能性需求的滿足情況

• 考核架構師知識經驗的分享情況

• 考核架構師對公司產品的改進情況