通過前面的文章，已經把高層架構設計所涉及到的各個部分基本講清楚了。
接下來看看概要設計階段要做什麼以及如何做。
概要設計階段要做的事情很多，把它總結梳理了一下，分成了如下十個大的方面，像寫設計文檔這些，都不算在内。
一：繼續架構設計
前面咱們講了很多高層架構設計方面的内容，相對而言，高層架構設計跟業務的聯系不是那麼緊密。
除了這些之外，還有很多跟具體業務相關的架構設計的内容，這些就放到概要設計階段和詳細設計階段來做。
是以，在概要設計階段，需要繼續架構設計，又分成兩個方面：
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）就有了。
十：初步定義資料庫表結構
前面定義的實體對象可以看作是資料庫的邏輯設計，基本上隻需要把它們轉化成實體設計，就可以得到初步的資料庫表結構了。