在我們從零開始做乙個新系統的時候，會首先進行系統功能模組架構設計，那麼是直接做乙個大而全的垂直的mvc系統，使用乙個war包進行發布管理，還是需要按一些規則進行模組拆分，設計成soa或者微服務系統比較好呢？這個筆者認為需要依據專案具有什麼樣的人力物力條件以及專案需要支撐多少使用者量和交易量為基礎。乙個好的系統設計應該能夠滿足解決當前的需求和問題，把控實現和進度風險，**和規劃未來，避免過度設計，在上線乙個基礎核心版本之後，再進行不斷迭代和完善。
今天我們來談一談進行soa、微服務系統架構設計時模組拆分的一些維度和原則。
按照系統業務功能進行劃分，例如對於電商系統，按功能維度我們可以拆分為商品中心，訂單中心，使用者中心，購物車，結算等功能模組。
對於乙個功能模組可以按照不同的業務邏輯狀態再進行劃分，比如電商的優惠券模組按狀態可以劃分為建立模組，領券模組，使用模組。這個是從乙個業務從開始到結束的不同狀態進行的模組拆分。
按照讀寫不同的壓力進行拆分，例如對於商品中心而言，讀取商品詳情的量會特別大，遠遠大於寫入商品詳情的量。這個時候就可以拆分為商品的寫服務、讀服務。讀取服務可以考慮使用redis或者memcache快取來提高效能，也可以做讀寫分離，而且可以依據訪問需求量增加或者減少讀寫服務的部署數量。當寫入的量太大時，可以考慮做分庫分表，有些聚合讀取的場景，比如商品詳情頁可以考慮使用資料異構，將分散的資料聚合到乙個儲存，從而提公升系統的可靠性和效能。
按照縱深的維度，最底層的是基礎服務，最上層的是業務服務，**結構一般按照mvc三層架構來進行劃分。
根據訪問特徵，按照aop進行拆分，比如商品詳情頁可以分為cdn、頁面渲染模組等。而cdn就是乙個aop。
高併發架構設計原則 拆分
在系統設計初期，是做乙個大而全的系統還是根據模組進行拆分要根據環境和需求進行權衡。訪問量不大 功能簡單 研發資源不多時可以做乙個大而全的系統即可 如果訪問量大資源充足 功能繁多可以考慮按功能拆分系統。下面幾種拆分維度 按照系統功能 業務拆分，比如商品系統 購物車系統 結算系統 訂單系統等。對乙個系統...
架構設計的幾個痛點 我總結出的架構原則和模式
應用層用負載均衡伺服器，能夠監測伺服器的可用性，把不可能的踢出集群 服務層使用分布式呼叫框架dubbo 資料庫使用同步複製，實現資料冗餘。還要考慮公升級發布引起的宕機 整體來說就是冗餘，故障轉移，使用分布式呼叫框架。分級管理 0級，1級。更重要的服務，使用更好的裝置 超時設定 不超時會長時間占用伺服...
架構設計之資料庫垂直 水平拆分六大原則
資料拆分前其實是要首先做準備工作的，然後才是開始資料拆分，我先講拆分前需要做的事情 第一步 採用分布式快取redis memcached等降低對資料庫的讀操作。第二步 如果快取使用過後，資料庫訪問量還是非常大，可以考慮資料庫讀 寫分離原則。第三步 當我們使用讀寫分離 快取後，資料庫的壓力還是很大的時...