如何打造一個小而精的電商網站架構？

標籤：bug   let   移動web   擴容   database   war   流量   手機瀏覽   使用者體驗   

本文大綱：

1. 小型電商網站的架構

2. 日誌與監控系統的解決方案

3. 構建資料庫的主從架構

4. 基於共用儲存的圖片伺服器架構

5. 移動M站建設

6. 系統容量預估

7. 緩衝系統

 

   

一、小型電商網站的架構

  

 

剛從傳統軟體行業進入到電商企業時，覺得電商網站沒有什麼技術含量，也沒有什麼門檻，都是一些現有的東西堆積木似的堆出來罷了。然而，真正進入到這個行業之後，才發現並非如此。有人說過，好的架構，是演化出來的，電商網站的架構也是如此。現在好的電商網站，看似很複雜，很牛逼，其實也是從很小的架構，也是從沒什麼技術含量開始的。所以，架構的演化過程，就是在技術團隊不斷追求極致的過程。

 

今天就來總結小型電商網站的架構演化。一套電商系統最初期的架構，往往會採用一個比較典型的LAMP架構，前端加上Apache/PHP，後端是MySQL。這個算是比較流行的。不過，目前還有一套.net的技術架構，可能大家很少提到。很不幸，我就是在一個.net平台為基礎的電商公司。所以，今天也是要總結.net 平台的電商架構。

 

1技術架構

 

 

一般初期的電商網站，基本就幾個業務子系統：網站前台、商家前台、系統管理後台、App、M站等。業務量也不是很大。所以，MVC + 緩衝 + 資料庫基本就搞定了。

 

單就開發效率而言，.net MVC 的技術架構不會比LAMP開發速度慢。所以，一些企業，為了快速推出自己的電商平台，也會採用.net 架構。

 

2基礎架構

 

 

為基礎架構層面。這是一個很簡單的基礎架構。

 

• 前端網站和M站，考慮到訪問量和系統的可用性，基本會採用分布式部署。通過Proxy 伺服器進行請求分發。

• 其它的業務子系統，像商家前台和管理系統，基本上都是單機或是主從部署。

• 各個DB ，Redis 服務和檔案和圖片服務，搜尋引擎Solr服務等，採用主從部署。

 

3詳細架構

 

 

整個系統架構裡面，還有一個比較重要的組成部分，那就是監控系統。例如：流量監控、硬體監控、系統效能監控等， 還有就是對某個頁面進行監控，設定頁面的其中一塊進行監控等。它是提高整個平台可用性的一個重要手段。多平台、多個維度監控，能夠確保系統的可用性。一旦出現異常，特別在硬體或者效能方面出現異常，監控系統也能立刻發出警告，這樣也好防範於未然。

 

總而言之，一個好的系統架構應該從擴充性、安全性、效能和可靠性來考慮。羅馬不是一天建成的，架構適合就行，可以先行之而後優。通過漸進演化的過程，逐步讓系統越來越完善。

 

   

二、日誌與監控系統的解決方案

  

 

監控系統主要用於伺服器叢集的資源和效能監控，以及應用異常、效能監控、日誌管理等多維度效能監控分析。一個完善的監控系統和日誌系統對於一個系統的重要性不必多說。總之，只有即時瞭解各系統的狀態，才能保證各系統的穩定。

 

 

如所示，監控平台監控的範圍很廣，從伺服器效能及資源，到應用系統的監控。每個公司都有特定的平台統一監控的需求及解決方案，但監控平台的任務和作用基本是一致的。

 

1日誌

 

日誌是監視程式啟動並執行一種重要的方式，主要有兩個目的：1.bug的及時發現和定位；2.顯示程式運行狀態。

 

正確詳細的日誌記錄能夠快速的定位問題。同樣，通過查看日誌，可以看出程式正在做什麼，是不是按預期的設計在執行，所以記錄下程式的運行狀態是必要的。這裡將日誌分為兩種：1.異常日誌；2.作業記錄。

 

我們主要是使用log4net，將各個系統的日誌，持久化記錄到資料庫或者檔案中，以方便後續的系統異常監控和效能分析。如何整合log4net，這裡不多說。

 

日誌記錄的幾個原則：

• 記錄層級一定要區分清楚，哪些屬於error、warning、info等。

• 記錄錯誤的位置。如果是分層系統，一定要在某個層統一處理，例如我們的MVC架構，都是在各個Action中Catch異常並處理，而業務層和資料庫層這些地方的異常，都是Catch到異常後，往上一層拋。

• 日誌資訊清晰準確有意義，日誌盡量詳細點，以方便處理。應該記錄相關係統、模組、時間、操作人、堆棧資訊等。方便後續處理。

 

2監控

 

監控系統是一個複雜的系統平台，目前有很多的開源產品和平台。不過我們平台小，監控任務和需求少，所以基本都是自己開發。主要有這五個方面：1.系統資源；2.伺服器；3.服務；4.應用異常；5.應用效能。

 

具體的架構圖如下：

 

 

1）系統資源監控

監控各種網路參數和各伺服器相關資源（CPU、記憶體、磁碟讀寫、網路、訪問請求等），保證伺服器系統的安全運營，並提供異常通知機制以讓系統管理員快速定位/解決存在的各種問題。目前比較流行的應該是Zabbix。

 

2）伺服器監控

伺服器的監控，主要是監控各個伺服器、網路節點、網關等網路裝置的請求響應是否正常。通過定時服務，定時去Ping各個網路節點裝置，以確認各網路裝置是否正常。如果哪個網路裝置出現異常，則發出訊息提醒。

 

3）服務監控

服務監控，指的是各個Web服務、圖片服務、搜尋引擎服務、快取服務等平台系統的各項服務是否正常運行。可以通過定時服務，每隔一段時間，就去請求相關的服務，以確保平台的各項服務正常運行。

 

4）應用異常監控

目前我們平台所有系統的異常記錄，都記錄在資料庫中。通過定時服務，統計分析一段時間之內的異常記錄。如果發現有相關重要的模組的系統異常，比如支付、下單模組頻繁發生異常，則立即通知相關人員處理，確保服務正常運行。

 

 5）應用效能監控

在API介面和各應用的相關位置進行攔截和記錄下程式效能（SQL效能，或是 程式執行效率）。相關重要模組提供效能預警，提前發現問題。 同時統計相關監控資訊並顯示給開發的人員，以方便後續的效能分析。

 

   

三、構建資料庫的主從架構

  

 

發展到大型成熟的公司之後，主從架構可能就有點落伍了，取而代之的是更加複雜的資料庫叢集。但作為一個小型電商公司，資料庫的主從架構應該是最基礎的。任何大型的系統架構，都是不斷演化的。主從架構便是資料庫結構描述中最基礎的架構。所以研究完主從架構，也就能看懂更加複雜的架構了。

 

首先為什麼要讀寫分離？

 

對於一個小型網站，可能單台資料庫伺服器就能滿足需求。但在一些大型的網站或者應用中，單台的資料庫伺服器可能難以支撐大的訪問壓力，升級伺服器效能成本又太高，所以必須要橫向擴充。還有就是，單庫的話，讀、寫都是操作一個資料庫。資料多了之後，對資料庫的讀、寫效能就會有很大影響。同時對於資料安全性和系統的穩定性也是挑戰。

 

資料庫的讀寫分離的好處？

 

• 將讀操作和寫操作分離到不同的資料庫上，避免主伺服器出現效能瓶頸；

• 主伺服器進行寫操作時，不影響查詢應用伺服器的查詢效能，降低阻塞，提高並發；

• 資料擁有多個容災副本，提高資料安全性，同時當主伺服器故障時，可立即切換到其他伺服器，提高系統可用性。

 

 

讀寫分離的基本原理就是讓主要資料庫處理事務性增、改、刪操作（Insert、Update、Delete）操作，而從資料庫處理Select查詢操作。資料庫複寫被用來把事務性操作導致的變更同步到其它從資料庫。

 

以SQL為例，主庫負責寫資料、讀資料。讀庫僅負責讀資料。每次有寫庫操作，同步更新到讀庫。寫庫就一個，讀庫可以有多個，採用日誌同步的方式實現主庫和多個讀庫的資料同步。

 

1SQL Server 讀寫分離的配置

 

SQL Server提供了三種技術，可以用於主從架構之間的資料同步的實現：記錄傳送、事務複製和SQL 2012 中新增的功能Always On 技術。各自優劣，具體的大家自己去百度吧，這裡提供網上的朋友的配置方式，僅供參考。

 

• 記錄傳送：SQL Server 2008 R2 主從資料庫同步

  （連結：http://www.it165.net/database/html/201306/4088.html）

• 事務複製：SQL Server 複製：事務發布

  （連結：http://www.cnblogs.com/gaizai/p/3305879.html）

 

 

（圖源：網路）

 

2C# 資料庫讀寫操作

 

C#的請求資料庫操作，單資料庫和主從架構的資料庫還是不一樣的。主從架構的資料庫，為了保證資料一致性，一般主庫可讀可寫，從庫只負責讀，不負責寫入。所以，實際C#在請求資料庫時，要進行區別對待。

 

最簡單的就是：配置兩個資料庫連接，然後在各個資料庫調用的位置，區分讀寫請求相應的資料庫伺服器，如：　

　　

 

第二種解決方案就是判斷SQL語句是寫語句（Insert 、Update、Create、 Alter）還是讀語句（Select）。

 

Demo下載：http://files.cnblogs.com/files/zhangweizhong/Weiz.DB.rar

 

（PS：此Demo為本人總結，跟實際生產中的DLL 不太相同，但原理是一樣的，大家總結封裝吧）

  

 

同時，增加相關的資料庫配置

 

 

   

四、基於共用儲存的圖片伺服器架構

  

 

在當前這個互連網的時代，不管何種網站，對圖片的需求量越來越大。尤其是電商網站，幾乎都會面臨到海量圖片資源的儲存、訪問等相關技術問題。在對圖片伺服器的架構、擴充、升級的過程中，肯定也會碰到各種各樣的問題與需求。當然這並不代表，你就必須得弄一個特別NB的圖片服務架構，只要簡單、高效、穩定就行。這部分我們來總結一個特別簡單、高效的圖片服務架構：通過共用儲存的方式來實現圖片服務架構。

 

然而，也有一些人問我，現在大型網站的圖片伺服器的架構已經完全不是這樣了，別人家的圖片系統比你這個牛逼多了，為啥不直接寫那個呢？ 

 

事實是：第一，大型牛逼的系統我也不會；第二， 再牛逼的系統也是從小的架構演化過去的，沒有一步到位的。這裡介紹圖片伺服器架構雖然比較簡單，但也是經過了單機時代的演化了，基本上可以滿足中小型分布式網站的需求。這種架構的搭建和學習成本都極低，符合目前“短平快”的開發模式。

 

通過共用目錄的方式實現共用儲存 ，在共用目錄檔案伺服器上配置獨立網域名稱，這樣可以將圖片伺服器和應用伺服器進行分離，來實現獨立圖片伺服器。

 

優點：

1. 將圖片服務和應用服務分離，緩解應用伺服器的I/O負載。

2. 通過共用目錄的方式來進行讀寫操作，可以避免多伺服器之間同步相關的問題。

3. 相對來講很靈活，也支援擴容/擴充。支援配置成獨立圖片伺服器和網域名稱訪問，方便日後的擴充和最佳化。 

4. 相對於更加複雜的分布式的NFS系統，這種方式是性價比高，符合目前互連網的“短平快”的開發模式。

 

缺點 ：

1. 共用目錄配置有些繁瑣。

2. 會造成一定的（讀寫和安全）效能損失。

3. 如果圖片伺服器出現問題，那所有的應用都會受到影響。同時也對儲存伺服器的效能要求特別高。

4. 圖片上傳操作，還是得經過Web伺服器，這對Web伺服器還是有巨大的壓力。

 

架構非常簡單，基本架構如所示：

 

 

 

在儲存伺服器上建立一個共用目錄（具體方式，我就不去重複了，自己百度吧，注意共用目錄的檔案安全）。

 

各個應用直接通過共用目錄（\\192.168.1.200），將圖片上傳到儲存伺服器上。

 

建立一個Web網站（i1.abc.com）將該共用目錄通過Web網站發布出去。這樣其它的應用就能訪問到相關圖片。

 

所以，各應用將檔案上傳到共用目錄

   

    //儲存原圖
//完整的地址：\\192.168.1.200\lib\2016\03\04\10\IMG\4ugvvt6m9gdu.jpg
relativePath = relativeDir + fileName + imageExtension;

       var absolutePath = ConfigHelper.SharePath + relativePath;

       fileData.SaveAs(absolutePath);             

  

上傳成功後，可直接通過web 的方式訪問：

http://i1.abc.com/lib/2016/03/04/10/IMG/4ugvvt6m9gdu.jpg

 

   

五、移動M站建設

  

 

最近在一直在搞M站，也就是移動Web網站。由於是第一次，也遇到了很多問題，所以把最近瞭解到的東西總結一番。聊一聊什麼是移動M站，以及它有什麼作用和優勢。

 

有人會問，M站和APP有什麼不同？

 

1. APP直接在使用者的行動裝置上，曝光率相對較高。 而M站需開啟瀏覽器，輸入地址才能訪問，所以曝光率相對較低。

2. M站的推廣的渠道相比移動APP，渠道較多，方便追蹤使用者來源、流量入口等，方便以後的活動推廣和資料分析。

3. M站使用者無需安裝，輸入URL即可訪問，而APP需要下載安裝。

4. M站能夠快速地通過資料分析，能快速得到使用者的反饋，從而更容易根據統計資料分析和使用者的需求來調整產品。

5. APP對使用者更具粘性及使用者體驗也更好。

6. M站對於營銷推廣活動非常方便，轉寄分享方便快捷。

7. M站更新迭代產品速度和響應產品調整非常快，隨時發布，而APP需要審核時間。

8. M站跨平台，無需開發安卓和iOS版，只需有瀏覽器即可。     

 

所以， 我覺得，M站和用戶端是相輔相成的。M站的及時性和快捷性，是APP無法比擬的。而APP的使用者體驗，則是M站無法做到的。目前來說兩者是不可能被對方完全替代的，在互連網營銷大行其道的今天，M站也越來越重要。營銷活動大多以H5頁面的形式展示和傳播。通過M站的營銷和推廣，從而又促進APP的使用和推廣。

 

目前，移動M站有傾向APP的趨勢。M站會越來越像個APP，使得M站也越來越重要。而且，很多APP的展示效果，在原生代碼無法實現的時候，嵌套移動H5頁面也是一個很好的選擇。

 

下面介紹幾個移動M站建設的要點：

 

151Degree

 

51Degrees號稱是目前最快、最準確的裝置檢測的解決方案。它是一個免費開源的.NET行動裝置 App開發組件，可以用來檢測行動裝置和瀏覽器。甚至可以擷取螢幕尺寸、IME、加上製造商和型號資訊等。從而可以選擇性地被定向到為行動裝置而設計的內容。由於擁有精確的行動裝置的資料，所以幾乎支援所有的智能手機，平板電腦等行動裝置。

 

其實說白了，51Degree的作用就是識別用戶端的裝置。PC瀏覽器訪問，就跳轉到PC站，手機瀏覽器訪問就跳轉到M站。從而達到更好的使用者體驗。

 

如何將51Degree加入到現有網站？

• http://51degrees.codeplex.com/wikipage？title=Enhance%20existing%20web%20site

 

2架構

 

移動Web和傳統的Web其實並沒有本質的區別。說白了還是一個Web網站，使用的技術都是Html+CSS+JS。不同的是，只不過目前在Html5的大趨勢下，將Html5加入到了移動M站，使得M站更像個輕APP。

 

 

3Bootstrap

 

Bootstrap就不多說了，網上有很多Bootstrap的資料。它最大的優勢應該就是非常流行，非常容易上手。如果缺少專業的設計或美工，那麼Bootstrap是一個比較好的選擇。他的用法極其簡單，幾乎沒什麼學習成本，絕對是快速開發的利器。

 

官網：http://getbootstrap.com/
Github：https://github.com/twbs/bootstrap/

 

4幾點建議

 

• 移動M站的URL要盡量和PC相同，這是可以避免同一URL在PC站可以顯示，但是在手機上開啟卻是404；

• M站寫單獨的TDK。

 

   

六、系統容量預估

  

 

電商公司的朋友，這樣的情境是否似曾相識：

 

運營和產品神秘兮兮的跑過來問：我們晚上要做搞個促銷，伺服器能抗得住嗎？如果扛不住，需要加多少台機器？

 

於是，技術一臉懵逼。

 

其實這些都是系統容量預估的問題，容量預估是架構師必備的技能之一。所謂，容量預估其實說白了就是系統在Down掉之前，所能承受的最大流量。這個是技術人員對於系統效能瞭解的重要指標。常見的容量評估包括流量、並發量、頻寬、CPU、記憶體 、磁碟等一系列內容。這部分來聊一聊容量預估的問題。

 

1幾個重要參數

 

• QPS：每秒鐘處理的請求數。

• 並發量： 系統同時處理的請求數。

• 回應時間：  一般取平均回應時間。

 

很多人經常會把並發數和QPS給混淆了。其實只要理解了上面三個要素的意義之後，就能推算出它們之間的關係：QPS = 並發量 / 平均回應時間。

 

2容量評估的步驟與方法

 

1）預估總訪問量

 

如何知道總訪問量？對於一個運營活動的訪問量評估，或者一個系統上線後PV的評估，有什麼好方法？

 

最簡單的辦法就是：詢問業務方，詢問運營同學，詢問產品同學，看產品和運營對此次活動的流量預估。

 

不過，業務方對於流量的預估，應該就PV和使用者訪問數這兩個指標。技術人員需要根據這兩個資料，計算其他相關指標，比如QPS等。

 

2）預估平均QPS

 

• 總請求數=總PV*頁面衍生串連數

• 平均QPS = 總請求數/總時間

 

比如：活動落地頁1小時內的總訪問量是30w PV，該落地頁的衍生串連數為30，那麼落地頁的平均QPS=(30w*30)/(60*60)=2500。

 

3）預估峰值QPS

 

系統容量規劃時，不能只考慮平均QPS，還要考慮高峰的QPS，那麼如何評估峰值QPS呢？

 

這個要根據實際的業務評估，通過以往的一些營銷活動的PV等資料進行預估。一般情況下，峰值QPS大概是均值QPS的3-5倍，如果日均QPS為1000，於是評估出峰值QPS為5000。

 

不過，有一些業務會比較難評估業務訪問量，例如“秒殺業務”，這類業務的容量評估暫時不在此討論。

 

4）預估系統、單機極限QPS

 

如何預估一個業務，一個伺服器單機的極限QPS呢？

 

這個效能指標是伺服器最基本的指標之一，所以除了壓力測試沒有其他的辦法。通過壓力測試，算出伺服器的單機極限QPS 。

 

在一個業務上線前，一般都需要進行壓力測試（很多創業型公司，業務迭代很快的系統可能沒有這一步，那就悲劇了），以APP推送某營銷活動為例（預計日均QPS為1000，峰值QPS為5000），業務情境可能是這樣的：

 

• 通過APP推送一個活動訊息；

• 運營活動H5落地頁是一個Web網站；

• H5落地頁由緩衝Cache和資料庫DB中的資料拼裝而成。

 

通過壓力測試發現，Web伺服器單機只能抗住1200的QPS，Cache和資料庫DB能抗住並發壓力（一般來說，1%的流量到資料庫，資料庫120 QPS還是能輕鬆抗住的，Cache的話QPS能抗住，需要評估Cache的頻寬，這裡假設Cache不是瓶頸），這樣，我們就得到了Web單機極限的QPS是1200。一般來說，生產系統不會跑滿到極限的，這樣容易影響伺服器的壽命和效能，單機線上允許跑到QPS1200*0.8=960。

 

擴充說一句，通過壓力測試，已經知道Web層是瓶頸，則可針對Web相關的方面做一些調整最佳化，以提高Web伺服器的單機QPS 。

 

還有壓力測試工作中，一般是以具體業務的角度進行壓力測試，關心的是某個具體業務的並發量和QPS。

 

5）回答最開始那兩個問題　

　　　　

需要的機器=峰值QPS/單機極限QPS

 

好了，上述已經得到了峰值QPS是5000，單機極限QPS是1000，線上部署了3台伺服器：

• 伺服器能抗住嗎？ -> 峰值5000，單機1000，線上3台，扛不住

• 如果扛不住，需要加多少台機器？ -> 需要額外2台，提前預留1台更好，給3台保險

 

3總結

 

需要注意的是，以上都是計算單個伺服器或是單個叢集的容量。實際生產環境是由Web、訊息佇列、緩衝、資料庫等等一系列組成的複雜叢集。在分布式系統中，任何節點出現瓶頸，都有可能導致雪崩效應，最後導致整個叢集垮掉 （“雪崩效應”指的是系統中一個小問題會逐漸擴大，最後造成整個叢集宕機）。

 

所以，要瞭解規劃整個平台的容量，就必須計算出每一個節點的容量。找出任何可能出現的瓶頸所在。

 

   

七、緩衝系統

  

 

對於一個電商系統，緩衝是重要組成部分，而提升系統效能的主要方式之一也是緩衝。它可以擋掉大部分的資料庫訪問的衝擊，如果沒有它，系統很可能會因為資料庫不可用導致整個系統崩潰。

 

但緩衝帶來了另外一些棘手的問題： 資料的一致性和即時性。例如，資料庫中的資料狀態已經改變，但在頁面上看到的仍然是緩衝的舊值，直到緩衝時間失效之後，才能重新更新緩衝。這個問題怎麼解決？

 

還有就是快取資料如果沒有失效的話，是會一直保持在記憶體中的，對伺服器的記憶體也是負擔，那麼，什麼資料可以放緩衝，什麼資料不可以，這是系統設計之初必須考慮的問題。

 

什麼資料可以放緩衝？

 

• 不需要即時更新但是又極其消耗資料庫的資料。比如網站首頁的商品銷售的熱門排行榜，熱搜商品等等，這些資料基本上都是一天統計一次，使用者不會關注其是否是即時的。

• 需要即時更新，但是資料更新的頻率不高的資料。

• 每次擷取這些資料都經過複雜的處理邏輯，比如產生報表。

 

什麼資料不應該使用緩衝？

 

實際上，在電商系統中，大部分資料都是可以緩衝的，不能使用緩衝的資料很少。這類資料包括涉及到錢、密鑰、業務關鍵性核心資料等。總之，如果你發現，系統裡面的大部分資料都不能使用緩衝，這說明架構本身出了問題。

 

如何解決一致性和即時性的問題？

 

保證一致性和即時性的辦法就是：一旦資料庫更新了，就必須把原來的緩衝更新。

 

說一說我們的緩衝方案：我們目前的緩衝系統：Redis（主從）+ RabbitMQ + 緩衝清理服務組成，具體如：

 

緩衝清理作業訂閱RabbitMQ訊息佇列，一有資料更新進入隊列，就將資料重新更新到Redis快取服務器。

 

當然，有些朋友的方案，是資料庫更新完成之後，立馬去更新相關快取資料。這樣就不需要MQ和緩衝清理作業。不過，這同時也增加了系統的耦合性。具體得看自己的業務情境和平台大小。

原文地址：http://click.aliyun.com/m/21358/  

如何打造一個小而精的電商網站架構？