前面寫過一些電商網站相關的文章，這幾天有時間，就把之前寫得網站架構相關的文章，總結整理一下。把以前的一些內容就連貫起來，這樣也能系統的知道，一個最小的電商平臺是怎麼一步步搭建起來的。

本文大綱：

1. 小型電商網站的架構
2. 日志與監控系統的解決方案
3. 構建數據庫的主從架構
4. 基於共享存儲的圖片服務器架構
5. 移動M站建設
6. 系統容量預估
7. 緩存系統

一、小型電商網站的架構

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

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

1.技術架構

一般初期的電商網站，基本就幾個業務子系統：網站前臺、商傢前臺、系統管理後臺、App、M站等。業務量也不是很大。所以，MVC + 緩存 + 數據庫基本就搞定瞭。

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

2.基礎架構

5aba485fec54cfd0edbcdf4663dc49ab

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

前端網站和M站，考慮到訪問量和系統的可用性，基本會采用分佈式部署。通過代理服務器進行請求分發。

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

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

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

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

首先為什麼要讀寫分離？

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

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

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

d2bd10141f0020d1095198385e2e6499

讀寫分離的基本原理就是讓主數據庫處理事務性增、改、刪操作（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）。

8053d3f9b87bb7f6bd394d5c8239d91c

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站點（http://i1.abc.com）將該共享目錄通過Web站點發佈出去。這樣其它的應用就能訪問到相關圖片。

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