電商總結（八）如何打造一個小而精的電商網站架構

時間 2019-11-08

原文原文鏈接

前面寫過一些電商網站相關的文章，這幾天有時間，就把以前寫得網站架構相關的文章，總結整理一下。把之前的一些內容就連貫起來，這樣也能系統的知道，一個最小的電商平臺是怎麼一步步搭建起來的。對之前的文章感興趣的朋友能夠看這個，http://www.cnblogs.com/zhangweizhong/category/879056.htmlhtml

本文大綱：前端

1. 小型電商網站的架構git

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

3. 構建數據庫的主從架構web

4. 基於共享存儲的圖片服務器架構數據庫

5. 移動M站建設bootstrap

6. 系統容量預估後端

7. 緩存系統瀏覽器

1、小型電商網站的架構緩存

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

今天就來總結小型電商網站的架構演進。一套電商系統最初期的架構，每每會採用一個比較典型的LAMP架構，前端加上Apache/PHP，後端是MySQL。這個算是比較流行的。不過，目前還有一套.net的技術架構，可能你們不多提到。很不幸，我就是在一個.net平臺爲基礎的電商公司。因此，今天也是要總結.net 平臺的電商架構。

1技術架構

通常初期的電商網站，基本就幾個業務子系統：網站前臺、商家前臺、系統管理後臺、App、M站等。業務量也不是很大。因此，MVC + 緩存 + 數據庫基本就搞定了。

單就開發效率而言，.net MVC 的技術架構不會比LAMP開發速度慢。因此，一些企業，爲了快速推出本身的電商平臺，也會採用.net 架構。

2基礎架構

上圖爲基礎架構層面。這是一個很簡單的基礎架構。

前端網站和M站，考慮到訪問量和系統的可用性，基本會採用分佈式部署。經過代理服務器進行請求分發。
其它的業務子系統，像商家前臺和管理系統，基本上都是單機或是主從部署。
各個DB ，Redis 服務和文件和圖片服務，搜索引擎Solr服務等，採用主從部署。

3詳細架構

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

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

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

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

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

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性能，或是程序執行效率）。相關重要模塊提供性能預警，提早發現問題。同時統計相關監控信息並顯示給開發的人員，以方便後續的性能分析。

3、構建數據庫的主從架構

發展到大型成熟的公司以後，主從架構可能就有點落伍了，取而代之的是更加複雜的數據庫集羣。但做爲一個小型電商公司，數據庫的主從架構應該是最基礎的。任何大型的系統架構，都是不斷演進的。主從架構即是數據庫架構中最基礎的架構。因此研究完主從架構，也就能看懂更加複雜的架構了。

首先爲何要讀寫分離？

對於一個小型網站，可能單臺數據庫服務器就能知足需求。但在一些大型的網站或者應用中，單臺的數據庫服務器可能難以支撐大的訪問壓力，升級服務器性能成本又過高，因此必需要橫向擴展。還有就是，單庫的話，讀、寫都是操做一個數據庫。數據多了以後，對數據庫的讀、寫性能就會有很大影響。同時對於數據安全性和系統的穩定性也是挑戰。

數據庫的讀寫分離的好處？

將讀操做和寫操做分離到不一樣的數據庫上，避免主服務器出現性能瓶頸；
主服務器進行寫操做時，不影響查詢應用服務器的查詢性能，下降阻塞，提升併發；
數據擁有多個容災副本，提升數據安全性，同時當主服務器故障時，可當即切換到其餘服務器，提升系統可用性。

讀寫分離的基本原理就是讓主數據庫處理事務性增、改、刪操做（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 不太相同，但原理是同樣的，你們總結封裝吧）

同時，增長相關的數據庫配置

4、基於共享存儲的圖片服務器架構

在當前這個互聯網的時代，無論何種網站，對圖片的需求量愈來愈大。尤爲是電商網站，幾乎都會面臨到海量圖片資源的存儲、訪問等相關技術問題。在對圖片服務器的架構、擴展、升級的過程當中，確定也會碰到各類各樣的問題與需求。固然這並不表明，你就必須得弄一個特別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

5、移動M站建設

最近在一直在搞M站，也就是移動Web站點。因爲是第一次，也遇到了不少問題，因此把最近了解到的東西總結一番。聊一聊什麼是移動M站，以及它有什麼做用和優點。

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

APP直接在用戶的移動設備上，曝光率相對較高。而M站需打開瀏覽器，輸入地址才能訪問，因此曝光率相對較低。
M站的推廣的渠道相比移動APP，渠道較多，方便追蹤用戶來源、流量入口等，方便之後的活動推廣和數據分析。
M站用戶無需安裝，輸入URL便可訪問，而APP須要下載安裝。
M站可以快速地經過數據分析，能快速獲得用戶的反饋，從而更容易根據統計數據分析和用戶的需求來調整產品。
APP對用戶更具粘性及用戶體驗也更好。
M站對於營銷推廣活動很是方便，轉發分享方便快捷。
M站更新迭代產品速度和響應產品調整很是快，隨時發佈，而APP須要審覈時間。
M站跨平臺，無需開發安卓和iOS版，只需有瀏覽器便可。

因此，我以爲，M站和客戶端是相輔相成的。M站的及時性和快捷性，是APP沒法比擬的。而APP的用戶體驗，則是M站沒法作到的。目前來講二者是不可能被對方徹底替代的，在互聯網營銷大行其道的今天，M站也愈來愈重要。營銷活動大多以H5頁面的形式展現和傳播。經過M站的營銷和推廣，從而又促進APP的使用和推廣。

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

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

151Degree

51Degrees號稱是目前最快、最準確的設備檢測的解決方案。它是一個免費開源的.NET移動應用開發組件，能夠用來檢測移動設備和瀏覽器。甚至能夠獲取屏幕尺寸、輸入法、加上製造商和型號信息等。從而能夠選擇性地被定向到爲移動設備而設計的內容。因爲擁有精確的移動設備的數據，因此幾乎支持全部的智能手機，平板電腦等移動設備。

其實說白了，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。

6、系統容量預估

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

運營和產品神祕兮兮的跑過來問：咱們晚上要作搞個促銷，服務器能抗得住麼？若是扛不住，須要加多少臺機器？

因而，技術一臉懵逼。

其實這些都是系統容量預估的問題，容量預估是架構師必備的技能之一。所謂，容量預估其實說白了就是系統在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臺服務器：