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

若是你經歷過創業，經歷過快速迭代業務，經歷過用戶量不斷上漲，經歷過訪問併發愈來愈大，你必定會遇到如下系統問題：

• 用戶訪問頁面愈來愈慢
• 系統性能降低，數據庫扛不住，鏈接數常常打滿，最終數據庫掛掉，重啓後又快速掛掉
• 改了一個小地方，另一個看似不相干的地方卻掛了，嚴重耦合

若是你沒有經歷過，極可能是：

• 沒到這一步項目就死了
• 身在所謂的大公司，用着所謂先進的架構體系

創業初期遇到上述痛點，很容易想到「三個分離」的架構優化方案：

• 動靜分離：可以100倍以上的提高靜態頁面/資源的訪問速度，詳見《必備，動靜分離架構實踐》
• 讀寫分離：可以快速的線性擴充數據庫的讀性能，詳見《必備，讀寫分離架構實踐》
• 先後分離：前臺與後臺的數據與訪問分離，也就是本文將要重點介紹的內容

1、業務場景介紹

虛擬一個相似於「安居客」租房買房的業務場景，這個業務的數據有兩大來源：

• 用戶發佈的數據
• 爬蟲從競對抓取來的數據

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

• 普通用戶，瀏覽與發佈數據，俗稱「前臺用戶」
• 後臺用戶，運營與管理數據，俗稱「後臺用戶」
  

在一個創業公司，爲了快速迭代，系統架構如上：

• web層：前臺web，後臺web
• 任務層：抓取數據
• 數據層：存儲數據

2、數據耦合的問題

系統兩類數據源，一類是用戶發佈的數據，一類是爬蟲抓取的數據，兩類數據的特色不同：

• 自有數據相對結構化，變化少
• 抓取數據源不少，數據結構變化快

若是將自有數據和抓取數據耦合在一個庫裏，常常出現的狀況是：

• -> 抓取數據結構變化
• -> 須要修改數據結構
• -> 影響前臺用戶展示
• -> 常常被動修改前臺用戶展示邏輯，配合抓取升級
  若是經歷過這個過程，其中的痛不欲生，是誰都不肯意再次回憶起的。

優化思路：前臺展示數據，後臺抓取數據分離，解耦。

如上圖所示：

• 前臺展示的穩定數據，庫獨立
• 後臺抓取的多變數據，庫獨立
• 任務層新增一個異步轉換的任務

如此這般：

• 頻繁變化的抓取程序，以及抓取的異構數據存儲，解耦
• 前臺數據與web都不須要被動配合升級
• 即便出現問題，前臺用戶的發佈與展示都不影響

3、系統耦合的問題

上面解決了不一樣數據源寫入的耦合問題，再來看看前臺與後臺用戶訪問的耦合問題。

用戶側，前臺訪問的特色是：

• 訪問模式有限
• 訪問量較大，DAU不達到百萬都很差意思說是互聯網C端產品
• 對訪問時延敏感，用戶若是訪問慢，立馬就流失了
• 對服務可用性要求高，系統常常用不了，用戶還會再來麼
• 對數據一致性的要求高，關乎用戶體驗的事情就是大事

運營側，後臺訪問的特色是：

• 訪問模式多種多樣，運營銷售各類奇形怪狀的，大批量分頁的，查詢需求
• 用戶量小，訪問量小
• 訪問延時不這麼敏感，大批量分頁，幾十秒能出結果，也能接受
• 對可用性能容忍，系統掛了，10分鐘以內重啓能回覆，也能接受
• 對一致性的要求始終，晚個30秒的數據，也能接受
  

前臺和後臺的模式與訪問需求都不同，可是，若是前臺與後臺混用同一套服務和結構化數據，會致使：

• 後臺的低性能訪問，對前臺用戶產生巨大的影響，本質仍是耦合
  
• 隨着數據量變大，爲了保證前臺用戶的時延，質量，作一些相似與分庫分表的升級，數據庫一旦變化，可能不少後臺的需求難以知足

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

如上圖所示：

• 前臺和後臺獨立服務與數據，解耦
• 若是出現問題，相互不影響
  
• 經過不一樣的技術方案，在不一樣容忍度，業務對系統要求不一樣的狀況下，可使用不一樣的技術棧來知足各自的需求，如上圖，後臺使用ES或者hive在進行數據存儲，用以知足「售各類奇形怪狀的，大批量分頁的，查詢需求」

4、總結

創業初期，快速實施架構優化，提高性能的「三大分離」優化利器：

• 動靜分離：可以100倍以上的提高靜態頁面/資源的訪問速度
• 讀寫分離：可以快速的線性擴充數據庫的讀性能
• 先後分離：前臺與後臺的數據與訪問分離

本文原計劃昨天發佈的，朋友作免費互聯網技術分享，轉了他一篇文章，不只被罵得很慘，還取關了一大片，很是抱歉，也很遺憾。

相關文章：
《必備，動靜分離架構實踐》
《必備，讀寫分離架構實踐》

另外一種先後端分離：
《先後端分離架構實踐》
《先後端分離的缺點》

技術人，謙虛一點，老是沒錯的。求幫轉。