百事設計出品
掃描關注網站建設微信公眾賬號

掃一掃微信二維碼

必備,前臺與後臺分離的架構實踐

百事網絡2019-03-05經驗之談

  創業項目優選 好項目來A5招商 ,點擊入駐!

  如果你經歷過創業,經歷過快速迭代業務,經歷過用戶量不斷上漲,經歷過訪問並發越來越大,你一定會遇到以下系統問題:

  用戶訪問頁面越來越慢

  系統性能下降,數據庫扛不住,連接數經常打滿,最終數據庫掛掉,重啟後又快速掛掉

  改瞭一個小地方,另外一個看似不相幹的地方卻掛瞭,嚴重耦合

  如果你沒有經歷過,很可能是:

  沒到這一步項目就死瞭

  身在所謂的大公司,用著所謂先進的架構體系

  創業初期遇到上述痛點,很容易想到“三個分離”的架構優化方案:

  動靜分離:能夠100倍以上的提升靜態頁面/資源的訪問速度,詳見《必備,動靜分離架構實踐》

  讀寫分離:能夠快速的線性擴充數據庫的讀性能,詳見《必備,讀寫分離架構實踐》

  前後分離:前臺與後臺的數據與訪問分離,也就是本文將要重點介紹的內容

  一、業務場景介紹

  虛擬一個類似於“安居客”租房買房的業務場景,這個業務的數據有兩大來源:

  用戶發佈的數據

  爬蟲從競對抓取來的數據

  這個業務對應的系統有兩類使用者:

  普通用戶,瀏覽與發佈數據,俗稱“前臺用戶”

  後臺用戶,運營與管理數據,俗稱“後臺用戶”

  

 

  在一個創業公司,為瞭快速迭代,系統架構如上:

  web層:前臺web,後臺web

  任務層:抓取數據

  數據層:存儲數據

  二、數據耦合的問題

  系統兩類數據源,一類是用戶發佈的數據,一類是爬蟲抓取的數據,兩類數據的特點不一樣:

  自有數據相對結構化,變化少

  抓取數據源很多,數據結構變化快

  如果將自有數據和抓取數據耦合在一個庫裡,經常出現的情況是:

  -> 抓取數據結構變化

  -> 需要修改數據結構

  -> 影響前臺用戶展現

  -> 經常被動修改前臺用戶展現邏輯,配合抓取升級

  如果經歷過這個過程,其中的痛不欲生,是誰都不願意再次回憶起的。

  優化思路:前臺展現數據,後臺抓取數據分離,解耦。

  

 

  如上圖所示:

  前臺展現的穩定數據,庫獨立

  後臺抓取的多變數據,庫獨立

  任務層新增一個異步轉換的任務

  如此這般:

  頻繁變化的抓取程序,以及抓取的異構數據存儲,解耦

  前臺數據與web都不需要被動配合升級

  即使出現問題,前臺用戶的發佈與展現都不影響

  三、系統耦合的問題

  上面解決瞭不同數據源寫入的耦合問題,再來看看前臺與後臺用戶訪問的耦合問題。

  用戶側,前臺訪問的特點是:

  訪問模式有限

  訪問量較大,DAU不達到百萬都不好意思說是互聯網C端產品

  對訪問時延敏感,用戶如果訪問慢,立馬就流失瞭

  對服務可用性要求高,系統經常用不瞭,用戶還會再來麼

  對數據一致性的要求高,關乎用戶體驗的事情就是大事

  運營側,後臺訪問的特點是:

  訪問模式多種多樣,運營銷售各種奇形怪狀的,大批量分頁的,查詢需求

  用戶量小,訪問量小

  訪問延時不這麼敏感,大批量分頁,幾十秒能出結果,也能接受

  對可用性能容忍,系統掛瞭,10分鐘之內重啟能回復,也能接受

  對一致性的要求始終,晚個30秒的數據,也能接受

  

 

  前臺和後臺的模式與訪問需求都不一樣,但是,如果前臺與後臺混用同一套服務和結構化數據,會導致:

  後臺的低性能訪問,對前臺用戶產生巨大的影響,本質還是耦合

  

 

  隨著數據量變大,為瞭保證前臺用戶的時延,質量,做一些類似與分庫分表的升級,數據庫一旦變化,可能很多後臺的需求難以滿足

  優化思路:冗餘數據,前臺與後臺服務與數據分離,解耦。

  

 

  如上圖所示:

  前臺和後臺獨立服務與數據,解耦

  如果出現問題,相互不影響

  

 

  通過不同的技術方案,在不同容忍度,業務對系統要求不同的情況下,可以使用不同的技術棧來滿足各自的需求,如上圖,後臺使用ES或者hive在進行數據存儲,用以滿足“售各種奇形怪狀的,大批量分頁的,查詢需求”

  四、總結

  創業初期,快速實施架構優化,提升性能的“三大分離”優化利器:

  動靜分離:能夠100倍以上的提升靜態頁面/資源的訪問速度

  讀寫分離:能夠快速的線性擴充數據庫的讀性能

  前後分離:前臺與後臺的數據與訪問分離

  【本文為51CTO專欄作者“58沈劍”原創稿件,轉載請聯系原作者】

文章关键词
百事網絡