前後臺,爲什麼要分離.

在快速迭代的業務中,用戶量不斷上漲,訪問量併發越來越大,就會遇到如下的系統問題:

• 用戶訪問頁面越來越慢
• 系統性能下降,數據庫扛不住,連接數經常打滿,最終數據庫掛掉,重啓之後有快速掛掉.
• 改了一個小地方,另外一個看似不相干的地方卻掛掉了,嚴重耦合

遇到上述的問題我們經常使用"前後臺分離"的架構優化方案

在業務早期,最常見的場景

虛擬一個類似於“AJK”租房買房的業務場景，這個業務的數據有兩大來源：

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

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

• 普通用戶，瀏覽與發佈數據，俗稱“前臺用戶”
• 後臺用戶，運營與管理數據，俗稱“後臺用戶”
  
  在創業公司，爲了快速迭代，系統架構如上：
• web層：前臺web，後臺web
• 任務層：抓取數據
• 數據層：存儲數據

上述的框架方案有哪些問題?
系統兩類數據源,一類是用戶發佈的數據,一類是爬蟲抓取的數據,兩類數據的特點不一樣:

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

如果將兩者數據耦合在一個數據庫中,經常出現的情況有:

• 抓取數據結構變化
• 需要修改數據結構
• 影響前臺用戶展現
• 經常被動修改前臺用戶展現邏輯，配合抓取升級

所以我們可以從中察覺到,耦合的根部原因在於 數據層的耦合

優化的方案如下:
前臺展示數據,後臺抓取數據 分離,解耦.

上述的方案

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

此方案的優點(較於業務早期方案)

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

另一個方案就是微服務,數據庫爲服務私有,不存在數據耦合,但是真的就沒有問題嗎?
上面解決了不同數據源寫入的耦合問題，再來看看前臺與後臺用戶訪問的耦合問題。
用戶側，前臺訪問的特點是：

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

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

• 訪問模式多種多樣，運營銷售各種奇形怪狀的需求，大批量分頁的，模糊搜索的
• 用戶量小，訪問量小
• 訪問延時不這麼敏感，大批量分頁，幾十秒能出結果，也能接受
• 對可用性能容忍，系統掛了，10分鐘之內重啓能回覆，也能接受
• 對一致性的要求始終，晚個30秒的數據，也能接受
  
  前臺和後臺的模式與訪問需求都不一樣，但是，如果前臺與後臺混用同一套服務和結構化數據，會導致：
• 後臺的低性能訪問，對前臺用戶產生巨大的影響，本質還是耦合
  
• 隨着數據量變大，爲了保證前臺用戶的時延，質量，做一些類似與分庫分表的升級，數據庫一旦變化，可能很多後臺的需求難以滿足

此時的耦合的根本原因，是服務層的耦合。

服務層高耦合的解決方案:
優化思路：冗餘數據，前臺與後臺服務與數據分離，解耦。

如上圖所示：

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

小結

• 創業早期，可能存在數據耦合，需要進行前臺與後臺分離，數據解耦
• 微服務架構，可能存在服務耦合，需要進行前臺與後臺分離，服務解耦

“前臺與後臺分離”的架構設計方案，是最常見的解耦與優化方案之一。