一個完整的電商系統，分為前臺交易系統與後臺作業系統，前後臺共庫是傳統企業在設計電商專案時的一個常見做法。但這個做法引發了上線後的諸多麻煩。在前臺交易系統處於峰值情況下，資料庫本身已存在很大的壓力，此時如果後臺作業系統產生大規模的查詢或寫入請求，則很容易造成資料庫無法響應。我們在很多客戶案例中發現，如果前後臺共庫，正常非峰值情況下，每日訂單數只要超過2000單，就會不同程度地出現前後臺互相干擾，資料庫成為主要瓶頸。此時，客戶不得不在系統高峰時停止在後臺作業系統上的操作，這給業務造成了很大傷害，發貨延時、客服水平下降、統計不準確等情況成了家常便飯。實際上，從架構上來說，前臺交易系統與後臺作業系統服務的使用者物件不同，前者是消費者，後者是企業內部員工，完全可以進行系統分離，兩者之間採用訊息佇列進行非同步訂單傳輸，以隔離互相之間的影響。

當然，對於交易系統，我們也要根據業務特徵進行分散式設計，提升業務擴充套件性、應對高負載。例如對商品貨架系統、會員系統、核心交易系統、資金系統、日誌系統等以高內聚、低耦合的原則進行分離，以分別根據不同的訪問特徵進行優化。

根據分散式架構的CAP理論，Consistency（一致性）、 Availability（可用性）和Partition tolerance（分割槽容忍性）最多隻能同時滿足兩點。對於一個峰值系統而言，分散式（分割槽）設計是必然的，可用性也是基礎要求，因此，我們只能放棄一致性要求，只達到最終一致性。不過，在一個電商系統的架構設計中，最容易出現的問題是濫用CAP原則。例如在交易過程中，後臺的供應能力（庫存）是至關重要的，在交易生成過程必須要保證嚴格一致性，而不是最終一致性，這就要求我們以事務的方式來解決。否則，雖然在架構實踐中很容易達到從容應對峰值訪問的目的，但超賣等傷害業務的現象必然會出現。

在分散式系統設計中，必然要求我們採用面向服務的體系結構（SOA）。但需要在設計中注意幾點。第一，在峰值系統中，每一個多餘位元組的傳輸都意味著對系統的極大開銷，以每日1000萬PV為例，假設這是每個請求都需要呼叫的服務，每新增一個位元組，就意味著會新增10MB的流量。第二，千萬不要直接使用自己企業內部IT原來部署的服務。這是因為企業內部原有的SOA服務不是為網際網路峰值系統所設計的。我們曾經有一個客戶，在電商網站上使用了企業內部IT提供的客戶驗證服務，看上去只是一個簡單查詢，結果甫一上線，直接導致該服務崩潰，進而引發整個內部IT SOA體系的下線，對內部系統造成的影響用了好幾天才得以消除，更不用說對線上系統的影響了，嚴重傷害了企業的形象。第三，冪等原則。假設所有的服務呼叫都是不可靠的，所以重試是常態，因此對於重複的