架構是什麼
- 架構是定義系統的結構，行爲及其他視圖的模型
- 架構虛設是有關係統的正是描述以及呈現，以有助於瞭解系統結構和行爲的方式來組織
認識架構4+1視圖模型
在4+1視圖將系統的架構用5種視圖來表示：
場景視圖
用於描述系統的參與者和功能用例之間的關係，反應系統最終的需求和交互設計
邏輯視圖
邏輯視圖主要用來支持功能性需求，系統應該提供什麼樣的服務給用戶
開發視圖
處理視圖
又稱進程試圖。用於描述系統軟件組件之間的通信時序，數據的輸入輸出。系統之間的各個進程調用關係：性能，伸縮性，吞吐量等
物理視圖
組件化思維
最簡化思維是一種應用複雜的系統分解方式，把大的系統分解爲組件。同時也利用了面向對象中的抽象和封裝，模塊化，層次結構思想。抽象了組件對外展現的公共接口，封裝了隱藏組件內部的邏輯。
組件本身即是一種模塊化的思想。組件可以套用行成父子組件，組件上的一層子系統，也可以理解爲一個更大的組件。萬物皆實體，皆對象，皆系統。
特定模式化的系統分解
一種識別組件的方式
優秀架構的一些標準
好的架構是怎麼樣的
- 架構是否滿足了利益相關者的需求（通過對結構和行爲的設計）
- 架構是具體好的結構能夠支持持續最低成本應對變化（兩個號的結構和行爲交互）
- 可審計性
- 性能
- 安全性
- 數據
- 合法性
- 伸縮性
- 擴展性
- 可測試性
運行架構特徵
| 類型 | 定義 |
|---|---|
| 可用性 | 系統可用時間，如果是24/7,則需要使系統在發生任何故障時能夠迅速啓動和運行 |
| 持續性 | 災難恢復能力 |
| 性能 | 包括壓力測試，峯值分析，分析功能的使用頻率，所需容量和響應時間，性能報告有時需要自行演練，需要幾個月才能完成 |
| 可恢復性 | 業務持續性要求 |
| 可靠性/安全性 | 評估系統是否需要具備某些安全功能，如果發生故障是否會給公司帶來大筆資金損失 |
| 穩健性 | 在網絡連接中段，斷電或者硬件故障時，系統是否能夠處理運行中的錯誤和邊界條件 |
| 可擴展性 | 隨着用戶或請求數量的增加，系統執行和運行的能力 |
結構架構特徵
| 類型 | 定義 |
|---|---|
| 可配置性 | 能夠輕鬆的變更軟件配置 |
| 可擴展性 | 添加新的功能是多麼重要 |
| 可安裝性 | 方便在所有必要的平臺安裝 |
| 可利用性/重複使用 | 能夠重複利用通用組件 |
| 本地化 | 文字輸入，多語言支持；報表，計量單位，貨幣支持 |
| 可維護性 | 輕鬆的進行應用變更和系統維護 |
| 可移植性 | 系統是否需要在超過一個平臺上 |
| 支持性 | 應用需要什麼級別的技術支持， |
| 可升級性 | 能夠在服務器和客戶端輕鬆快速升級 |
跨領域架構特徵
| 類型 | 定義 |
|---|---|
| 可訪問性 | 讓所用用戶，包括色盲殘疾聽障人士都能訪問（iphone 有類似支持） |
| 歸檔性 | 數據是否需要在一段時間後歸檔或者刪除 |
| 認證 | 安全要求，確保用戶是那個人 |
| 權限 | 安全性要求，確保用戶只能訪問程序中的某些功能 |
| 法律要求 | 符合當地法律法規 |
| 隱私 | 個人信息數據加密存儲，不泄露，不傳播 |
| 安全性 | 隨着用戶或請求數量的增加，系統執行和運行的能力 |
最差可用架構
永遠不要爲了最好的架構努力，而要爲最差可用的架構努力。--《軟件架構指南》
架構師很少能夠設計系統並使每個架構特徵最大化，通常決策歸結爲幾個相互競爭的問題的之間的權衡。
架構風格
單體架構
1. 分層架構
2. 管道架構
3. 微核架構
分佈式架構
1. 基於SOA服務
2. 事件驅動
3. 微服務架構
