a. 系統架構概要
概述 歷史
第一次軟體危機(20世紀60年代~20世紀70年代)
解決方案：拋棄goto的結構化程式通過「自頂向下、逐步細化、模組化」的方法，將軟體的複雜度控制在一定範圍內，從而從整體上降低了軟體開發的複雜度。
第二次軟體危機與物件導向(20世紀80年代)
第一次軟體危機的根源在於軟體的「邏輯」變得非常複雜，而第二次軟體危機主要體現在軟體的「擴 展」變得非常複雜。
概念軟體架構指軟體系統的頂層結構
系統與子系統
模組與元件
模組： 從業務角度分析，功能職責
元件：從技術角度分析，功能復用
框架與架構
框架關注的是規範
架構關注的是結構
基本思想
技術：關鍵思維是邏輯和實現
技術的基礎是演算法，解決的是具體的業務問題
工程：工程的關鍵思維是判斷和取捨
工程的基礎是架構和專案管理
架構：解決的是具體的業務場景
專案管理：解決的是人員協作問題
行業解決方案：分析和解決問題的能力，制定行業標準
架構圖邏輯/業務角度
技術/物理角度
架構 4 +1 檢視
架構四元素：問題、模組、規則、系統
本質：面對複雜和變更的挑戰，在有限的資源條件下，保證業務的響應
目的：架構設計的主要目的是為了解決軟體系統複雜度帶來的問題。
系統複雜度 - 高效能
衡量指標
響應時間、tps、伺服器資源利用率等客觀指標
使用者的主觀感受（從程式設計師、業務使用者、終端使用者/客戶不同的視角，可能會得出不同的結論）
單台計算機內部為了高效能帶來的複雜度；
軟體方面
批處理多程序
多執行緒硬體方面：多cpu
smp（symmetric multi-processor，對稱多處理器結構）
numa（non-uniform memory access，非一致儲存訪問結構）
mpp（massive parallel processing，海量並行處理結構）
多台計算機集群為了高效能帶來的複雜度。
任務分配：任務分配器
任務分解：任務分解帶來的效能收益是有乙個度的，並不是任務分解越細越好，而對於架構設計來說，如何把握這個粒度就非常關鍵了。
簡單的系統更加容易做到高效能
可以針對單個任務進行擴充套件
解決方案
垂直維度
cpu：演算法優化、增加核數
記憶體：增大記憶體
磁碟io：固態硬碟
網路io：公升級頻寬
水平維度
功能分解：基於功能將系統分解為更小的子系統
多例項副本：同一元件重複部署到多台不同的伺服器
資料分割：在每台機器上都只部署一部分資料
系統複雜度 - 高可用：無中斷、無單點、冗餘機器
核心思想：**高可用的主要技術手段是服務與資料的冗餘備份與失效轉移。
衡量指標
**不可用時間=完成故障修復的時間點 - 故障發現的時間點
**年度可用時間=年度總時間 - **不可用時間
可用性型別
計算高可用
儲存高可用 - 資料一致性
**式/單點
協商式/主備
民主式：一主多從
集群高可用
服務治理
監控解決方案
架構角度
應用伺服器。可通過負載均衡裝置將多個應用伺服器構建為集群對外提供服務（前提是這些服務需要設計為無狀態，即應用伺服器不儲存業務的上下文資訊，而僅根據每次請求提交的資料進行業務邏輯的操作響應），當均衡裝置通過心跳檢測手段檢測到應用伺服器不可用時，則將其從集群中移除，並將請求切換到其他可用的應用服務上。
(2)服務層伺服器。這些伺服器被應用層通過分布式服務框架（如dubbo）訪問，分布式服務框架可在應用層客戶端程式中實現軟體負載均衡，並通過服務註冊中心提供服務的伺服器進行心跳檢測，當發現有伺服器不可用時，立即通知客戶端程式修改服務列表，同時移除響應的伺服器。
(3)資料伺服器。需要在資料寫入時進行資料同步複製，將資料寫入多台伺服器上，實現資料冗餘備份；當資料伺服器宕機時，應用程式將訪問切換到有備份資料的伺服器上。
系統複雜度 - 可擴充套件
目標伴隨業務的發展、創新，執行環境的變化，對技術也就提出了更多、更高的要求。能夠快速響應上述變化，並最大程度降低對現有系統的影響，是設計可擴充套件性好的架構的主要目的。
核心：正確**變化、完美封裝變化
在業務維度，**變化
在技術維度，封裝變化
其他手段
使用分布式服務(框架)構建可復用的業務平台。
使用分布式訊息佇列降低業務模組間的耦合性。
原則：低耦合、高內聚
其他 低成本
往往只有「創新」才能達到低成本目標
引入新技術。
開創乙個全新技術領域。
安全性型別
功能安全：比如說系統漏洞
架構安全
資料安全性
規模：規模帶來複雜度的主要原因就是「量變引起質變」
1. 功能越來越多，導致系統複雜度指數級上公升
2. 資料越來越多，系統複雜度發生質變
WF架構概要設計
最近在學習wf,好久沒有這麼長時間持續看書了,我覺得有點學習疲勞.順帶一提很奇怪,在codeplex上面沒有找到什麼以wf實現工作流的專案,於是我就面臨乙個問題 如何在實際應用中使用這個框架呢?初步構思,有這麼三種形式 1.將wf寫成靜態工具類的模式.在這種情況下,每次都需要根據活動的當前狀態來設定...
SOA架構設計概要
主要內容也是來自 stevey對amazon和google平台的長篇大論 我們理解的soa必然是通過介面的方式將資料與功能開放出來的，但要想要往平台方向發展，必須保證用且僅用服務介面的形式提供資料和服務 團隊間的程式模組的資訊通訊，都要通過這些介面 除此之外沒有其它的通訊方式。其他形式一概不允許 不...
軟體架構師之架構過程概要
軟體架構是軟體系統乙個高層次的結構體現，顯示了系統分解後元件的布局和元件之間的關係。好的架構描述應該包含架構的多個視角，元件的設計和擴充套件描述，以及為滿足功能性需求和非功能性需求的設計原則。一般說，軟體架構分為5個步驟，1.建立架構的任務並且形成架構團隊。2.建立並且文件化架構需求。3.設計架構 ...