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

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

如果你沒有經歷過，很可能是：

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

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

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

一、業務場景介紹

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

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

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

• 普通用戶，瀏覽與發布數據，俗稱“前臺用戶”
• 后臺用戶，運營與管理數據，俗稱“后臺用戶”

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

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

二、數據耦合的問題

系統兩類數據源，一類是用戶發布的數據，一類是爬蟲抓取的數據，兩類數據的特點不一樣：

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

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

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

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

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

如上圖所示：

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

如此這般：

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

三、系統耦合的問題

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

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

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

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

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

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

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

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

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

如上圖所示：

• 前臺和后臺獨立服務與數據，解耦
• 如果出現問題，相互不影響

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

四、總結

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

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

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

戳這里，看該作者更多好文