1. 架構師要會什麼



讓工程師專注更少的事情有助於提高軟體開發的質量

需要知道什麼

1. Saas 後台設計，分佈式設計

2. 設計難點，主導核心組件設計

3. 定位系統瓶頸，提高系統性能/穩定性，業務擴展性

4. 跨部門合作

5. 負載均衡，故障處理，系統監控

6. 資料庫設計，大數據相關技術

問題

1. 什麼是軟件架構

2. 如何寫一個架構設計文檔，文檔中要包含哪些功能

3. 子類 override 父類後，想要修改拋出的異常，那麼子類方法拋出的異常類應該是父類方法拋出異常類的子類還是父類

4. 掏寶這樣的大規模分佈式互連網應用系統使用了哪些技術方案和手段，主要解決什麼問題

5. 什麼是 CAP 原理，請描述某個你熟悉的 NoSQL 產品是如何解決 CAP 問題的

6. 如何做性能測試，性能測試的流程是什麼？性能測試的主要指標有哪些？

主要職責

1. 編寫架構設計文檔

2. 開發編成框架

3. 重構軟件代碼

4. 設計系統架構

5. 進行技術選型，解決技術應用中的問題

6. 優化系統性能

7. 模塊分解為服務架構重構

8. 保證系統安全高可用

9. 大數據應用

10. 技術創新

11. 溝通管理

架構師主要能力

1. 編程

2. 基礎技術掌握

3. 常用技術產品的理解與應用

4. 性能優化與分析故障

5. 常用架構模式和框架的理解與應用

6. 建模及設計文檔的方法

7. 業務理解及功能模塊及非功能模塊拆解

8. 快速學習

9. 溝通領導



軟件架構

有關軟體結構與組件的抽象描述，用於指導大型軟件系統各方面的設計

2. 4+1 視圖模型

1. Logical View： 設計的對象模型

2. Process View： 捕捉設計的開發和同步特徵

3. Physical View：描述軟件到硬件的映射，反應佈署特性

4. Development View：描述在開發環境中軟件的靜態組織結構

5. Scenario：描述應用場景



Logic View:

• 相關方：客戶、用戶、開發組織管理者

• 視角：系統的功能元素，以及他們的接口，職責，交互

• 主要元素：系統、子系統、功能模塊、子功能模塊、接口

• 用途：開發組織劃分，成本、進度的評估



Development View：

• 相關方：開發相關人員、測試人員

• 視角：系統如何開發實現

• 主要元素：描述系統的層，分區，包，框架，系統通用服務，業務通用服務，類和接口，系統平台和相關基礎框架

• 用途：指導開發組織設計和開發實現



Physical View：

• 相關方：系統集成商、系統維運人員

• 視角：系統邏輯組件到物理節點部署和節點之間的物理網路配置

• 主要元素：物理節點以及節點間的通信



Process View:

• 相關方：性能優化、開發相關人員

• 視角：系統運行時的 process, thread 

• 主要元素：process, thread, queue



Scenario:

• 相關方：用戶、開發、設計人員

• 視角：概括架構上最重要的場景（最典型或者是最有風險）及其非功能性需求，通過這些場景的實現，闡明了架構的廣度或眾多架構元素運行的方式



3. 如何使用 UML 進行軟件架構設計

什麼是模型？

• 模型是一個系統的完整抽象。人們對於某個領域特定問題的求解及解決方案，對他們的理解和認識都蘊含在模型中

• 通常，開發一個計算機系統是為了解決某個領域特定的問題，問題求解的過程中，就是從領域問題的計算機系統的映射



為什麼建造模型？

• 傳統模型

• 為了證明某件事情能工作

• 軟件模型

• 為了與人溝通



何時畫圖？

• 討論、交流時

• 最終設計文檔

• 只保留最少量、最重要的圖



UML

• Unified Modeling Language

• 以圖型方式描述軟件的概念



UML可用來描述

• 某個問題領域

• 構思中的軟件設計

• 描述已經完成的軟件實現



靜態圖：

通過描述類、對象和數據結構以及他們之間存在的關係，來描述軟件要素中不變的邏輯結構

• 靜態模型

• Use Case Diagrams

• 實現模型

• Component Diagrams：顯示代碼本身的邏輯結構、它描述系統中存在的軟構件以及他們之間的依賴關係



動態圖：動態模型

通過描繪執行流程或者實體狀態變化的方式，來展現軟件實體在執行過程中的變化過程

1. Collaboration Diagrams：用來描述相互合作的對象間的交互關係，它描述的交互關係是對象間的消息連接關係 (synchronous, asynchronous)

2. Sequence Diagrams：是一種交互圖，主要描述對象之間的動態合作關係以及合作程序中的行為次序，常用來描述一個用例的行為，著重在對象間消息傳遞的時間順序

3. Activity Diagrams：著重描述操作實現中完成的工作以及用例實例或對象中的活動

4. State Diagrams： 用來描述對象、子系統、系統的生命週期



Actor:

1. 誰是使用系統的主要功能者

2. 誰需要從系統獲得對日常工作的支持和服務

3. 誰需要維護管理系統的日常運行

4. 系統需要控制哪些硬件設備

5. 系統需要與哪些系統交互

6. 誰需要使用系統產生的結果



Ex: 項目與資源管理系統的 use case diagram

• 系統的執行者

• 項目管理員、資源管理員、系統管理員

• 確定用例

• 項目管理、資源管理、系統管理

• 對用例進行分解，畫出下層的 use case

• 對上層的用例進行分解，並將執行者分配到各層次的 use case



沒有設計文檔，就沒有軟件設計

沒有軟件設計，就沒有設計進步

4. 架構設計文檔模版

不同階段的 UML 模型，放在文檔中

• 設計概述

• 簡單描述業務場景要解決的核心問題領域

• 具體設計

• Deployment Diagram

5. 同學分享（用好 UML 的一些启发）

怎样的用例才算「有价值」

“有一种系统开发方法，让开发组织能够理解业务的目标，同时又不会麻烦业务人员，用例图提供了这种能力。”

在识别系统用例时

1. 应满足一类需求，而非具体个例

2. 应使用领域术语

3. 应是系统职责范围内能提供的功能

4. 应是「完整」的活动流程、体现系统价值，而非不完整的步骤

5. 应体现独立价值

6. 「你们先玩，我去 xxxx 就回来」