架構師是怎樣煉成的

這是我參與更文挑戰的第25天，活動詳情查看：更文挑戰

軟件架構師定義

• 軟件工程師的職業發展方向:

• 軟件架構師:
  • 制定高級設計決策,並肯定技術標準,包括編程標準,工具和平臺的軟件專家
• 軟件架構:
  • 系統的基本組織構成,這種組織主要體如今其組件,組件之間關係,組件與環境之間的關係,以及決定系統設計與演化原則
  • 架構是系統的藍圖,描述了系統的結構和關鍵決策
  • 架構包含系統的功能和非功能性需求:
    • 系統如何實現的?
    • 系統與子系統是如何劃分的?
    • 系統之間是如何通訊的?
    • 系統功能如何設計和交互的?
    • 包含重要的架構決策,系統組成,功能設計,技術選型,成本分析等等
  • 架構的基礎是設計知足客戶需求的系統,其中包含功能性,非功能性以及質量和約束

• 架構師必定要負責整個系統中最核心和最難的地方編寫,而且設計好團隊合做開發方式,能根據編程經驗看到將來的變化
• 若是一個團隊裏須要一個架構師,必定是一位代碼能力最好的,可以負責核心業務的開發,而且不能脫離實際業務

項目中包含哪些角色:

• 客戶: 爲系統開發買單的人,關注系統的業務價值
• 用戶: 使用系統的人,關注是否知足功能需求,提高效率和易用性等
• 項目經理: 負責項目管理,組織,協調,溝通等管理工做
• 需求分析師: 負責需求相關工做,好比業務分析,需求獲取,需求調研,需求管理,編寫需求規格說明書等
• 系統架構師: 負責總體的系統分析,架構規劃,技術選型,核心功能需求和非功能性需求的架構設計
• 系統設計師: 在架構模型的基礎上,進行核心功能和非核心功能的詳細設計
• 開發人員: 根據架構設計和詳細設計完成編碼和單元測試,達到提測標準
• 測試人員: 驗證開發功能是否知足需求,好比進行功能測試,集成測試,性能測試,壓力測試,安全性測試,迴歸測試等
• 運維人員: 負責部署環境搭建,部署和平常維護

架構師職責

• 架構師須要創建高效卓越的體系,在規定的時間內完成項目
• 架構師須要:
  • 識別定義並確認需求
  • 進行系統分解造成總體架構
  • 正確地技術選型
  • 制定技術規格說明並有效推進落地
• 架構師的角色:
  • 理解並解析需求
  • 建立有用的模型
  • 確認並細化擴展模型
  • 管理架構

軟件架構層級

應用級

• 最低層級的架構
• 層級低,可是很詳細
• 這種層級的交流通常是在一個開發團隊內展開

解決方案級

• 架構的中間層
• 關注一個或多個知足業務需求的應用,即商業方案
• 這之中有些設計是高層次的,但大部分仍是低層次的設計
• 這種層級的交流開始涉及多個開發團隊

企業級架構

• 架構的最高層級
• 關注多個設計方案
• 這種架構的設計層次高且抽象,所以也須要方案級和應用級的架構師對此進行細化
• 這種層級的架構須要多個組織進行溝通

• 架構師能夠被看做是不一樣工做組之間的粘合劑:
  • 橫向: 在業務部和開發人員或者不一樣的開發團隊之間架起溝通的橋樑
  • 縱向: 在管理者和開發人員之間架起橋樑
  • 技術: 將不一樣的技術或應用整合在一塊兒

解決方案架構師

工做方式理解

• 瞭解和挖掘客戶痛點,項目定義,現有環境管理
• 梳理明確高階需求和非功能性需求
• 對客戶問題已經存在什麼解決方案
• 溝通,方案建議,屢次迭代,交付整體架構
• 架構決策

職責

• 從客戶視圖看:
  • 堅決客戶高層信心: 利用架構和解決方案能力,幫助客戶選擇相關解決方案
  • 解決客戶中層問題: 利用相關解決方案,幫助客戶解決業務問題,得到業務價值
  • 引領客戶IT員工: 技術引領,方法引領,產品引領
• 從項目視圖看:
  • 對接管理部門: 彙報技術方案,進度,技術溝通
  • 對接PM,項目PM: 協助項目計劃,人員管理等.負責全部技術交付物的指導
  • 對接業務部門和需求人員: 瞭解和挖掘痛點,幫忙梳理高級業務需求,指導需求工藝
  • 對接開發: 產品支持,技術指導,架構指導
  • 對接測試: 配合測試計劃和工藝制定.配合性能測試或者非功能性測試
  • 對接運維: 產品支持,運維支持
  • 對接配置和環境: 產品支持
  • 其他資源整合

軟件架構師職責

• 定義和肯定所需的開發技術和平臺
• 定義開發標準,如編程標準,工具,審覈流程,測試方法等
• 對肯定和理解業務需求提供技術支持
• 設計系統並根據需求做出決策
• 對架構定義,設計和決策進行討論記錄
• 檢查並審覈架構和代碼,好比檢查前期肯定的模式與編程標準是否被正確實施
• 與其餘部門和架構師合做
• 對開發人員的引導和諮詢
• 將高級設計細化,並轉化爲較低級的設計

---

• 按照系統設計實現過程:
  • 支持售前或需求階段,提供概念架構或技術諮詢
  • 系統分析,架構設計,技術選型,產出架構解決方案
  • 指導項目團隊成員,按照架構設計完成,開發,測試和發佈
  • 開發或設計開發框架,制定編碼或者編程規範,設計架構原型,驗證架構原型
  • 組織技術或架構培訓,把我技術或者架構方向
  • 實現與成本的方案平衡,干係人溝通,技術風險管理,技術領袖
• 按照項目階段:
  • 售前階段: 給予商務支持,提供系統解決方案和架構諮詢
  • 需求階段: 與需求分析師一塊兒,參與項目溝通,協助完成技術或者業務諮詢和需求模型,兼顧業務專家身份
  • 架構階段: 進行系統分析與設計,進行系統抽象,設計系統模型,進行技術原型,開發架構原型等
  • 設計階段: 指導設計人員完成詳細設計
  • 開發階段: 指導開發人員按設計實現,解決技術難題
  • 測試階段: 指導測試人員工做,特別是非功能需求測試
  • 發佈階段: 指導部署人員按照部署架構進行部署,及時解答或反饋運行期間架構問題
  • 其餘工做: 技術選型,人員培訓,技術指導

軟件架構師工做流程

• 架構的工做流程是一個系統如何從需求,架構到實現的的過程和方法
• 良好的架構:
  • 須要架構師具有技術和架構設計能力以外,還須要具備良好豐富的業務知識
  • 從軟件工程角度,架構師不只要參與系統架構和設計階段外,還要參與需求分析階段,開發,測試,發佈,試運行階段
• 需求分析主要包括需求模型,架構模型,設計模型和解決方案模型:
  • 需求模型: 參與需求分析和需求模型設計,提供技術建議或引導需求定義,提供解決方案指導
    • 主要參與者: 需求分析師,業務分析師
    • 輔助參與者: 架構師,設計師
  • 架構模型: 根據需求模型,產出架構模型
    • 選擇架構對象: 關鍵流程,核心用例和非功能需求
    • 流程建模: 梳理需求關鍵流程,分析業務對象,子系統,模塊,設計出系統的交互流程
    • 領域建模: 梳理業務流程中設計的對象,子系統模塊,劃分子系統,模塊,核心對象,通訊機制,事務模型等
    • 輸出整體架構: 根據領域模型和業務流程模型,結合組件架構,部署架構,通訊機制,輸出系統體架構方案
    • 架構驗證: 驗證架構可用性,能夠用評審或架構原型的方式,進行評審或實際測試驗證
    • 主要參與者: 架構師,架構委員會
    • 輔助參與者: 系統設計師,開發人員,測試人員
  • 設計模型: 在架構師的指導下,根據系統架構,完成各子系統,模塊,功能,接口的概要或詳細設計
    • 主要參與者: 系統設計師,高級工程師
    • 輔助參與者: 架構師
  • 解決方案模型: 架構模型,設計模型,架構原型等統一組成架構解決方案
• 一個完整的系統架構包括:
  • 總體架構
  • 子系統
  • 模塊
  • 功能概要或詳細設計
  • 通訊機制
  • 事務機制
  • 接口定義,包括內部和外部
  • 領域模型
  • 業務流程
  • 數據庫設計
  • 中間件
  • 組件架構
  • 部署架構
• 系統解決方案標準:
  • 知足功能和非功能性需求
  • 符合項目要求的規模和成本
  • 知足開發,測試和發佈要求

軟件架構師能力模型

通用能力

架構思惟

自頂向下構建架構

• 定義問題:
  • 定義問題中最重要的是定義客戶的問題
  • 定義問題,特別是識別出關鍵問題.
  • 關鍵問題是對客戶有體感,可以解決客戶痛點,經過必定的數據化來衡量識別出來,關鍵問題要優先給出解決方案
• 問題定義加入時間維度:
  • 將方案和問題定義區分開來
• 分析問題定義:
  • 須要對問題進行升層思考後再進行升維思考,從而真正抓到問題的本質,理清和挖掘清楚需求
  • 要善用第一性原理思惟進行分析思考問題
• 問題解決原則:
  • 使命: 先解決客戶的問題
  • 願景: 而後才能解決本身的問題
  • 強調的是可以爲客戶具體解決什麼問題,而後纔是咱們能變成什麼,從而怎樣去更好地服務客戶
• 善用多種方法對客戶問題進行分析:
  • 將客戶問題轉換成產品和平臺須要提供的能力
  • 好比倉儲系統WMS能夠提供哪些商業能力
• 梳理現有流程和能力模型:
  • 找到須要提高的地方,升層思考和升維思考真正明確提高的部分
• 定義指標:
  • 定義指標並可以對指標進行拆解,而後進行數學建模
• 能力訴求轉化爲技術挑戰:
  • 將能力訴求轉換爲技術人員的方案設計,須要結合自底向上的架構推導方式
• 創新:
  • 創新能夠是業務創新,也能夠是產品創新,也能夠是技術創新,也能夠是運營創新
  • 升層思考,升維思考,使用第一性原理思惟幫助本身在業務,產品,技術上發現不一樣的創新可能
  • 哲科思惟是架構師的靈魂思惟

自底向上推導應用架構

• 先根據業務流程,分解出系統時序圖,根據時序圖對模塊進行概括,從而獲得粒度更大的模塊,經過模塊的組合或者聚合構建整個系統架構
• 應用邏輯架構的推導有4個子路徑:
  • 業務概念架構: 來源於業務概念模型和業務流程
  • 系統模型: 來源於業務概念模型
  • 系統流程: 來源於業務流程
  • 非功能性的系統支撐: 來源於對性能,穩定性,成本的需求
• 最影響邏輯結構落地成物理架構的三大主要因素:
  • 效率
  • 穩定性
  • 性能
• 從邏輯架構到物理架構,必定須要先對效率,穩定性和性能作出明確的量化要求
• 自底向上依賴於演繹和概括:
  • 若是產品方案已經明確,程序員須要理解這個業務需求,並根據產品方案推導出架構,通常使用自底向上的方法.領域建模就是這種自底向上的分析方法
• 演繹: 演繹就是邏輯推導,越是底層,越須要演繹
  • 從用例到業務模型就屬於演繹
  • 從業務模型到系統模型也屬於演繹
  • 根據目前的問題,推導出須要實施某種穩定性措施也是演繹
• 概括: 概括是根據事物的某個維度來進行歸類,越是高層的,越須要歸類
  • 問題空間模塊劃分屬於概括
  • 邏輯架構也有的屬於概括
  • 根據一堆穩定性問題來概括出事前,事中,過後都須要的對應的操做,是就時間維度來進行概括

領域驅動設計架構

• 領域劃分設計步驟:
  • 對用戶需求場景進行分析,識別出業務全維度的用例
  • 分析模型魯棒圖,識別出業務場景中全部的實體對象
    • 魯棒圖:
      • 需求設計過程當中使用的一種方法-魯棒性分析
      • 經過魯棒分析法可讓設計人員更清晰,更全面地瞭解需求
      • 一般使用在需求分析後及需求設計前作軟件架構分析之用,主要注重於功能需求的設計分析工做
      • 需求規格說明書爲其輸入信息,設計模型爲其輸出信息
      • 是功能需求向設計方案過渡的第一步,重點是識別組成軟件系統的高級職責模塊,規劃模塊之間的關係
      • 魯棒圖包含三種圖形:
  • 領域劃分,將全部識別出的實體對象進行分類
  • 評估域劃分合理性,並進行優化

基於數據驅動設計架構

• 隨着loT,大數據和人工智能的發展,之前的領域驅動的方式架構每每知足不了需求或者達不到預期的效果
• 在大數據的應用場景中:
  • 從領域分析升維到基於大數據統計分析結果來進行業務架構,應用架構,數據架構和技術架構
  • 須要具有數理統計分析的基礎和BI的能力,以數據思惟來架構系統
  • 好比阿里的數據分析平臺採雲間和菜鳥的數據分析平臺FBI

專業能力

• 企業級應用的架構師: 負載均衡,集羣,分佈式,高併發,高可用,易管理等等,理論能力和動手編碼能力須要同時提升.注重設計思想和設計模式,對於前沿技術,要不懈的追求和鑽研,這樣才能在技術架構選型時作出合理的決策
  • 數據層: 重點在於集羣方案的選擇
    • 好比MySQL集羣,集羣方案不少,須要選擇符合業務的方案:好比多主,主備,讀寫分離
    • 是否還須要作高可用,是用lvs,仍是zookeeper
    • 是否須要mycat類中間件來管理數據庫或者作數據分片等等
  • 服務層:
    • 選擇Dubbo,主要用於高併發的系統,微服務讓團隊開發耦合度下降,各自關心各自模塊,以服務的方式發佈出去
    • 傳統一點使用SpringMVC+RESTful
    • 緩存的選擇,能夠用memcached,ehcache,redis
  • 應用層: 選擇適合適合團隊的框架
  • 網絡層: 瞭解F5之類
  • 部署:
    • 是否須要用Docker部署,開源Docker容器讓部署輕量化,易於擴展一個節點,對於高併發,伸縮性要求高的場景可使用,能夠實現一鍵部署
    • 是否須要負載均衡,能夠選擇硬負載F5,也能夠用軟負載nginx
    • 軟負載方案能夠是apache+tomcat,須要考慮session複製
    • 也能夠選擇lvs+haproxy,打包發佈,熟練使用maven,創建本身的maven私服,能指導項目成員使用maven發佈
  • 安全: 大多數安全問題在網絡層就解決了,但應用的安全不容忽視
    • 須要考慮SQL注入,受權認證
    • 重點的安全問題來自框架自己,儘可能解決開源框架中的應用漏洞
  • 其餘方面: 自動化測試,版本管理,大數據,人工智能

必備技能

設計

• 理論層面:
  • 瞭解基本的設計模式
  • 研究一下模式與反模式
  • 瞭解質量度量
• 實踐層面:
  • 嘗試理解不一樣的技術棧
  • 分析和理解應用模式:
    • 查看當前流行的框架
    • 在實踐中學習不少模式
    • 理解如何在框架中應用模式,爲何要這樣作
    • 深刻地研究代碼並瞭解如何實現的

決策

架構師須要制定決策,指引項目甚至整個公司的正確方向

• 分清主次:
  • 概念完整性
  • 一致性
• 優先級
• 認清本身的能力,明確本身的職責
• 評估多種選擇

簡化

• 多方位觀察解決方案
• 分而治之
• 重構

編程

• 開發副項目:
  • 大量的編程語言,框架,工具,流程和實踐
• 只嘗試須要嘗試的事情

記錄

• 架構文檔
• 代碼整潔
• 在可能的狀況下生成文檔:
  • 利用工具生成文檔: Swagger, RAML
• 儘量多記必需的東西,內容儘量少:
  • 用於理解該文件的全部必要信息都包括在內了嗎
  • 哪些信息是真正須要的,哪些是能夠省略的
• 更多地瞭解架構框架

成長方式

廣度

• 廣度: 架構師應該對所在領域的主流技術體系有一個全面清晰的認識,每一種技術不須要深刻的瞭解,但必須指導每一個技術的三個層面
  • 每種技術的由來,爲何會出現這種技術?這種技術是用來解決什麼問題的?
  • 每種技術是什麼?技術的基本組成是什麼?
  • 解決同一個問題的相同技術各自優缺點是什麼?更適合哪一種場景?只有清晰認識同一類型技術的優缺點,才能在技術選型可以使用更加合理的技術
• 廣度學習方法: 對各主流技術一一經過搜索引擎瞭解三個層面的內容

高度

• 高度: 架構師應該具有可以從紛繁雜亂的信息中創建抽象的能力
  • 業務抽象: 可以從軟件和產品的複雜需求中抽象出核心業務實體,並給業務實體創建合理的關係
  • 技術抽象: 可以對複雜的技術架構進行分層抽象,服務抽象或者微服務抽象,組件抽象,併爲各層和各層服務之間調用創建合理關係
• 高度學習方法: 深刻理解和學習面向對象,設計模式,琢磨優秀開源框架的設計原理和設計思想

深度

• 深度: 架構師對主流技術有深刻理解
  • 對主流技術的原理,運做機理有基本全面的理解
  • 至少要對一種技術有深刻的認識,是這種技術的專家,熟悉源代碼

寬度

• 寬度: 架構師要熟知當前的技術前沿和熱點,可以使用新的技術解決問題.好比微服務,大數據,雲計算,人工智能
• 寬度學習方法: 訂閱相關的技術諮詢,按期瞭解,對於和所負責工做相關的技術進一步瞭解

軟件架構師技術能力

• 軟件架構師要會解決問題: 一個系統中,若是拆解出來了不少模塊,應該部署在哪些機器上
  • 慢SQL優化
  • Memcache緩存
  • 負載均衡
  • 熱備,冷備,雙活
• 根據不一樣的應用須要,去設計不一樣的策略,同時將這些場景規範化,成爲一整個團隊都要遵循的標準:
  • 穿透DB
  • 失效策略
• 每個技術框架的選擇,都通過討論,驗證,測試,最終在全團隊裏推行:
  • Tuscany
  • Scallop
  • Hadoop
  • ActiveMQ
  • Erlang
  • hertrix
  • DevOps
• 架構師職責:
  • 須要從前到後都要懂
  • 須要制定關鍵的技術細節,須要給出最佳實踐
  • 須要瞭解業界全部流行的解決方案
  • 這些方案可不能夠拿過來,一樣適用於本身的場景
• 架構師須要精通:
  • 分佈式
  • Nginx
  • F5
  • 微服務
  • 緩存
  • 持久化
  • 消息隊列
• 架構師須要熟悉:
  • 全部技術細節裏最經常使用的解決方案,不能有遺漏,也不能過分設計
• 架構師還要肩負起修復開源軟件Bug的任務.須要看源碼,理解開源框架的思路,而後找有可能產生問題的地方,再去修復
• 架構師須要在有效的時間內,弄懂全部底層的東西,TCP/IP詳解
• 沒有不懂業務的架構師,全部的架構,都依賴於業務:
  • 全部的架構師,也必須寫業務代碼
  • 不把本身設計的東西,用在真正的項目裏,是不會理解架構設計的合理性在哪的

通用的架構框架

TOGAF

• TOGAF: The Open Group Architecture Framework
• TOGAF強調商業目標做爲架構的驅動力,並提供一個最佳實踐的儲藏庫:
  • TOGAF架構開發方法ADM
  • TOGAF架構內容框架
  • TOGAF參考模型
  • ADM架構開發方法指引和技術
  • 企業連續統一體
  • TOGAF能力框架

ADM

• ADM是一個迭代的步驟順序以發展企業範圍的架構的方法:

• 架構內容框架:

• 參考模型:

• ADM指引和技術:
  • 架構迭代階段:
  • 在不一樣的水平領域運用ADM:

• 利益相關者分類:

• 企業連續統一體:
  • 架構指導及支持解決方案:
    • 基礎
    • 通用系統
    • 行業組織特定
• 能力框架:

DODAF

• DODAF是一個控制 「EA開發,維護和決策生成」 的組織機制,是統一組織 「團隊資源,描述和控制EA活動」 的整體架構
  • DODAF涵蓋DoD的全部業務領域
  • 定義了表示,描述,集成DoD範圍內衆多架構的標準方法,確保架構可比較,評估
  • 提供了對系統族Fos和體系SoS進行理解,比較,集成和互操做共同架構的基礎,提供開發和表達架構描述的規則和指南
• DODAF的核心是8個視點和52個模型:

• 全景視點AV
  • 與全部視點相關的體系結構描述的頂層概貌
  • 提供有關體系結構描述的整體信息:
    • 體系結構描述的範圍:
      • 專業領域
      • 時間框架
    • 體系結構描述的背景:
      • 條令
      • 戰術
      • 技術
      • 程序
      • 相關目標和構想描述
      • 做戰概念CONOPS
      • 環境條件

• 能力視點CV
  • 集中反映了與總體願景相關的組織目標,這些願景在特定標準和條件下進行特定行動過程或是達成指望效果的能力,綜合使用各類手段和方式來完成一組任務
  • 爲體系結構描述中闡述的能力提供了戰略背景和相應的高層範圍,比做戰概念圖中定義的基於想定的範圍更全面
  • 這些模型是高層的,用決策者易於理解的術語來描述能力,以便溝通能力演進方面戰略構想
• 做戰視點OV
  • 集中反映了完成DoD使命的機構,任務,或執行的行動以及彼此之間必須交換的信息
  • 描述信息交換的:
    • 種類
    • 頻度
    • 性質
    • 信息交換支持哪些任務和活動
• 服務視點ScvV
  • 集中反映了爲做戰行動提供支撐的系統,服務和相互交織的功能
  • DoD流程包括做戰,業務,情報和基礎設施功能
  • SvcV功能和服務資源及要素能夠連接到OV中的體系結構數據.這些系統功能和服務資源支撐做戰行動,促進信息交換
• 系統視點SV
  • 集中反映支持做戰行動中的自動化系統,相互交聯和其他系統功能的信息
• 數信視點DIV
  • 數信視點DIV: 指數據和信息視點
  • 反映了體系結構描述中的業務信息需求和結構化的業務流程規則
  • 描述體系結構描述中與信息交換的相關信息,諸如屬性,特徵和相互關係
• 標準視點StdV
  • 用來管控系統各組成部分或要素的編排,交互和相互依賴的規則的最小集
  • 目的是確保系統能知足特定的一組操做需求
  • 提供技術系統的實施指南,以工程規範爲基礎,確立通用的積木塊,開發產品線
  • 包括:
    • 技術標準
    • 執行慣例
    • 標準選項
    • 標準規則
    • 標準規範
  • 這些標準在特定體系結構描述中能夠組成管控系統和系統或者服務要素的文件profile
• 項目視點PV
  • 集中反映了項目是如何有機地組成一個採辦項目的有序組合
  • 描述多個採辦項目之間的關聯關係,每一個採辦項目都負責交付特定系統或能力