系統架構
系統架構圖是為了抽象的表示軟件系統的整體輪廓和各個組件之間的相互關系和約束邊界，以及軟件系統的物理部署和軟件系統的演進方向的整體視圖。好的架構圖可以讓干系人理解、遵循架構決策，就需要把架構信息傳遞出去。那么，畫架構圖是為了：解決溝通障礙/達成共識/減少歧義。比較流行的是4+1視圖和C4視圖。
1 怎么畫好架構圖
一個好的架構圖是不需要解釋的，它應該是自描述的，并且要具備一致性和足夠的準確性，前瞻性，能夠與 后面的設計相呼應。
2 架構方案的受眾分析
架構方案，也要 千人千面，在畫出一個好的架構圖之前， 首先應該要明確其受眾，再想清楚要給他們傳遞什么信息 ，一個方案，面向不同的受眾，需要有不同的視圖，不是為了畫圖而畫圖，而是應該差異化分析
要進行受眾分析，應該根據受眾的不同，傳遞的信息的不同，用圖準確地表達出來，最后的圖可能就是在這樣一些分類里。
3 視圖的分析維度
針對不同的受眾，有不同的分析圖，但是，也是層層深入的；
大概有下面的 8個維度
3.1 場景視圖
用于描述系統的參與者與功能用例間的關系，反映系統的最終需求和交互設計，通常由用例圖表示；
場景分析圖的受眾：外部的技術或非技術人員，包括團隊內部或外部的開發人員或運維人員
3.2 系統架構分析
用于描述系統軟件功能拆解后的組件關系，組件約束和邊界，反映系統整體組成與系統如何構建的過程，通常 子系統的 線框圖表示。
3.3 系統依賴分析
用于描述要我們要構建的系統是什么，子系統直接的依賴關系是什么，用戶是誰，需要如何融入已有的IT環境。
系統依賴分析圖的受眾：外部的技術或非技術人員，包括團隊內部或外部的開發人員或運維人員
3.4 子系統依賴分析
子系統依賴 是 系統依賴圖里 ，對待建設的子系統做了一個內部依賴關系展開分析，
子系統依賴分析 主要用來描述子軟件系統的內部的依賴關系，分析系統中的職責是如何分布的，子系統是如何交互的。
子系統依賴分析的受眾：外部的技術或非技術人員，包括團隊內部或外部的開發人員或運維人員
3.5 組件架構圖
組件架構圖是把針對某個子系統 進行組件設計、模塊設計，組件架構圖 用于 子系統 的模塊關系，介紹 子系統由哪些組件/服務組成，了組件之間的關系和依賴，為軟件開發如何分解交付提供了框架。
組件架構圖受眾：主要是給內部開發人員看的。
組件架構圖的作用：為代碼的組織和模塊架構，提供支撐
3.6 模塊架構圖
從編碼的維度來說，組件內部，很多模塊。
模塊架構分析 ，是對組件的進一步 深入分析。
模塊架構分析用于描述模塊劃分和組成,
模塊架構分析可以細化到內部包的組成設計，服務于開發人員，反映系統開發實施過程。
3.7 邏輯架構視圖
用于描述系統模塊內部的的通信時序,數據的輸入輸出,反映系統的功能流程與數據流程,、
通常由時序圖和流程圖表示。
3.8 部署架構分析
用于描述系統軟件到物理硬件的映射關系,反映出系統的組件是如何部署到一組可計算機器節點上，用于指導軟件系統的部署實施過程。
對于程序員來說，最常用的是這三種架構圖，
3.2 系統架構分析：通常用于整體描述系統所包含的組件
3.5 組件架構圖：通常用于模塊設計
3.7 邏輯架構視圖 ：通常用于開發小組內部討論具體的復雜的開發流程；
4 案例
上面根據不同的受眾劃分了8中類型的架構圖，但是實際應用中，不需要那么死板，架構說到底是為了達成交流共識的實現方案演示，并不一定非得拘泥于某種形式，只要你能畫的清楚，講的明白就最合適不過了。
以下是三個案例
案例1：架構選型圖
作用：通常在新項目開發初期，都要做一些技術選型工作。在負載、網關、架構、治理、框架、服務、數據以及環境和支撐服務上，要選擇適合當前開發的技術。
案例2：微服務架構
作用：技術選型完畢后，接下來就是對于這些技術的運用。這個過程有點像搭積木一樣，把每一個區域用適合此位置的積木填充進去。如果是團隊初建或者是技術升級，那么這個過程還是比較復雜的，需要大量的驗證。不過其實互聯網的技術分層和使用已經相對穩定，搭建一個這樣的微服務并不會耗費太長的時間。
案例3：技術架構圖
作用：技術架構圖主要是對于研發層面做技術實現指導的，它可以把系統分層和實現結構劃分清楚。另外一般也會把案例工程的結構拿出來一起講解，這樣可以讓團隊伙伴快速的進入開發。
技術方案
光有圖是不夠的，還要有方案
不管我們是做業務開發，還是做基礎建設，雖然產品訴求千差萬別，但是我們必然需要做好方案設計，然后還需要進行方案設計評審。
1 精簡版-技術方案設計模板
精簡版的模板如下，一般的方案設計，大家都可以參考這個提綱來寫：
2 詳細版-技術方案設計模板
相對詳細和復雜的版本如下：
3 現狀
現狀，主要是用來描述當前這個業務(項目)的一些基本情況介紹和相關的背景。你的方案設計出來之后，是需要給你的 leader 或者團隊其他成員進行評審或者查看，甚至是要給更高級別的人來評審。但是別人不可能都和你一樣清楚你的項目，因此首先，你要把你項目的基本情況和背景都說清楚，讓大家達成一個共識，站在同一個起點上，才能進行后面的方案評審和討論。
3.1 業務背景
業務背景就是你這個業務（項目）的基本介紹，包括但不限于：
- 項目名稱
- 業務描述
3.2 技術背景
技術背景就是你這個業務是基于什么樣的技術背景下來構建的，我們的技術方案可能是從 0 到 1 來構建，也能是基于現有的方案來優化，但是不管是什么場景，一定都會存在相關的技術背景，因此包括但不限于：
- 現有技術積淀
- 現有架構描述
- 現有系統的整體容量
4 需求
需求，很重要！技術人員千萬不要忽略需求，因為不管你的技術有多牛逼，都一定為需求服務的，不管這個需求是技術需求，還是業務需求，一定都是要為需求服務。而需求，就是你這個技術方案的起點，技術方案一切都是圍繞需求來設計，當然，這個需求可以是當下的需求，也可以包含未來潛在的需求。
只有把需求介紹清楚之后，大家才能知道你方案設計里面的所有設計和對應的折中點是否可行，也才能比較好的去評審你的方案。
4.1 業務需求
業務需求就是你這個業務具體要做的事情，包括但不限于：
- 要改造的內容
- 要實現的新需求
4.2 業務痛點
- 涉及到的業務痛點有哪些
4.3 性能需求
我們做需求的時候，對于技術人員，不能只看業務需求，業務需求可能是項目管理人員，也可能是產品人員提出來的，他們只會重點關注業務的可行性，只會關注業務的邏輯。但是技術人員，要從這個業務需求里面考慮清楚我們滿足這個業務之下的性能需求點，比如我做一個秒殺活動，如果你不考慮性能，可能活動一上來，服務就掛掉了。性能需求包括但不限于：
- 預估系統平均容量
- 預估系統峰值容量
- 可伸縮性
- 其他的一些性能要求點，比如安全性等
5 方案描述
前面把現狀和需求說清楚后，終于到了我們的重頭戲，方案描述這里了。一般我們做方案，可能會有幾個可選的方案，但是你不清楚哪個方案最合適，因此你需要把相關可能的方案都描述清楚，然后給出你認為的最合適的方案，然后讓大家來評審和決策，看是否同意你的意見或者有其他更好的意見。
如果沒有方案對比，那么可以省略掉這一章節
5.1 方案1
概述
一句話概括方案的亮點，比如說：高性能、可擴展、雙寫、主從分離、分庫分表、擴容等。詳細說明
詳細說明這里需要圖文結合，包括但不限于架構圖、流程圖 等。把你整個方案的架構和模塊、細節流程都描述清楚-
性能目標
性能一般來說可能包含以下部分：- 日平均請求：一般來自產品人員的評估；
- 平均QPS：日平均請求 除以 4w秒得出，為什么是4w秒呢，24小時化為86400秒，取用戶活躍時間為白天算，除2得4w秒；
- 峰值QPS：一般可以以QPS的2~4倍計算；
-
性能評估
給出方案的基準數據，并按性能需求評估需要使用的資源數量。- 單機并發量
- 單機容量
- 按照預估性能需求，預估資源數量(應用服務器、緩存、存儲、隊列等)
- 伸縮方式
方案優缺點
列出方案的優缺點，優缺點要具有確定性，最好是通過量化的指標來說明
5.2 方案2
可選的另外一種方案，模板和上面一樣。
5.3 方案對比
前面給出了多種可選的方案，那么這里就是進行一個簡單的對比，然后給出你覺得最優的方案和原因，這就是你的決策。
有了你自己的決策（傾向）的方案后，接下來的設計就應該更多的偏向你傾向的方案去做設計和描述
6 線上方案
線上方案是對上面你更傾向的方案的更為細致的描述。
6.1 架構圖
整體架構是如何，把架構圖畫上
6.2 關鍵設計點 和 設計折衷
把幾個關鍵、重點的點的設計思想表述出來，用來確保你的方案的大體方向是 OK 的。
因為沒有一個方案設計是最完美，方案設計都是逐步演進和優化的，方案設計是要最符合當前的背景的。因此，一定會有你設計的關鍵點和折衷點，這也就是前面為何要把項目的各種業務背景和技術背景都說清楚的原因。
6.3 業務流程
整體流程是如何，弄一個整體流程圖、核心流程圖出來，然后分業務場景把各個業務場景的流程圖也畫出來，并且做好相關介紹
6.4 模塊劃分
有了業務流程，那么必然要針對這個業務流程的各個環節來劃分模塊，模塊的劃分需要考慮我們架構設計的一些原則，比如：架構分層、業務分模塊、微服務化、高內聚低耦合 等。然后把每個模塊的功能點都說清楚
6.5 異常邊界【重要】
異常邊界是比較重要的，一般情況下，大部分人都能考慮到正常的處理流程，對于異常的邊界考慮的比較少，但是線上出問題，大部分都是異常情況導致，因此這里非常重要！！！
我們可以通過一個 xmind 格式去整理相關的異常邊界，這樣有助于自己在實現的時候有足夠的把控度，也便于別人去 review 你的方案和具體實現（如 coding）
異常邊界需要考慮:
- 涉及到了哪些模塊
- 涉及到了哪些流程
- 每個模塊、流程出現了各種可能情況的處理是？
- 系統底層原因導致的異常的處理是 ？
6.6 統計、監控
線上運行的項目，一定需要有各種監控，除了公司內部的基建的監控外，我們可能還需要從業務內部實現自定義的一些業務監控和相關技術統計
6.7 灰度、回滾策略
- 如何灰度？
- 如何回滾？
6.8 容災方案
容災就是當出現 IDC 異常的情況下，怎么容災，這個可以根據實際情況去考慮。
7 部署拓撲
線上部署拓撲如何，上下游是如何
8 風險評估
標識所選方案的風險，提出解決此風險發生時候的應對策略，比如：上線失敗時的回滾策略。
潛在風險
- 相關的改動有哪些風險點
- 不兼容點？
- 當前設計方案目前存在哪些問題？
- 潛在有哪些問題
9 階段規劃【架構演進規劃】
架構怎么演進
階段如何規劃
-
每個階段該達成什么目標
- 第一階段
- 第二階段
- 第三階段
10 工作量評估
工作量評估也是一個重要的環節，這里需要細化到每個模塊、每個接口的設計分別需要多長時間，一定要同時包括開發時間、聯調時間、測試時間。
