如何打造一個(gè)小而精的電商網(wǎng)站架構(gòu)？

時(shí)間：2022-08-06 02:57:01 | 來源：網(wǎng)站運(yùn)營

時(shí)間：2022-08-06 02:57:01 來源：網(wǎng)站運(yùn)營

本文大綱：

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

2. 日志與監(jiān)控系統(tǒng)的解決方案

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

4. 基于共享存儲(chǔ)的圖片服務(wù)器架構(gòu)

5. 移動(dòng)M站建設(shè)

6. 系統(tǒng)容量預(yù)估

7. 緩存系統(tǒng)



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



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

今天就來總結(jié)小型電商網(wǎng)站的架構(gòu)演進(jìn)。一套電商系統(tǒng)最初期的架構(gòu)，往往會(huì)采用一個(gè)比較典型的LAMP架構(gòu)，前端加上Apache/PHP，后端是MySQL。這個(gè)算是比較流行的。不過，目前還有一套.net的技術(shù)架構(gòu)，可能大家很少提到。很不幸，我就是在一個(gè).net平臺(tái)為基礎(chǔ)的電商公司。所以，今天也是要總結(jié).net 平臺(tái)的電商架構(gòu)。

1技術(shù)架構(gòu)

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

單就開發(fā)效率而言，.net MVC 的技術(shù)架構(gòu)不會(huì)比LAMP開發(fā)速度慢。所以，一些企業(yè)，為了快速推出自己的電商平臺(tái)，也會(huì)采用.net 架構(gòu)。

2基礎(chǔ)架構(gòu)

上圖為基礎(chǔ)架構(gòu)層面。這是一個(gè)很簡(jiǎn)單的基礎(chǔ)架構(gòu)。

• 前端網(wǎng)站和M站，考慮到訪問量和系統(tǒng)的可用性，基本會(huì)采用分布式部署。通過代理服務(wù)器進(jìn)行請(qǐng)求分發(fā)。
  
  
• 其它的業(yè)務(wù)子系統(tǒng)，像商家前臺(tái)和管理系統(tǒng)，基本上都是單機(jī)或是主從部署。
  
  
• 各個(gè)DB ，Redis 服務(wù)和文件和圖片服務(wù)，搜索引擎Solr服務(wù)等，采用主從部署。
  
  

3詳細(xì)架構(gòu)

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

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



二、日志與監(jiān)控系統(tǒng)的解決方案



監(jiān)控系統(tǒng)主要用于服務(wù)器集群的資源和性能監(jiān)控，以及應(yīng)用異常、性能監(jiān)控、日志管理等多維度的性能監(jiān)控分析。一個(gè)完善的監(jiān)控系統(tǒng)和日志系統(tǒng)對(duì)于一個(gè)系統(tǒng)的重要性不必多說?？傊挥袑?shí)時(shí)了解各系統(tǒng)的狀態(tài)，才能保證各系統(tǒng)的穩(wěn)定。

如上圖所示，監(jiān)控平臺(tái)監(jiān)控的范圍很廣，從服務(wù)器性能及資源，到應(yīng)用系統(tǒng)的監(jiān)控。每個(gè)公司都有特定的平臺(tái)統(tǒng)一監(jiān)控的需求及解決方案，但監(jiān)控平臺(tái)的任務(wù)和作用基本是一致的。

1日志

日志是監(jiān)視程序運(yùn)行的一種重要的方式，主要有兩個(gè)目的：1.bug的及時(shí)發(fā)現(xiàn)和定位；2.顯示程序運(yùn)行狀態(tài)。

正確詳細(xì)的日志記錄能夠快速的定位問題。同樣，通過查看日志，可以看出程序正在做什么，是不是按預(yù)期的設(shè)計(jì)在執(zhí)行，所以記錄下程序的運(yùn)行狀態(tài)是必要的。這里將日志分為兩種：1.異常日志；2.運(yùn)行日志。

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

日志記錄的幾個(gè)原則：

• 日志級(jí)別一定要區(qū)分清楚，哪些屬于error、warning、info等。
  
  
• 記錄錯(cuò)誤的位置。如果是分層系統(tǒng)，一定要在某個(gè)層統(tǒng)一處理，例如我們的MVC架構(gòu)，都是在各個(gè)Action中Catch異常并處理，而業(yè)務(wù)層和數(shù)據(jù)庫層這些地方的異常，都是Catch到異常后，往上一層拋。
  
  
• 日志信息清晰準(zhǔn)確有意義，日志盡量詳細(xì)點(diǎn)，以方便處理。應(yīng)該記錄相關(guān)系統(tǒng)、模塊、時(shí)間、操作人、堆棧信息等。方便后續(xù)處理。
  
  

2監(jiān)控

監(jiān)控系統(tǒng)是一個(gè)復(fù)雜的系統(tǒng)平臺(tái)，目前有很多的開源產(chǎn)品和平臺(tái)。不過我們平臺(tái)小，監(jiān)控任務(wù)和需求少，所以基本都是自己開發(fā)。主要有這五個(gè)方面：1.系統(tǒng)資源；2.服務(wù)器；3.服務(wù)；4.應(yīng)用異常；5.應(yīng)用性能。

具體的架構(gòu)圖如下：

1）系統(tǒng)資源監(jiān)控

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

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

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

3）服務(wù)監(jiān)控

服務(wù)監(jiān)控，指的是各個(gè)Web服務(wù)、圖片服務(wù)、搜索引擎服務(wù)、緩存服務(wù)等平臺(tái)系統(tǒng)的各項(xiàng)服務(wù)是否正常運(yùn)行。可以通過定時(shí)服務(wù)，每隔一段時(shí)間，就去請(qǐng)求相關(guān)的服務(wù)，以確保平臺(tái)的各項(xiàng)服務(wù)正常運(yùn)行。

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

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

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

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



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



發(fā)展到大型成熟的公司之后，主從架構(gòu)可能就有點(diǎn)落伍了，取而代之的是更加復(fù)雜的數(shù)據(jù)庫集群。但作為一個(gè)小型電商公司，數(shù)據(jù)庫的主從架構(gòu)應(yīng)該是最基礎(chǔ)的。任何大型的系統(tǒng)架構(gòu)，都是不斷演進(jìn)的。主從架構(gòu)便是數(shù)據(jù)庫架構(gòu)中最基礎(chǔ)的架構(gòu)。所以研究完主從架構(gòu)，也就能看懂更加復(fù)雜的架構(gòu)了。

首先為什么要讀寫分離？

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

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

• 將讀操作和寫操作分離到不同的數(shù)據(jù)庫上，避免主服務(wù)器出現(xiàn)性能瓶頸；
  
  
• 主服務(wù)器進(jìn)行寫操作時(shí)，不影響查詢應(yīng)用服務(wù)器的查詢性能，降低阻塞，提高并發(fā)；
  
  
• 數(shù)據(jù)擁有多個(gè)容災(zāi)副本，提高數(shù)據(jù)安全性，同時(shí)當(dāng)主服務(wù)器故障時(shí)，可立即切換到其他服務(wù)器，提高系統(tǒng)可用性。
  
  

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

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

1SQL Server 讀寫分離的配置

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

• 日志傳送：SQL Server 2008 R2 主從數(shù)據(jù)庫同步
  
  （鏈接：http://www.it165.net/database/html/201306/4088.html）
  
  
• 事務(wù)復(fù)制：SQL Server 復(fù)制：事務(wù)發(fā)布
  
  （鏈接：SQL Server 復(fù)制：事務(wù)發(fā)布）
  
  

（圖源：網(wǎng)絡(luò)）

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

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

最簡(jiǎn)單的就是：配置兩個(gè)數(shù)據(jù)庫連接，然后在各個(gè)數(shù)據(jù)庫調(diào)用的位置，區(qū)分讀寫請(qǐng)求相應(yīng)的數(shù)據(jù)庫服務(wù)器，如下圖：　

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

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

（PS：此Demo為本人總結(jié)，跟實(shí)際生產(chǎn)中的DLL 不太相同，但原理是一樣的，大家總結(jié)封裝吧）

同時(shí)，增加相關(guān)的數(shù)據(jù)庫配置



四、基于共享存儲(chǔ)的圖片服務(wù)器架構(gòu)



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

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

事實(shí)是：第一，大型牛逼的系統(tǒng)我也不會(huì)；第二， 再牛逼的系統(tǒng)也是從小的架構(gòu)演化過去的，沒有一步到位的。這里介紹圖片服務(wù)器架構(gòu)雖然比較簡(jiǎn)單，但也是經(jīng)過了單機(jī)時(shí)代的演化了，基本上可以滿足中小型分布式網(wǎng)站的需求。這種架構(gòu)的搭建和學(xué)習(xí)成本都極低，符合目前“短平快”的開發(fā)模式。

通過共享目錄的方式實(shí)現(xiàn)共享存儲(chǔ) ，在共享目錄文件服務(wù)器上配置獨(dú)立域名，這樣可以將圖片服務(wù)器和應(yīng)用服務(wù)器進(jìn)行分離，來實(shí)現(xiàn)獨(dú)立圖片服務(wù)器。

優(yōu)點(diǎn)：

1. 將圖片服務(wù)和應(yīng)用服務(wù)分離，緩解應(yīng)用服務(wù)器的I/O負(fù)載。

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

3. 相對(duì)來講很靈活，也支持?jǐn)U容/擴(kuò)展。支持配置成獨(dú)立圖片服務(wù)器和域名訪問，方便日后的擴(kuò)展和優(yōu)化。

4. 相對(duì)于更加復(fù)雜的分布式的NFS系統(tǒng)，這種方式是性價(jià)比高，符合目前互聯(lián)網(wǎng)的“短平快”的開發(fā)模式。

缺點(diǎn) ：

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

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

3. 如果圖片服務(wù)器出現(xiàn)問題，那所有的應(yīng)用都會(huì)受到影響。同時(shí)也對(duì)存儲(chǔ)服務(wù)器的性能要求特別高。

4. 圖片上傳操作，還是得經(jīng)過Web服務(wù)器，這對(duì)Web服務(wù)器還是有巨大的壓力。

架構(gòu)非常簡(jiǎn)單，基本架構(gòu)如下圖所示：

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

各個(gè)應(yīng)用直接通過共享目錄（//192.168.1.200），將圖片上傳到存儲(chǔ)服務(wù)器上。

建立一個(gè)Web站點(diǎn)（http://i1.abc.com）將該共享目錄通過Web站點(diǎn)發(fā)布出去。這樣其它的應(yīng)用就能訪問到相關(guān)圖片。

所以，各應(yīng)用將文件上傳到共享目錄

//保存原圖
//完整的地址：//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

五、移動(dòng)M站建設(shè)



最近在一直在搞M站，也就是移動(dòng)Web站點(diǎn)。由于是第一次，也遇到了很多問題，所以把最近了解到的東西總結(jié)一番。聊一聊什么是移動(dòng)M站，以及它有什么作用和優(yōu)勢(shì)。

有人會(huì)問，M站和APP有什么不同？

1. APP直接在用戶的移動(dòng)設(shè)備上，曝光率相對(duì)較高。 而M站需打開瀏覽器，輸入地址才能訪問，所以曝光率相對(duì)較低。
   
   
2. M站的推廣的渠道相比移動(dòng)APP，渠道較多，方便追蹤用戶來源、流量入口等，方便以后的活動(dòng)推廣和數(shù)據(jù)分析。
   
   
3. M站用戶無需安裝，輸入U(xiǎn)RL即可訪問，而APP需要下載安裝。
   
   
4. M站能夠快速地通過數(shù)據(jù)分析，能快速得到用戶的反饋，從而更容易根據(jù)統(tǒng)計(jì)數(shù)據(jù)分析和用戶的需求來調(diào)整產(chǎn)品。
   
   
5. APP對(duì)用戶更具粘性及用戶體驗(yàn)也更好。
   
   
6. M站對(duì)于營銷推廣活動(dòng)非常方便，轉(zhuǎn)發(fā)分享方便快捷。
   
   
7. M站更新迭代產(chǎn)品速度和響應(yīng)產(chǎn)品調(diào)整非?？?，隨時(shí)發(fā)布，而APP需要審核時(shí)間。
   
   
8. M站跨平臺(tái)，無需開發(fā)安卓和iOS版，只需有瀏覽器即可。
   
   

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

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

下面介紹幾個(gè)移動(dòng)M站建設(shè)的要點(diǎn)：

151Degree

51Degrees號(hào)稱是目前最快、最準(zhǔn)確的設(shè)備檢測(cè)的解決方案。它是一個(gè)免費(fèi)開源的.NET移動(dòng)應(yīng)用開發(fā)組件，可以用來檢測(cè)移動(dòng)設(shè)備和瀏覽器。甚至可以獲取屏幕尺寸、輸入法、加上制造商和型號(hào)信息等。從而可以選擇性地被定向到為移動(dòng)設(shè)備而設(shè)計(jì)的內(nèi)容。由于擁有精確的移動(dòng)設(shè)備的數(shù)據(jù)，所以幾乎支持所有的智能手機(jī)，平板電腦等移動(dòng)設(shè)備。

其實(shí)說白了，51Degree的作用就是識(shí)別客戶端的設(shè)備。PC瀏覽器訪問，就跳轉(zhuǎn)到PC站，手機(jī)瀏覽器訪問就跳轉(zhuǎn)到M站。從而達(dá)到更好的用戶體驗(yàn)。

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

http://51degrees.codeplex.com/wikipage？title=Enhance%20existing%20web%20site2架構(gòu)

移動(dòng)Web和傳統(tǒng)的Web其實(shí)并沒有本質(zhì)的區(qū)別。說白了還是一個(gè)Web站點(diǎn)，使用的技術(shù)都是Html+CSS+JS。不同的是，只不過目前在Html5的大趨勢(shì)下，將Html5加入到了移動(dòng)M站，使得M站更像個(gè)輕APP。

3Bootstrap

Bootstrap就不多說了，網(wǎng)上有很多Bootstrap的資料。它最大的優(yōu)勢(shì)應(yīng)該就是非常流行，非常容易上手。如果缺少專業(yè)的設(shè)計(jì)或美工，那么Bootstrap是一個(gè)比較好的選擇。他的用法極其簡(jiǎn)單，幾乎沒什么學(xué)習(xí)成本，絕對(duì)是快速開發(fā)的利器。

官網(wǎng)：Bootstrap · The world's most popular mobile-first and responsive front-end framework.
Github：twbs/bootstrap

4幾點(diǎn)建議

• 移動(dòng)M站的URL要盡量和PC相同，這是可以避免同一URL在PC站可以顯示，但是在手機(jī)上打開卻是404；
  
  
• M站寫單獨(dú)的TDK。
  
  

六、系統(tǒng)容量預(yù)估



電商公司的朋友，這樣的場(chǎng)景是否似曾相識(shí)：

運(yùn)營和產(chǎn)品神秘兮兮的跑過來問：我們晚上要做搞個(gè)促銷，服務(wù)器能抗得住么？如果扛不住，需要加多少臺(tái)機(jī)器？

于是，技術(shù)一臉懵逼。

其實(shí)這些都是系統(tǒng)容量預(yù)估的問題，容量預(yù)估是架構(gòu)師必備的技能之一。所謂，容量預(yù)估其實(shí)說白了就是系統(tǒng)在Down掉之前，所能承受的最大流量。這個(gè)是技術(shù)人員對(duì)于系統(tǒng)性能了解的重要指標(biāo)。常見的容量評(píng)估包括流量、并發(fā)量、帶寬、CPU、內(nèi)存 、磁盤等一系列內(nèi)容。這部分來聊一聊容量預(yù)估的問題。

1幾個(gè)重要參數(shù)

• QPS：每秒鐘處理的請(qǐng)求數(shù)。
  
  
• 并發(fā)量： 系統(tǒng)同時(shí)處理的請(qǐng)求數(shù)。
  
  
• 響應(yīng)時(shí)間： 一般取平均響應(yīng)時(shí)間。
  
  

很多人經(jīng)常會(huì)把并發(fā)數(shù)和QPS給混淆了。其實(shí)只要理解了上面三個(gè)要素的意義之后，就能推算出它們之間的關(guān)系：QPS = 并發(fā)量 / 平均響應(yīng)時(shí)間。

2容量評(píng)估的步驟與方法

1）預(yù)估總訪問量

如何知道總訪問量？對(duì)于一個(gè)運(yùn)營活動(dòng)的訪問量評(píng)估，或者一個(gè)系統(tǒng)上線后PV的評(píng)估，有什么好方法？

最簡(jiǎn)單的辦法就是：詢問業(yè)務(wù)方，詢問運(yùn)營同學(xué)，詢問產(chǎn)品同學(xué)，看產(chǎn)品和運(yùn)營對(duì)此次活動(dòng)的流量預(yù)估。

不過，業(yè)務(wù)方對(duì)于流量的預(yù)估，應(yīng)該就PV和用戶訪問數(shù)這兩個(gè)指標(biāo)。技術(shù)人員需要根據(jù)這兩個(gè)數(shù)據(jù)，計(jì)算其他相關(guān)指標(biāo)，比如QPS等。

2）預(yù)估平均QPS

• 總請(qǐng)求數(shù)=總PV*頁面衍生連接數(shù)
  
  
• 平均QPS = 總請(qǐng)求數(shù)/總時(shí)間
  
  

比如：活動(dòng)落地頁1小時(shí)內(nèi)的總訪問量是30w PV，該落地頁的衍生連接數(shù)為30，那么落地頁的平均QPS=(30w*30)/(60*60)=2500。

3）預(yù)估峰值QPS

系統(tǒng)容量規(guī)劃時(shí)，不能只考慮平均QPS，還要考慮高峰的QPS，那么如何評(píng)估峰值QPS呢？

這個(gè)要根據(jù)實(shí)際的業(yè)務(wù)評(píng)估，通過以往的一些營銷活動(dòng)的PV等數(shù)據(jù)進(jìn)行預(yù)估。一般情況下，峰值QPS大概是均值QPS的3-5倍，如果日均QPS為1000，于是評(píng)估出峰值QPS為5000。

不過，有一些業(yè)務(wù)會(huì)比較難評(píng)估業(yè)務(wù)訪問量，例如“秒殺業(yè)務(wù)”，這類業(yè)務(wù)的容量評(píng)估暫時(shí)不在此討論。

4）預(yù)估系統(tǒng)、單機(jī)極限QPS

如何預(yù)估一個(gè)業(yè)務(wù)，一個(gè)服務(wù)器單機(jī)的極限QPS呢？

這個(gè)性能指標(biāo)是服務(wù)器最基本的指標(biāo)之一，所以除了壓力測(cè)試沒有其他的辦法。通過壓力測(cè)試，算出服務(wù)器的單機(jī)極限QPS 。

在一個(gè)業(yè)務(wù)上線前，一般都需要進(jìn)行壓力測(cè)試（很多創(chuàng)業(yè)型公司，業(yè)務(wù)迭代很快的系統(tǒng)可能沒有這一步，那就悲劇了），以APP推送某營銷活動(dòng)為例（預(yù)計(jì)日均QPS為1000，峰值QPS為5000），業(yè)務(wù)場(chǎng)景可能是這樣的：

• 通過APP推送一個(gè)活動(dòng)消息；
  
  
• 運(yùn)營活動(dòng)H5落地頁是一個(gè)Web站點(diǎn)；
  
  
• H5落地頁由緩存Cache和數(shù)據(jù)庫DB中的數(shù)據(jù)拼裝而成。
  
  

通過壓力測(cè)試發(fā)現(xiàn)，Web服務(wù)器單機(jī)只能抗住1200的QPS，Cache和數(shù)據(jù)庫DB能抗住并發(fā)壓力（一般來說，1%的流量到數(shù)據(jù)庫，數(shù)據(jù)庫120 QPS還是能輕松抗住的，Cache的話QPS能抗住，需要評(píng)估Cache的帶寬，這里假設(shè)Cache不是瓶頸），這樣，我們就得到了Web單機(jī)極限的QPS是1200。一般來說，生產(chǎn)系統(tǒng)不會(huì)跑滿到極限的，這樣容易影響服務(wù)器的壽命和性能，單機(jī)線上允許跑到QPS1200*0.8=960。

擴(kuò)展說一句，通過壓力測(cè)試，已經(jīng)知道Web層是瓶頸，則可針對(duì)Web相關(guān)的方面做一些調(diào)整優(yōu)化，以提高Web服務(wù)器的單機(jī)QPS 。

還有壓力測(cè)試工作中，一般是以具體業(yè)務(wù)的角度進(jìn)行壓力測(cè)試，關(guān)心的是某個(gè)具體業(yè)務(wù)的并發(fā)量和QPS。

5）回答最開始那兩個(gè)問題　

需要的機(jī)器=峰值QPS/單機(jī)極限QPS

好了，上述已經(jīng)得到了峰值QPS是5000，單機(jī)極限QPS是1000，線上部署了3臺(tái)服務(wù)器：

• 服務(wù)器能抗住么？ -> 峰值5000，單機(jī)1000，線上3臺(tái)，扛不住
  
  
• 如果扛不住，需要加多少臺(tái)機(jī)器？ -> 需要額外2臺(tái)，提前預(yù)留1臺(tái)更好，給3臺(tái)保險(xiǎn)
  
  

3總結(jié)

需要注意的是，以上都是計(jì)算單個(gè)服務(wù)器或是單個(gè)集群的容量。實(shí)際生產(chǎn)環(huán)境是由Web、消息隊(duì)列、緩存、數(shù)據(jù)庫等等一系列組成的復(fù)雜集群。在分布式系統(tǒng)中，任何節(jié)點(diǎn)出現(xiàn)瓶頸，都有可能導(dǎo)致雪崩效應(yīng)，最后導(dǎo)致整個(gè)集群垮掉 （“雪崩效應(yīng)”指的是系統(tǒng)中一個(gè)小問題會(huì)逐漸擴(kuò)大，最后造成整個(gè)集群宕機(jī)）。

所以，要了解規(guī)劃整個(gè)平臺(tái)的容量，就必須計(jì)算出每一個(gè)節(jié)點(diǎn)的容量。找出任何可能出現(xiàn)的瓶頸所在。



七、緩存系統(tǒng)



對(duì)于一個(gè)電商系統(tǒng)，緩存是重要組成部分，而提升系統(tǒng)性能的主要方式之一也是緩存。它可以擋掉大部分的數(shù)據(jù)庫訪問的沖擊，如果沒有它，系統(tǒng)很可能會(huì)因?yàn)閿?shù)據(jù)庫不可用導(dǎo)致整個(gè)系統(tǒng)崩潰。

但緩存帶來了另外一些棘手的問題： 數(shù)據(jù)的一致性和實(shí)時(shí)性。例如，數(shù)據(jù)庫中的數(shù)據(jù)狀態(tài)已經(jīng)改變，但在頁面上看到的仍然是緩存的舊值，直到緩沖時(shí)間失效之后，才能重新更新緩存。這個(gè)問題怎么解決？

還有就是緩存數(shù)據(jù)如果沒有失效的話，是會(huì)一直保持在內(nèi)存中的，對(duì)服務(wù)器的內(nèi)存也是負(fù)擔(dān)，那么，什么數(shù)據(jù)可以放緩存，什么數(shù)據(jù)不可以，這是系統(tǒng)設(shè)計(jì)之初必須考慮的問題。

什么數(shù)據(jù)可以放緩存？

• 不需要實(shí)時(shí)更新但是又極其消耗數(shù)據(jù)庫的數(shù)據(jù)。比如網(wǎng)站首頁的商品銷售的排行榜，熱搜商品等等，這些數(shù)據(jù)基本上都是一天統(tǒng)計(jì)一次，用戶不會(huì)關(guān)注其是否是實(shí)時(shí)的。
  
  
• 需要實(shí)時(shí)更新，但是數(shù)據(jù)更新的頻率不高的數(shù)據(jù)。
  
  
• 每次獲取這些數(shù)據(jù)都經(jīng)過復(fù)雜的處理邏輯，比如生成報(bào)表。
  
  

什么數(shù)據(jù)不應(yīng)該使用緩存？

實(shí)際上，在電商系統(tǒng)中，大部分?jǐn)?shù)據(jù)都是可以緩存的，不能使用緩存的數(shù)據(jù)很少。這類數(shù)據(jù)包括涉及到錢、密鑰、業(yè)務(wù)關(guān)鍵性核心數(shù)據(jù)等?？傊?，如果你發(fā)現(xiàn)，系統(tǒng)里面的大部分?jǐn)?shù)據(jù)都不能使用緩存，這說明架構(gòu)本身出了問題。

如何解決一致性和實(shí)時(shí)性的問題？

保證一致性和實(shí)時(shí)性的辦法就是：一旦數(shù)據(jù)庫更新了，就必須把原來的緩存更新。

說一說我們的緩存方案：我們目前的緩存系統(tǒng)：Redis（主從）+ RabbitMQ + 緩存清理服務(wù)組成，具體如下圖：

緩存清理作業(yè)訂閱RabbitMQ消息隊(duì)列，一有數(shù)據(jù)更新進(jìn)入隊(duì)列，就將數(shù)據(jù)重新更新到Redis緩存服務(wù)器。

當(dāng)然，有些朋友的方案，是數(shù)據(jù)庫更新完成之后，立馬去更新相關(guān)緩存數(shù)據(jù)。這樣就不需要MQ和緩存清理作業(yè)。不過，這同時(shí)也增加了系統(tǒng)的耦合性。具體得看自己的業(yè)務(wù)場(chǎng)景和平臺(tái)大小。

原文地址：如何打造一個(gè)小而精的電商網(wǎng)站架構(gòu)？