電子商務網(wǎng)站設計如何打造得又小又精

最新消息，日前，宜家的控股企業(yè)Interogo Holding AG斥資17億瑞典克朗(約1.90億美元)買入海恩斯莫里斯(H&M)集團0.6%的股份，并擁持有了后者0.3%的投票權。這是Interogo Holding AG第一次擁有快時尚企業(yè)的股份。

前面寫過一些電商網(wǎng)站相關的文章，這幾天有時間，就把之前寫得網(wǎng)站架構相關的文章，總結整理一下。把以前的一些內容就連貫起來，這樣也能軟件的知道，一個最小的電商網(wǎng)站是怎么一步步開發(fā)起來的。

本文大綱：

1.小型電商網(wǎng)站的架構

2.日志與監(jiān)控軟件的解決規(guī)劃

3.構建數(shù)據(jù)庫的主從架構

4.基于共享存儲的圖片服務器架構

5.無線M站創(chuàng)建

一、小型電商網(wǎng)站的架構

剛從傳統(tǒng)系統(tǒng)行業(yè)進入到電商公司時，覺得電商網(wǎng)站沒有什么技術含量，也沒有什么門檻，都是一些現(xiàn)有的東西堆積木似的堆出來罷了。然而，真正進入到這個行業(yè)之后，才發(fā)現(xiàn)并非如此。有人說過，好的架構，是演化出來的，電商網(wǎng)站的架構也是如此。現(xiàn)在好的電商網(wǎng)站，看似很復雜，很牛逼，其實也是從很小的架構，也是從沒什么技術含量開始的。所以，架構的演化過程，就是在技術團隊不斷追求極致的過程。

今日就來總結小型電商網(wǎng)站的架構演進。一套電商軟件最初期的架構，往往會采用一個比較典型的LAMP架構，前端加上Apache/PHP，后端是MySQL。這個算是比較流行的。不過，目前還有一套.net的技術架構，可能大家很少提到。很不幸，我就是在一個.net網(wǎng)站為基礎的電商企業(yè)。所以，今日也是要總結.net網(wǎng)站的電商架構。

1技術架構

一般初期的電商網(wǎng)站，基本就幾個業(yè)務子軟件：網(wǎng)站前臺、商家前臺、軟件管理后臺、App、M站等。業(yè)務量也不是很大。所以，MVC+緩存+數(shù)據(jù)庫基本就搞定了。

單就搭建效率而言，.netMVC的技術架構不會比LAMP搭建速度慢。所以，一些公司，為了快速推出自己的電商網(wǎng)站，也會采用.net架構。

2基礎架構

1、前端網(wǎng)站和M站，考慮到訪問量和軟件的可用性，基本會采用分布式部署。通過加盟服務器進行請求分發(fā)。

2、其它的業(yè)務子軟件，像商家前臺和管理軟件，基本上都是單機或是主從部署。

3、各個DB，Redis服務和文件和圖片服務，搜索引擎Solr服務等，采用主從部署。

3詳細架構

整個軟件架構里面，還有一個比較重要的組成部分，那就是監(jiān)控軟件。例如：流量監(jiān)控、硬件監(jiān)控、軟件性能監(jiān)控等， 還有就是對某個頁面進行監(jiān)控，設置頁面的其中一塊進行監(jiān)控等。它是提高整個網(wǎng)站可用性的一個重要手段。多網(wǎng)站、多個維度的監(jiān)控，能夠確保軟件的可用性。一旦出現(xiàn)異常，特別在硬件或者性能方面出現(xiàn)異常，監(jiān)控軟件也能立刻發(fā)出警告，這樣也好防范于未然。

總而言之，一個好的軟件架構應該從擴展性、安全性、性能和可靠性來考慮。羅馬不是一天建成的，架構適合就行，可以先行之而后優(yōu)。通過漸進演化的過程，逐步讓軟件越來越完善。

二、日志與監(jiān)控軟件的解決規(guī)劃

監(jiān)控軟件主要用于服務器集群的資源和性能監(jiān)控，以及應用異常、性能監(jiān)控、日志管理等多維度的性能監(jiān)控分析。一個完善的監(jiān)控軟件和日志軟件對于一個軟件的重要性不必多說?？傊?，只有實時了解各軟件的狀態(tài)，才能保證各軟件的穩(wěn)定。

監(jiān)控網(wǎng)站監(jiān)控的范圍很廣，從服務器性能及資源，到應用軟件的監(jiān)控。每個企業(yè)都有特定的網(wǎng)站統(tǒng)一監(jiān)控的需要及解決規(guī)劃，但監(jiān)控網(wǎng)站的任務和作用基本是一致的。

1日志

日志是監(jiān)視程序運行的一種重要的方式，主要有兩個目的：

1.bug的及時發(fā)現(xiàn)和定位；

2.顯示程序運行狀態(tài)。

正確詳細的日志記錄能夠快速的定位問題。同樣，通過查看日志，可以看出程序正在干什么，是不是按預期的設計在執(zhí)行，所以記錄下程序的運行狀態(tài)是必要的。

這里將日志分為兩種：

1.異常日志；

2.運行日志。

咱們主要是操作log4net，將各個軟件的日志，持久化記錄到數(shù)據(jù)庫或者文件中，以方便后續(xù)的軟件異常監(jiān)控和性能分析。如何集成log4net，這里不多說。

日志記錄的幾個原則：

日志級別一定要區(qū)分清楚，哪些屬于error、warning、info等。

記錄錯誤的位置。如果是分層軟件，一定要在某個層統(tǒng)一處理，例如咱們的MVC架構，都是在各個Action中Catch異常并處理，而業(yè)務層和數(shù)據(jù)庫層這些地方的異常，都是Catch到異常后，往上一層拋。

日志信息清晰準確有意義，日志盡量詳細點，以方便處理。應該記錄相關軟件、模塊、時間、操作人、堆棧信息等。方便后續(xù)處理。

2監(jiān)控

監(jiān)控軟件是一個復雜的軟件網(wǎng)站，目前有很多的開源產品和網(wǎng)站。不過咱們網(wǎng)站小，監(jiān)控任務和需要少，所以基本都是自己搭建。

主要有這五個方面：

1.軟件資源；

2.服務器；

3.服務；

4.應用異常；

5.應用性能。

具體的架構如下：

1）軟件資源監(jiān)控

監(jiān)控各種網(wǎng)絡參數(shù)和各服務器相關資源（CPU、內存、磁盤讀寫、網(wǎng)絡、訪問請求等），保證服務器軟件的安全運營，并提供異常通知機制以讓軟件管理員快速定位/解決存在的各種問題。目前比較流行的應該是Zabbix。

2）服務器監(jiān)控

服務器的監(jiān)控，主要是監(jiān)控各個服務器、網(wǎng)絡節(jié)點、網(wǎng)關等網(wǎng)絡設備的請求響應是否正常。通過定時服務，定時去Ping各個網(wǎng)絡節(jié)點設備，以確認各網(wǎng)絡設備是否正常。如果哪個網(wǎng)絡設備出現(xiàn)異常，則發(fā)出消息提醒。

3）服務監(jiān)控

服務監(jiān)控，指的是各個Web服務、圖片服務、搜索引擎服務、緩存服務等網(wǎng)站軟件的各項服務是否正常運行。可以通過定時服務，每隔一段時間，就去請求相關的服務，以確保網(wǎng)站的各項服務正常運行。

4）應用異常監(jiān)控

目前咱們網(wǎng)站所有軟件的異常記錄，都記錄在數(shù)據(jù)庫中。通過定時服務，統(tǒng)計分析一段時間之內的異常記錄。如果發(fā)現(xiàn)有相關重要的模塊的軟件異常，比如支付、下單模塊頻繁發(fā)生異常，則立即通知相關人員處理，確保服務正常運行。

5）應用性能監(jiān)控

在API接口和各應用的相關位置進行攔截和記錄下程序性能（SQL性能，或是 程序執(zhí)行效率）。相關重要模塊提供性能預警，提前發(fā)現(xiàn)問題。同時統(tǒng)計相關監(jiān)控信息并顯示給搭建的人員，以方便后續(xù)的性能分析。

三、構建數(shù)據(jù)庫的主從架構

發(fā)展到大型成熟的企業(yè)之后，主從架構可能就有點落伍了，取而代之的是更加復雜的數(shù)據(jù)庫集群。但作為一個小型電商企業(yè)，數(shù)據(jù)庫的主從架構應該是最基礎的。任何大型的軟件架構，都是不斷演進的。主從架構便是數(shù)據(jù)庫架構中最基礎的架構。所以研究完主從架構，也就能看懂更加復雜的架構了。

首先為什么要讀寫分離？

對于一個小型網(wǎng)站，可能單臺數(shù)據(jù)庫服務器就能滿足需要。但在一些大型的網(wǎng)站或者應用中，單臺的數(shù)據(jù)庫服務器可能難以支撐大的訪問壓力，升級服務器性能投入又太高，所以必須要橫向擴展。還有就是，單庫的話，讀、寫都是操作一個數(shù)據(jù)庫。數(shù)據(jù)多了之后，對數(shù)據(jù)庫的讀、寫性能就會有很大影響。同時對于數(shù)據(jù)安全性和軟件的穩(wěn)定性也是挑戰(zhàn)。

數(shù)據(jù)庫的讀寫分離的好處？

1、將讀操作和寫操作分離到不同的數(shù)據(jù)庫上，避免主服務器出現(xiàn)性能瓶頸；

2、主服務器進行寫操作時，不影響查詢應用服務器的查詢性能，降低阻塞，提高并發(fā)；

3、數(shù)據(jù)擁有多個容災副本，提高數(shù)據(jù)安全性，同時當主服務器故障時，可立即切換到其他服務器，提高軟件可用性。

讀寫分離的基本原理就是讓主數(shù)據(jù)庫處理事務性增、改、刪操作（Insert、Update、Delete）操作，而從數(shù)據(jù)庫處理Select查詢操作。數(shù)據(jù)庫復制被用來把事務性操作導致的變更同步到其它從數(shù)據(jù)庫。

以SQL為例，主庫負責寫數(shù)據(jù)、讀數(shù)據(jù)。讀庫僅負責讀數(shù)據(jù)。每次有寫庫操作，同步更新到讀庫。寫庫就一個，讀庫可以有多個，采用日志同步的方式實現(xiàn)主庫和多個讀庫的數(shù)據(jù)同步。

1SQL Server 讀寫分離的配置

SQL Server提供了三種技術，可以用于主從架構之間的數(shù)據(jù)同步的實現(xiàn)：日志傳送、事務復制和SQL 2012 中新增的功能Always On 技術。各自優(yōu)劣，具體的大家自己去百度吧，這里提供網(wǎng)上的朋友的配置方式，僅供參考。

日志傳送：SQL Server 2008 R2 主從數(shù)據(jù)庫同步

事務復制：SQL Server 復制：事務發(fā)布

2C# 數(shù)據(jù)庫讀寫操作

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

最簡單的就是：配置兩個數(shù)據(jù)庫連接，然后在各個數(shù)據(jù)庫調用的位置，區(qū)分讀寫請求相應的數(shù)據(jù)庫服務器，如下圖：

第二種解決規(guī)劃就是判斷SQL語句是寫語句（Insert 、Update、Create、 Alter）還是讀語句（Select）。

同時，增加相關的數(shù)據(jù)庫配置。

四、基于共享存儲的圖片服務器架構

在當前這個互聯(lián)網(wǎng)的年代，不管何種網(wǎng)站，對圖片的需要量越來越大。尤其是電商網(wǎng)站，幾乎都會面臨到海量圖片資源的存儲、訪問等相關技術問題。在對圖片服務器的架構、擴展、升級的過程中，肯定也會碰到各種各樣的問題與需要。當然這并不典型，你就必須得弄一個特別NB的圖片服務架構，只要簡單、高效、穩(wěn)定就行。這部分咱們來總結一個特別簡單、高效的圖片服務架構：通過共享存儲的方式來實現(xiàn)圖片服務架構。

然而，也有一些人問我，現(xiàn)在大型網(wǎng)站的圖片服務器的架構已經完全不是這樣了，別人家的圖片軟件比你這個牛逼多了，為啥不直接寫那個呢？

事實是：第一，大型牛逼的軟件我也不會；第二， 再牛逼的軟件也是從小的架構演化過去的，沒有一步到位的。這里介紹圖片服務器架構雖然比較簡單，但也是經過了單機年代的演化了，基本上可以滿足中小型分布式網(wǎng)站的需要。這種架構的開發(fā)和學習投入都極低，符合目前“短平快”的搭建商業(yè)模式。

通過共享目錄的方式實現(xiàn)共享存儲 ，在共享目錄文件服務器上配置獨立域名，這樣可以將圖片服務器和應用服務器進行分離，來實現(xiàn)獨立圖片服務器。

優(yōu)勢：

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

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

3.相對來講很靈活，也支持擴容/擴展。支持配置成獨立圖片服務器和域名訪問，方便日后的擴展和優(yōu)化。

4.相對于更加復雜的分布式的NFS軟件，這種方式是性價比高，符合目前互聯(lián)網(wǎng)的“短平快”的搭建商業(yè)模式。

缺點 ：

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

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

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

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

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

 

在存儲服務器上建立一個共享目錄（具體方式，我就不去重復了，自己百度吧，注意共享目錄的文件安全）。

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

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

所以，各應用將文件上傳到共享目錄

 

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

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

五、無線M站創(chuàng)建

最近在一直在搞M站，也就是無線Web站點。由于是第一次，也遇到了很多問題，所以把最近了解到的東西總結一番。聊一聊什么是無線M站，以及它有什么作用和優(yōu)點。

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

APP直接在用戶的無線設備上，曝光率相對較高。 而M站需打開瀏覽器，輸入地址才能訪問，所以曝光率相對較低。

M站的推廣的渠道相比無線APP，渠道較多，方便追蹤用戶來源、流量入口等，方便以后的活動推廣和數(shù)據(jù)分析。

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

M站能夠快速地通過數(shù)據(jù)分析，能快速得到用戶的反饋，從而更容易根據(jù)統(tǒng)計數(shù)據(jù)分析和用戶的需要來調整產品。

APP對用戶更具粘性及用戶體驗也更好。

M站對于營銷推廣活動非常方便，轉發(fā)分享方便快捷。

M站更新迭代產品速度和響應產品調整非?？?，隨時發(fā)布，而APP需要審核時間。

M站跨網(wǎng)站，無需搭建安卓和iOS版，只需有瀏覽器即可。

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

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

下面介紹幾個無線M站創(chuàng)建的要點：

151Degree

51Degrees號稱是目前最快、最準確的設備檢測的解決規(guī)劃。它是一個免費開源的.NET無線應用搭建組件，可以用來檢測無線設備和瀏覽器。甚至可以獲取屏幕尺寸、輸入法、加上制造商和型號信息等。從而可以選擇性地被定向到為無線設備而設計的內容。由于擁有精確的無線設備的數(shù)據(jù)，所以幾乎支持所有的智能手機，平板電腦等無線設備。

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

如何將51Degree加入到現(xiàn)有網(wǎng)站？

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

2架構

無線Web和傳統(tǒng)的Web其實并沒有本質的區(qū)別。說白了還是一個Web站點，操作的技術都是Html+CSS+JS。不同的是，只不過目前在Html5的大趨勢下，將Html5加入到了無線M站，使得M站更像個輕APP。

3Bootstrap

Bootstrap就不多說了，網(wǎng)上有很多Bootstrap的資料。它最大的優(yōu)點應該就是非常流行，非常容易上手。如果缺少專業(yè)的設計或美工，那么Bootstrap是一個更好的選擇。他的用法極其簡單，幾乎沒什么學習投入，絕對是快速搭建的利器。

4幾點意見

1、無線M站的URL要盡量和PC相同，這是可以避免同一URL在PC站可以顯示，但是在手機上打開卻是404；

2、M站寫單獨的TDK。

<HiShop（westcoastpropertyservices.com）是國內知名公司級電商網(wǎng)站提供商，為公司級商家提供最佳的軟件搭建（多種商業(yè)模式電商網(wǎng)站開發(fā)：B2B/B2B2C/B2C/O2O/新零售等）、供應鏈軟件開發(fā)及電商行業(yè)解決規(guī)劃服務>

<本文由himall原創(chuàng)，商業(yè)轉載請聯(lián)系作者獲得授權，非商業(yè)轉載請標明：himall原創(chuàng)>