系統架構設計入門掃盲

最近負責一個項目的系統架構設計，剛開始粗粗給了個草案。經過一次修訂後帶著草案稿去找了一下公司首席科學家 傳說中的“老天”，促膝長談一整天，雖然被批判得一無是處，但是我卻覺得異常之爽，頓時覺得在系統架構設計上已經漸漸掃盲開始進入正軌。

 

極度歡迎有理由的對我批判，越狗血淋頭越過癮。。（是不是有些犯賤了，哈哈）

 

結合項目實際情況，總結一下一些改進建議和以後值得注意的地方：

 

 

1。 平台API先不用考慮。我原先第一版就在平台上考慮了公用API，但是實際上在第一版描述中，其用途不大，並且以後想擴充的話很簡單。所以為了降低系統複雜度，不用考慮。2。 設計要更加細化，必須拍板必要的技術選型。系統設計絕不是對需求的再描述，作為系統架構師，必須剛開始就對關鍵的技術選型拍板。3。 調用關係不允許出現三角關係。原先的設計圖中沒有特別標明主從關係，於是導致了看似三角關係的出現。實際上應該標明調用方向，主動發起者是箭頭的起始位置。4。 要能從設計層面識別程式模組。必須明確的指導，哪個系統是一個什麼樣的程式。（如命令列程式、系統服務程式、WEB服務程式？）5。 本系統不是分層系統，而是一個網路樞紐系統（星型）。分層系統一般對於底層是完全封閉的菜適用，星形系統不能描述為分層系統。6。 對業務的拆分放到業務層，任務系統必須業務無關。盡量拆分業務無關模組，業務相關的任務下達必須在業務層完成。7。 計算過程拆分後，中間計算過程不能直接主動的記錄結果，而必須調度系統匯總。（事務，防崩潰）中間任務模組要考慮事務的崩潰恢複。8。 計算系統和外部管理系統可以進一步抽象成計算單元。9。 調度系統與業務的耦合應該使用資料庫隔離。10。 配置資訊也要在架構設計體現。11。 所有調用關係必須明確。12。 參考狀態 > 參考曆史。13。 所有系統盡量被動。這樣可以降低系統耦合以及開發的複雜度。14。 視頻元計算不可分割，不用考慮分布式叢集計算。15。 日誌必須是可以丟棄的，不然就是業務。這句話經典啊。16。 計算節點自動升級從開始就可以設計。