在系統設計初期，是做乙個大而全的系統還是根據模組進行拆分要根據環境和需求進行權衡。
訪問量不大、功能簡單、研發資源不多時可以做乙個大而全的系統即可；如果訪問量大資源充足、功能繁多可以考慮按功能拆分系統。
下面幾種拆分維度
按照系統功能/業務拆分，比如商品系統、購物車系統、結算系統、訂單系統等。
對乙個系統進行功能再次拆分，比如優惠券系統可以拆分為後台優惠券建立系統、領券系統、用券系統等。
根據讀寫比例特徵進行拆分。比如商品系統，交易的哥哥系統都會讀取資料，讀的量大於寫的量，可以拆分哼商品寫服務，商品讀服務；讀服務可以考慮使用快取提公升效能；寫的量太大，寫的量太大時，需要考慮分庫分表；有些聚合讀取的場景，如商品詳情頁，可以考慮資料來源異構拆分系統，將分散在多出的資料聚合到一處儲存，以提公升系統的效能和可靠性。
根據訪問特徵，按照aop進行拆分，比如商品詳情頁可以分為cdn，頁面渲染系統；cdn就是乙個aop系統。
這裡簡單說下aop（切面）維度的理解，aop程式設計(面向切面程式設計aspect oriented program)與oop(object oriented programming)程式設計相對應，我們可以簡單的理解aop程式設計(實際會更豐富)：**執行時，動態的將特定**切入到指定類的方法、指定位置上的程式設計思維。如果說面oop向物件程式設計是乙個平面橫向把乙個個類區分開，aop面向切面則是對oop的乙個很好的補充，縱向上增加了時間維度，**三維立體了。aop在oop中通過**機制實現。那麼什麼是aop維度的架構呢？不同請求再在用系統資源的時候，可以把系統資源進行拆分，如靜態資源放到cdn或nginx等，實現服務資源的立體化（不同資源由不同服務提供，**鏈路上一一收集資源最終返回給客戶）。
按照基礎**維護特徵進行拆分，如基礎模組分庫分表、資料庫連線池等，**結構按照三層架構（web、service、dao）進行劃分。（拆分顆粒需進一步**）
架構設計原則 高併發
架構設計原則 高併發 高併發設計可以從以下幾方面考慮 1.無狀態 無狀態的應用容易進行水平擴充套件。實際常用 應用無狀態，配置檔案有狀態，例如，不同的機房讀取不同的配置檔案，通過配置中心指定。2.拆分 拆分維度 3.服務化 服務化需要考慮自動服務註冊，和服務發現，還有服務的分組 隔離，例如，有的系統...
高併發架構設計原則 訊息佇列
解耦 消峰 非同步 有abcd四個系統，a系統有一條資料需要傳給bcd，a系統不僅要關心資料傳送還要處理資料傳送bcd其中產生的異常，如b掛掉了怎麼辦，a是否重傳？如果使用訊息佇列，a系統只負責傳送訊息到訊息佇列，bcd消費訊息佇列中的訊息即可，a系統不關心訊息發給誰了，誰消費失敗了等等問題。類似於...
高併發架構設計原則 無狀態
服務端不儲存任何客戶端請求者資訊，客戶端的每次請求必須具備自述資訊，通過這些資訊識別客戶端身份。優點 客戶端請求不依賴服務端的資訊，任何多次請求不需要必須訪問到同一臺服務，這樣為伺服器橫向擴充套件提供了條件。服務端需要記錄每次繪畫的客戶端資訊，從而識別客戶端身份，根據客戶端身份進行對請求的處理，如s...