架構師必須要清楚的概念（架構師成長之路）

2023-05-27 07:58:31 3

通過前面的文章，已經把高層架構設計所涉及到的各個部分基本講清楚了。

接下來看看概要設計階段要做什麼以及如何做。

概要設計階段要做的事情很多，把它總結梳理了一下，分成了如下十個大的方面，像寫設計文檔這些，都不算在內。

一：繼續架構設計

前面咱們講了很多高層架構設計方面的內容，相對而言，高層架構設計跟業務的聯繫不是那麼緊密。

除了這些之外，還有很多跟具體業務相關的架構設計的內容，這些就放到概要設計階段和詳細設計階段來做。

因此，在概要設計階段，需要繼續架構設計，又分成兩個方面：

1：對前面整體的技術架構，結合實際應用情況進一步細化

高層架構設計相對還是比較粗略，具體落地，還顯得空泛，因此，需要我們進一步結合實際應用情況，對架構設計進行細化。

比如：前面講緩存架構提到的：緩存使用中，具體使用什麼數據類型、存儲數據的格式等等

前面已經確定緩存使用Redis，那這裡就要結合著業務，來確定到底使用什麼類型，這個時候，架構師的技術功底就要受到考驗了，最起碼要對Redis的一些基本技術有所理解：

比如：你肯定得知道Redis的Value支持五種類型，每種類型都幹些什麼，特點是什麼，使用上有什麼限制等等的。然後再結合著具體業務，來進行選擇使用。可能就需要深入地理解適合應用Redis的地方：

（1） 緩存

（2） 取最新N個數據的操作，如：可以將最新的50條評論的ID放在List集合

（3）排行榜類的應用，取TOP N操作，前面操作以時間為權重，這個是以某個條件為權重，比如按頂的次數排序

（4） 計數器應用

（5） 存儲關係：比如社交關係，比如Tag等

（6）獲取某段時間所有數據排重值，使用set，比如某段時間訪問的用戶ID，或者是客戶端IP

（7） 構建隊列系統，List可以構建棧和隊列，使用zset可以構建優先級隊列

（8） 實時分析系統，比如：訪問頻率控制

（9） 模擬類似於HttpSession這種需要設定過期時間的功能

（10）Pub/Sub構建實時消息系統

（11）記錄日誌

2：做一些跟業務相關的典型業務系統的架構設計

概要設計階段，會進一步考慮一些跟業務和具體實現相關的架構，比如一些典型業務系統的架構設計：像什麼 秒殺、實時統計報表等等

二：繼續技術選型

這個大的部分在前面整體技術架構部分已經選好了，這裡主要選擇一些跟實際功能實現相關的技術，整體技術架構設計的時候不會考慮這麼細。

比如：文件上傳下載用什麼組件、excel讀寫用什麼框架、Image的壓縮轉換等等的。

三：繼續確定具體技術棧

針對已選型的技術，確定落地的技術棧，比如：要使用redis，那用哪個版本？使用什麼客戶端的技術？jedis還是lettuce？是使用原生API還是使用Spring提供的Template？客戶端使用哪個版本？等等。

如果是微服務架構，這個可能會更麻煩一些，假如選擇的是SpringCloud，那麼它不同的版本所包含的技術組件是不一樣的，組合方式也不一樣，直接會影響到整個技術實現。

也就是需要進一步對整個技術體系進行確定。

四：架構原型實現和架構驗證

這個這裡沒法具體演示，基本方法就是構建一個最簡單的、但是有代表性的業務，然後用這個架構和選定的技術，進行實現，以此來驗證架構是否達到預期。

如果我們使用的是已經使用過的架構體系，技術的組合方式也已經通過其它項目或產品的驗證，那麼，這個步驟可以省略。這個就看公司或者團隊自身的技術積累和沉澱了。

五：技術預研

這個不一定是每個項目都需要的，主要是針對項目中的重難點技術點、不確定的技術點，進行實際開發前的技術研究，以確保在現有的架構設計和技術體系下，能合理的實現這些功能點或技術點。

方法：抽象構建demo，能用於解決技術問題，不要涉及太多業務，聚焦於技術上的解決方案，但最後要能應用到項目中。

比如說現在項目中有一個功能要求實現以圖搜圖，如果這個功能以前沒有實現過，那就需要預先研究一下，看看如何來實現這個功能，另外還要看看能不能達到用戶的要求。

六：繼續分服務、分模塊

這裡會更細緻地考慮模塊的層級和拆分，進一步完善整個業務的拆分。

構建初步的系統工程結構 和 包結構。

七：應用的基礎框架設計

這個是進行具體開發的基礎，應該要先做。

這裡會設計具體的功能，只不過是把一些具體的、通用的功能做了一定的抽象和封裝，並考慮未來具體應用，該如何簡單的來使用這些功能。

當然，每個公司和團隊，都會有一些積累和沉澱，這裡就是在這些積累的基礎之上，結合具體的項目，進一步完善整個基礎框架或基礎功能包。

八：初步定義API

結合著每個模塊要實現的業務來定義。

這個有很多的規則、方法、技巧和經驗總結，後面可以給大家詳細講講如何進行API設計。

九：初步定義實體對象

這個方法比較簡單，主要依據是需求調研和需求分析。

屬性來源：業務單據、控制數據、暫存數據

相當於基本的vo（ValueObject）就有了。

十：初步定義資料庫表結構

前面定義的實體對象可以看作是資料庫的邏輯設計，基本上只需要把它們轉化成物理設計，就可以得到初步的資料庫表結構了。

當然，轉化後還是需要進行一些微調，比如：有些欄位是不需要在資料庫中存儲的。

有關於概要設計階段，具體要做的事情還有基本方法，就先聊到這裡。

如果你覺得本系列文章還不錯，能夠給你一些啟發和思考的話，請關注、點讚、收藏加轉發，讓更多的朋友加入到我們的行列，謝謝啦！

更多架構師之路乾貨文章，已在路上，稍後就到！