我們一般在做架構設計的時候，會經歷過三個階段：需求分析、概要設計和詳細設計。
需求分析階段: 主要梳理所有用例（use case）和場景，並抽象出面向系統的使用者與角色，梳理出需求提供哪些功能與非功能的需求給這些使用者。
概要設計階段：根據需求分析的產物：核心需求，對整個系統進行模組劃分，並定義好模組之間的互動關係。
詳細設計階段：通過多個檢視來描述系統的架構，包括但不侷限於：邏輯系統、物理檢視、資料檢視、物理檢視
非功能的需求主要體現在高效能、高可用、可伸縮、可擴充套件、安全性等維度。
非功能指標
描述高效能
執行效率高、響應速度快、吞吐量高
可用性可伸縮性
垂直伸縮、水平伸縮
可擴充套件性
可插拔、元件重用
安全性資料安全、加密、防攻擊
魯棒性容錯性、可恢復性
非功能需求對應不同系統指標主要分為 4 部分：
應用伺服器是請求的入口，所有流量都是通過應用伺服器來**的。主要關心 qps 、rt 等指標。
容量與效能相關指標如下所示
1. 每天的請求量
2. 各界面的訪問峰值
3. 平均響應時間
4. 最大響應時間
5. 請求大小
6. 網絡卡與磁碟 i/o 負責
7. 記憶體使用情況
8. cpu 使用情況
1. 複製模型
2. 失效轉移策略
3. 容災策略
4. 歸檔策略
5. 讀寫分離策略
6. 分庫分表策略
1. 當前資料容量
2. 預估資料容量
3. 每秒讀峰值
4. 每秒寫峰值
5. 每秒事務峰值
1. 複製模型
2. 失效轉移
3. 持久策略
4. 淘汰策略
5. 執行緒模型
1. 快取內容大小
2. 快取內容數量
3. 快取內容過期時間
4. 快取資料結構
5. 每秒讀峰值
6. 每秒寫峰值
1. 複製模型
2. 失效轉移
3. 持久策略
1. 每天平均資料增量
2. 訊息儲存時間
3. 每秒讀峰值
4. 每秒寫峰值
5. 每條訊息大小
6. 平均響應時間
7. 最大響應時間
架構設計思路
1 針對請求獲取url 判斷資料請求方式，如果為ajax請求則通過ajax返回json資料，否則顯示html頁面 2 根據url判斷模組 模型 控制器 方法以及關鍵key等 3 資料報data包括data list data info data tree data custom field defi...
架構設計思路
1 首先最外層有一層閘道器層 mz gatway 在閘道器層 使用霸下等，將異常流量剝離出來 異常流量 1 爬蟲，根據ip，如果是 的話，根據協議頭 request header 也可以判斷出來 2 使用者應用層，承接入口流量 包含了登入層設計 使用使用者名稱和密碼 登入然後服務端返回session...
salesforce 架構設計 從架構設計到架構師
因為碎片化的時間多了，所以開始刷起某乎了，關注了架構相關的板塊，也順手回答了一些問題。發現有很多同道中人正在經歷著我前兩年經歷的階段，對於做架構沒有相對具象的一些理解，更沒有系統化的認識。所以把最近回答的一些內容整理一下，權當記錄，留給3年後的自己 按慣例，容許我裝x開頭 一 架構的定義 在軟體開發...