[我的項目]電商價格監控——項目介紹和架構演變

前言

文章介紹並整理了一直在維護的一個小項目：京東價格監控，並詳細整理了該項目前先後後幾回重構的技術選型，做爲一篇總結。

網站介紹

在京東購物時，你是否遇到以下狀況：

• 心儀的商品降價了，你卻一無所知，等發現後早已斷貨。
• 你設置了京東自帶的降價提醒，結果在降價後好久才收到郵件提醒或者乾脆沒有提醒，錯失搶購良機。
• 網上各類折扣信息，各類折扣網站，卻老是不能選擇關注指定商品
• 想買手機/電腦/耳機等類別商品，想知道整個京東上手機/電腦/耳機類目實時折扣力度最大的商品。

如今，一個基於python爬蟲的實時價格監控網站上線了，你要作的僅僅是打開瀏覽器，輸入：

pricemonitor.online
複製代碼

網站功能

一：自定義商品監控

設置商品ID（京東商品編號）和您的預期價格，當商品價格【低於】設定的預期價格後自動發送郵件提醒用戶。

二：品類商品訂閱

用戶訂閱某品類後（例如數碼大類），該類全部商品中降價幅度大於7折的【自營商品】會被選出併發送郵件提醒用戶。

網站架構演變

小白期：Flask+HTML模板+Python腳本

2017年，我當時入門Python語言，學着一步步寫網頁爬蟲，後來接觸到了Python後臺開發，以後便萌生了作一個與爬蟲結合的先後端項目做爲練手，最後想到的就是電商商品的爬取。

可是，就算在幾年前，信息整合的網站就已經很是多了。國內的商品優惠信息整合網站大可能是以什麼值得買、惠惠購物助手等信息流推薦+商品歷史價格查看這種方式運營。想要作到有本身的特點，就必須作點不同的。

因而我決定將爬蟲做爲監控手段，監控商品的實時價格。

實際上，拿京東舉例，京東在當時就已經有了本身的降價提醒，但實際效果並很差，主要問題出在時效性上。用自營商品設置價格提醒後，在京東秒殺時不提醒，在正常顯示價格調整後每每在3.4個小時後才能收到提醒郵件。

因而，我從單個商品的監控下手，開始了這個小項目（與其說是項目，不如說僅僅是一個小腳本）。

網站需求很簡單，整個一代目架構總結以下：

爬蟲組件：就是個簡單的Python腳本，加上了定時循環。

數據庫：採用了最輕量的Sqlite，不須要客戶端和服務，單文件保存。

Web端：後臺我採用了網上推薦的Flask，前端只套用了HTML模板。 Flask中，涉及到使用Flask-Admin，Flask-Login，Flask-SQLAlchemy，Flask-WTF等組件，搭建了用戶註冊登陸系統。

爬蟲開源：github.com/qqxx6661/Pr…

Flask+HTML開源：github.com/qqxx6661/fl…

從如今的眼光來看，相比於Python中的Django，我認爲Flask對於新上手後臺的小白來講，並不能稱得上是很好的入門框架。至於我爲何這麼認爲，這就涉及到Flask和Django的區別了，我摘抄一段答案在這裏：

Flask

• Flask與關係型數據庫的配合使用不弱於Django，而其與NoSQL數據庫的配合遠遠優於Django
• 自由、靈活，可擴展性強，開發時能夠結合本身最喜歡用的第三方庫
• 適用於小型網站
• 適用於開發web服務的API
• 開發大型網站無壓力，但代碼架構須要本身設計
• 各方面性能均等於或優於Django
• Flask比Django更加Pythonic，與Python的philosophy更加吻合

Django

• 過重了，靈活和自由度不夠高
• Django能開發小應用，但總會有「殺雞焉用牛刀」的感受
• Django自帶的Admin好評如潮
• Django的自帶ORM很是優秀
• Django自帶的模板引擎
• Django自帶ORM也使Django與關係型數據庫耦合度太高，若是想使用MongoDB等NoSQL數據，須要選取合適的第三方庫
• Django很是適合企業級網站的開發：快速、靠譜、穩定
• Django上手也比較容易，開發文檔詳細、完善，相關資料豐富
• Django目前支持Jinja等非官方模板引擎

我認爲對於小白來講，能夠先熟悉Django，我以爲：

• Flask其實和Spring（或者說Springboot）有殊途同歸之妙，二者依靠官方的第一方庫和網絡上的第三方庫，來構建一個完整的系統。對於新手來講，跟着教程上手，很容易在各類庫的組裝中迷失了本身，各類兼容衝突，各類版本匹配，都會讓新手摸不到頭腦。我也深受其害，兩個月以後我再拾起代碼，對於以前是如何將各個庫進行整合的，忘得一乾二淨。
• Django雖然重，但勝在能讓小白對各個系統（管理後臺，用戶系統，登陸註冊，郵箱驗證，數據庫ORM等）都有直觀且實際的概念，知道各個系統在一個web項目中應該發揮的做用。

若是讓我推薦純小白開始學Python後臺開發，我會建議他從Django開始，在深刻去了解Flask。

說回個人網站，網站初步上線後，我在本身的博客上還有Github上作了些宣傳。陸續天天都有幾我的來訪問個人網站，也有在Github上提Issue提建議的。不得不說，正是這些小事讓我看到了項目的活力，讓我也擁有了更大的編碼熱情。

但因爲學校的科研任務緊，這個項目在搭建好後，就進入了漫長的維護階段，在這個階段中，除了幾回爬蟲規則的從新設計外，並無其餘業務上的改進。

過渡期：Django+Bootstrap+Scrapy爬蟲框架+代理池

大概半年後，我從新拾了起來，此時已經有一百多個註冊用戶了，雖然天天的使用率並不高，可是也足夠讓我知足了。本着學習技術的想法，我開始重構網站。

當時流行的比價插件（購物黨/惠惠比價）已經開始作商品的價格監控了，而且他們作的是瀏覽器插件，完美嵌入瀏覽器，更方便用戶使用，個人價格監控還須要獨立的網站進行商品登記，顯然已經out了。在這期間，我也萌生了品類監控的想法。

這一時期的主要改動有：

• 從Flask轉爲Django，前端使用Bootstrap代替原生HTML模板
• 採用Scrapy分佈式爬蟲框架爬取整個品類的商品
• 採用代理池提升總體採集效率

整個二代目架構總結以下：

爬蟲組件：從單一的Python腳本改成Scrapy框架爬取。

數據庫：使用Mysql做爲商品和用戶數據庫

Web端：Django，Django大而全，使用到了Django自帶的後臺管理，數據庫ORM，登陸驗證，Session，郵件等子模塊

穩按期：Springboot+React+Scrapy爬蟲框架+代理池+任務隊列

18年的秋招，對我來講試一次一場難忘的經歷，詳情能夠看個人秋招文章。秋招我主要是尋找Java後臺開發的工做，因此鑽研了一段時間的Spring，加之以前的實習經歷，開發過實際的SSM項目，對於後臺開發，尤爲是web後臺開發有了更加深入和廣闊的認識，。因而，我打算對電商監控網站進行第三次重構，固然，此次的重點主要是用Spring全家桶替代Django。

此外，爲了應用先後臺分離思想，我找了一個帥哥同窗幫我寫React前端，整個項目一會兒就有模有樣起來。

這一時期的主要改動有：

• 使用Springboot代替Django做爲後臺，向前端提供API
• 使用React做爲前端，接受JSON數據
• 改用任務隊列發送郵件
• 代理池支持免費代理，收費代理
• 免費代理使用Github明星開源項目：github.com/jhao104/pro…

整個三代目架構總結以下：

• web網站：Springboot提供接口+React前端頁面

  • Springboot（Api）+ Mysql（用戶數據）+ React（前端）
  • 表結構設計、Mybaits、Swagger二、Spring Security + JWT、Spring Cache、跨域、數據庫定時備份

• 爬蟲：Scrapy分佈式爬蟲框架

  • Requests/Selenium（爬取）、Mysql（商品信息）、Scrapy + Redis（分佈式爬蟲）
  • 反爬策略、IP代理、Scrapy自定義中間件、Headless Chrome網頁渲染

• 監控：Python腳本+Celery任務隊列

  • Supervisor（守護進程）、Crontab（定時監控腳本）、Celery任務隊列（提醒郵件）

將來

這個項目有不少的不足，我也一邊編碼一邊總結。

如今個人TODO List：

• Docker化各個模塊
• 全局搜索
• QQ微信登陸
• 價格曲線
• 推廣連接
• 添加更多商品
• ...

時至今日，這個項目的兩個功能可能都能找到更好的替代產品，畢竟一我的的精力有限，沒法將全部想法都體如今程序上。可是這個項目我還會堅持下去，它已經成爲了我技術的試驗田，也成爲了我繼續學習的動力。

關注我

個人Csdn：

blog.csdn.net/qqxx6661

個人知乎：

www.zhihu.com/people/yang…

個人簡書：

www.jianshu.com/u/b5f225ca2…

個人我的公衆號：Rude3Knife