系統設計的三板斧

【一凡sir，原創文章，禁止轉載】

背景

對於技術來說，每一個系統都少不了最重要的一個環節，系統設計。
系統設計的成功與否直接決定了後續的系統開發能否成功。
這次的分享，我們將系統設計的方法簡化為三板斧，簡單易懂，居家旅行學習進修必備。
三包承諾：包記住，包理解，包會用。如有問題，請再看一遍。如想快速瀏覽，可以先看總論

大綱

• 1 系統設計的基本流程

• 2 三板斧的招式

• 3 例項講解，許可權系統設計

• 4 總結
  

什麼是系統設計

The process of defining the 　　　　　　　　　 　 定義（產出）
architecture, 　　　　　　　　　　　　　　　　　架構
components, 　　　　　　　　　　　　　　　　　元件
modules, 　　　　　　　　　　　　　　　　　　　模組
interfaces, 　　　　　　　　　　　　　　　　　　介面
and data 　　　　　　　　　　　　　　　　　　　資料
for a system to satisfy specified requirements. 　　需求（目標）

1 系統設計的基本流程

1.1 軟體開發流程

• 1 需求分析

• 2 概要設計

• 3 詳細設計

• 4 系統開發

• 5 系統測試

• 6 軟體交付
  軟體開發流程，詳細內容可以參考： 
  需求分析就是一個很專業的工作，對於大型的軟體開發，也有專門的需求分析師，所以這裡面的方法和流程也還有很多細分的內容，有興趣的同學可以繼續挖掘。
  系統設計主要就是2、3兩部分，大學畢業設計的時候，應該也都有深刻的印象，自己的文件是怎麼寫出來，怎麼組織和編排的吧。

1.2 系統設計的流程

系統設計的內容可以用16或者32課時來專門開一課，大學時候應該也有這樣的課，可能是選修吧。
詳細內容可以參考： 從 0 到 1 教你設計業務系統 

1.3 總結，系統設計的基本流程

上面的軟體開發流程和系統設計流程，看著就很複雜，分工很細，要完全遵守這些方法來做網際網路產品開發的話，很多人是無法想象的，2週上線，1天1個版本？
所以，上面的流程都是來自傳統的企業軟體開發方法。而傳統軟體的開發週期，最少也是半年、一年的週期，交付物也都會比較嚴格，也不會有持續迭代一說。
傳統企業軟體開發，有很多是外包公司，規模很大，類似富士康的工廠。而規模的基礎就需要標準化，遵守各種認證體系的要求，這樣也更能被企業認可和信任。
但是，這些流程、方法，對於我們網際網路研發就很不合適，系統設計也是。所以，才有了本文的核心方法。

2 三板斧的招式

2.1 第一招：抽象，萬物歸一

• 1 人，主體物件
  實體模型，資料結構

• 2 事，核心功能
  元件模組，功能需求

• 3 物，資源要求
  系統規模，開發週期，架構設計

宏觀上的面，提煉和定義，不拘泥細節。
從繁雜的系統中剝離、提煉，抽象出來我們系統的核心，定義好系統的人、事、物，也就有了系統的大致樣貌。
抽象，這是最重要的一步，也是最厲害的一招。

2.2 第二招：具象，有血有肉

• 1 資料結構設計
  物件的屬性，資料表

• 2 業務功能設計
  功能模組，任務清單

• 3 系統架構設計
  效能、併發、伸縮、擴充套件、安全

微觀實現的點，為後續的編碼掃平模糊。
系統設計在這一招完成後，基本上就要全面完工了，交付給開發來編碼。如果這時候還有不清晰的地方，還有遺留的點，那麼後續就會出現很嚴重的需求變更、技術變更、甚至重構，會嚴重影響專案開發的週期和質量。
具象，這是需要細緻且耐心的一步，也是勢大力沉的一招。

2.3 第三招：演算，活靈活現

• 1 業務流程
  讓功能細節發生互動（業務戀愛）

• 2 資料流程
  讓物件之間發生關係（資料懷孕）

• 3 模擬操作與系統預估
  模擬的運轉和系統壓力評估（成長煩惱）

流程不通，操作不順，系統瓶頸，及早發現和補充完善。
純腦力運算的過程，可能是設計者來做，也可能是要系統相關人一起來做。
這裡用時2小時或者一起開個會，把系統設計的方方面面都模擬的運轉起來，各個環節，各個角色帶入進來，發現問題馬上調整前面的抽象和具象的設計。
演算是一個快速查缺補漏的環節，也是對系統設計進行方案最佳化、調整的最後環節，這裡投入的每一分鐘都是十倍百倍於後續研發階段的調整時間效率。
演算，這是最容易忽略的一步，也是最難的一招。

2.4 總結，系統設計的三板斧

圍繞系統設計中的人、事、物，我們透過宏觀層面的抽象，提煉和定義出來核心內容，在透過微觀層面的具象，把各個細節補充完善，最後，運用演算，讓這個系統在我們的腦子裡面活起來，重複這三板斧，完善我們的系統設計。

3 例項講解，許可權系統設計

介紹：許可權系統管理著應用和服務之間的呼叫關係。應用要呼叫服務的介面，必須先申請對應的服務介面許可權才可以。

3.1.1 抽象：許可權系統的核心物件（主體）

• 1 主要物件
  應用，服務

• 2 派生物件
  介面，應用請求服務
  許可權，介面許可權

• 3 外部物件
  閘道器，系統平臺，第三方服務等
  提煉許可權系統內部的主體物件，確定系統的資料模型。

3.1.2 抽象：許可權系統的核心功能（硬性）

• 1 許可權相關功能
  應用端申請，服務端審批，查詢

• 2 後臺管理功能
  服務資訊和擴充套件許可權的配置

• 3 擴充套件功能
  訊息通知，許可權推送
  定義必須的應用的全後端功能，擴充套件的與外部系統的互動功能。

3.1.3 抽象：許可權系統的資源要求（軟性）

• 1 許可權的管理系統，不涉及許可權驗證
  系統併發量很有限，效能要求低

• 2 平臺內應用、服務的許可權依賴度高
  系統的安全和穩定性高

• 3 內部和外部服務的許可權定義差別大
  擴充套件性要求高
  系統的架構設計不必過於複雜，保證應用程式的安全和穩定性，定義好系統的可擴充套件性。

3.2.1 具象：許可權系統的資料結構

• 1 申請記錄表 tb_privilege
  應用相關
  服務相關
  介面相關
  申請相關
  審批相關
  標準欄位
  

• 2 服務配置表 tb_paas
  服務資訊
  推送相關
  外部相關
  擴充套件相關
  標準欄位
  

• 3 操作日誌表 tb_log
  資料模型
  新舊資料
  標準欄位

3.2.2 具象：許可權系統的業務功能

細化每一個功能的處理過程，要結合互動頁面，操作流程，資料輸入和產出等。

3.2.3 具象：許可權系統的系統架構

• 1 分層模型，前後端分離
  前端展現和互動，後端資料和邏輯，前後端耦合度低

• 2 服務的許可權訂閱和推送，預留第三方服務和擴充套件許可權
  定製化多端推送，擴充套件能力強

• 3 多機分散式，定時任務更新許可權和通知
  資源伸縮性強
  **架構演化：**單機 -> 分散式，單庫 -> 主從庫 -> 快取層 -> 資料分拆（水平、垂直） -> 應用分拆（微服務）
  架構選擇，只有合適與否，沒有好壞之分。

3.3 演算：資料流程、業務流程和互動模擬

• 1 許可權申請流程
  方便查詢服務，方便申請介面許可權

• 2 許可權審批流程
  方便查詢服務，方便申請介面許可權

• 3 介面許可權申請的狀態變更
  申請、審批和推送、通知，把開發者、服務方、閘道器、服務都串聯起來
  流程，讓整個系統運轉起來，是一個活的系統，不再是冷冰冰的資料結構和系統框架。
  考慮開發者和服務方的使用者，帶入使用者的立場和操作，更好地模擬整個系統的互動體驗。

3.4 總結，例項講解，許可權系統設計

這裡的例項比較簡單，但畢竟是最近設計開發的一個系統。
而對於更加複雜的系統，方法還是互通的。
定義好，寫下來，畫下來，這就是一個系統設計和專案文件。
當然系統設計不僅僅是上面呈現出來的內容，還有關於介面，任務清單等內容。

4 總結，系統設計的三板斧

一句話形容，從宏觀到微觀，互動更長久。
抽象，先從宏觀層面做好抽象；
具象，再從微觀層面補充完善細節；
演算，全流程的模擬，查缺補漏；
重複上述三板斧，不斷完善系統設計。
注意：不用糾結未知和差異化太大的部分。
系統設計的三板斧，相信不僅僅可以用在系統設計中，在其他的很多方面應該也是類似，比如：寫作。
主題 -> 目標
創意 -> 抽象（人、事、物）
細節 -> 具象（有血有肉）
故事 -> 演算（活靈活現）

在最後，強調一遍，抽象和推理是數學的重要能力，數學絕對是極其重要的學科，掌握好數學，能夠更好地掌握科學方法，而不僅僅只有個人的經驗和直覺。

關注我的實戰課程
《》
《》