電商系統架構——系統鳥瞰圖

標籤：電商   系統架構   互連網   設計   搜尋   

             在看到圖（一）這樣的圖，我們是否有一種探究系統的衝動？這樣一個花花綠綠的介面，背後隱藏著什麼樣的奧秘！使用者輸入某個網域名稱的時候，比如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：各個子系統，在本地區內採用主備模式。底層資料都掛了，則在底層系統跨地區訪問資料。所以需要一個跨地區的資料訪問代理，同時降級提供業務。

        或者將訪問切向另外的一個地區，這裡要考慮另外一個地區的負載情況。

  這裡，概略地介紹了電商系統的架構原理，接著後繼將對各個子系統的設計進行探討！

電商系統架構——系統鳥瞰圖