河北百度愛采購以最小化可行產品方式迭代推在持續開發系統的過程中，會有一些設計原則/經驗可以用來遵循和指導我設計原則應該在系統迭代過程中，根據現有問題或特征匹配使用，如果剛開始遇到的不是核心問題，那么不要復雜化系統設計，但先行規劃和設計是有必要的，要對現有問題有方案，對未來架構有預案1.1高并發原則1.1.1無狀態果設計的應用是無狀態的，那么應用比較容易進行水平擴展。實際生境可能是這樣的：應用無狀態，配置文件有狀態。
    比如，不同的河北百度愛采購需要讀取不同的數據源，此時，就需要通過配置文件或配置中心指1.1.2拆分在系統設計初期，是做一個大而全的系統還是按功能模塊拆分系統，這個需要根據環境進行權衡。比如，做私塾在線時，本身用戶量/交易量不會特別大，開發就筆者源有限，那就沒必要對系統拆分（比如，拆分商品、訂單等），做一個大而全的系統即可。而像設計京東秒殺系統，訪問量是非常大的而且投入的資源還是蠻充足的，在這種情況下，就可以考慮按功能拆分系統筆者遇到的拆分主要有如下幾種情況。系統維度：按照系統功能/業務拆分，比如商品系統、購物車、結算、訂單系等功能維度：對進行功能再拆分，比如，優惠券系統可以拆分為后臺券創建系券系統、用券系統等讀寫維度：根據讀寫比例特征進行拆分。比如，河北百度愛采購的各個系統都會讀取數據，讀的量大于寫，因此可以拆分成商品寫服務、商品讀服務；讀服務可以考慮使用緩存提升性能；寫的量太大時，需要考慮分庫分表；有些聚合讀取的場景，如商品詳情頁，可考慮數據異構拆分系統，將分散在多處的數據聚合到一處存儲，以提升系統的性能和可靠性AOP維度：根據訪問特征，按照AOP進行拆分，比如，商品詳情頁可以分為CDN、頁面渲染系統；CDN就是一個AOP系統模塊維度：比如，按照基礎或者代碼維護特征進行拆分，如基礎模塊分庫表、數據庫連接池等；代碼結構一般按照三層架構（web、 Service、DAO）進行劃分。
    服務化首先，判斷是不是只需要簡單的單點遠程服務調用，單機不行集群是不是就可以解決？在客戶端注冊多臺機器并使用 Nginx進行負載均衡是不是就可以解決？隨著調用方越來越多，應該考慮使用服務自動注冊和發現（如 Dubbo使用ZooKeeper）。其次，還要考慮服務的分組/隔離，比如，有的系統訪問量太大致把整個服務打掛，因此，需要為不同的調用方提供不同的服務分組，隔離訪問。后期隨著調用量的增加還要考慮服務的限流、黑白名單等。