在看到圖（一）這樣的圖，我們是否有一種探究系統的衝動？這樣一個花花綠綠的界面，背後隱藏着什麼樣的奧祕！用戶輸入某個域名的時候，比如www.taobao.com的時候，頁面是如何展示的，用戶在搜索框搜寶貝的時候，系統又是如何處理的，用戶在參加秒殺活動的時候，系統又是如何處理的。經過兩年多的互聯網從業經驗，以及自己的思考，在這裏我就拋磚引玉對電商系統架構進行探究，探究系統是如何設計的，以及設計這個系統的各種權衡。
圖（一）
隱藏在花花綠綠的界面之後，是一個龐大複雜的系統，圖（二）是這個系統的鳥瞰圖。我只描繪了一些枝幹子系統，省略掉其他輔助子系統。
在這個複雜的系統中，各個子系統是如何工作的？
1：User 是如何訪問到類似www.taobao.com 的頁面呢？User 在瀏覽器輸入www.taobao.com 的域名，瀏覽器通過DNS服務器解析該域名指向的IP地址。IP地址可能不只一個，有可能是多個。那該選擇哪一個，一般由DNS基於一定的策略返回。
2：假如瀏覽器選擇了一個IP地址，那麼通過該IP地址訪問到了頁面服務器，即WebServer。從可靠性、性能來講，WebServer 不只部署一臺機器，而是多臺。這樣部署既要負載均衡，又要在某個子節點崩潰後，能夠正常服務。我們的做法可以採用額外的負載均衡器方法，也可以通過LVS來實現。
3：WebServer 加載頁面詳情的時候，通過詳情繫統來加載。詳細系統通過聚合多個子系統的信息：商品子系統、圖片子系統（CDN）、活動子系統。
4：用戶登錄賬號的時候，是通過用戶賬號子系統，該子系統要支持統一賬號模式：通過郵箱登錄、QQ賬號登錄、微信賬號登錄。
5：用戶在搜索框輸入寶貝名稱的時候，搜索請求是通過搜索子系統來完成的。搜索子系統定時從備DB增量建索引，這種方式容忍搜索有一定的延遲。
其實也可以採用一些實時搜索系統，比如solr，或者採用大系統聚合小系統的方式，新增數據通過消息隊列的方式進入搜索系統的內存中，或者實時系統中，然後在用戶搜索的時候採用聚合的方式返回結果。
6：用戶購買商品的時候，先將物品加入購物車，這需要購物車系統，購物系統要訪問庫存系統，判斷當前是否有貨，如果有貨才允許用戶添加到購物車，並計算總價錢。添加購物車的時候，是否允許用戶減庫存，取決於用戶體驗和惡意用戶之間的矛盾：如果不允許減庫存，則有時用戶要下單的時候，會出現沒貨。如果允許減庫存，則存在惡意用戶佔着庫存，影響其他用戶購買。
7：庫存系統記錄了商品的價格、庫存等輕量信息，爲了性能的考慮，個人覺得庫存子系統是採用內存的方式，其數據來源商品系統（或者直接訪問數據庫）。
8：訂單系統：在活動期間，訂單系統會遇到峯值，所以訂單系統宜採用異步方式。
9：商品系統：吐商品信息的系統。
10：DB採用主備方式，現在常見的模式：寫主、查備。這種模式有主備數據一致性問題。備數據的實時性取決於同步，比較簡單的方式，採用數據庫本身的備份功能；或者在商品系統中通過異步寫。那寫主查備是基於什麼考慮的呢？只要是讀寫分離，提高性能。
11：跨區域容災，採用異步的方式，這種影響性能比較小，但是數據一致性不敢保障。這裏只能具體業務採取不同的策略，對一致性要求高的子系統，則採用異地同時雙寫。
12：子系統基於SOA的方式進行交付，現在一般採用某個RPC框架。個人覺得開源的ICE是不錯的選擇。
13：各個子系統，在本區域內採用主備模式。底層數據都掛了，則在底層系統跨地區訪問數據。所以需要一個跨區域的數據訪問代理，同時降級提供業務。
或者將訪問切向另外的一個區域，這裏要考慮另外一個區域的負載情況。
這裏，概略地介紹了電商系統的架構原理，接着後繼將對各個子系統的設計進行探討！