如果你經(jīng)歷過創(chuàng)業(yè)，經(jīng)歷過快速迭代業(yè)務(wù)，經(jīng)歷過用戶量不斷上漲，經(jīng)歷過訪問并發(fā)越來越大，你一定會遇到以下系統(tǒng)問題：

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

如果你沒有經(jīng)歷過，很可能是：

• 沒到這一步項目就死了
• 身在所謂的大公司，用著所謂先進(jìn)的架構(gòu)體系

創(chuàng)業(yè)初期遇到上述痛點，很容易想到“三個分離”的架構(gòu)優(yōu)化方案：

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

一、業(yè)務(wù)場景介紹

虛擬一個類似于“安居客”租房買房的業(yè)務(wù)場景，這個業(yè)務(wù)的數(shù)據(jù)有兩大來源：

• 用戶發(fā)布的數(shù)據(jù)
• 爬蟲從競對抓取來的數(shù)據(jù)

這個業(yè)務(wù)對應(yīng)的系統(tǒng)有兩類使用者：

• 普通用戶，瀏覽與發(fā)布數(shù)據(jù)，俗稱“前臺用戶”
• 后臺用戶，運(yùn)營與管理數(shù)據(jù)，俗稱“后臺用戶”

在一個創(chuàng)業(yè)公司，為了快速迭代，系統(tǒng)架構(gòu)如上：

• web層：前臺web，后臺web
• 任務(wù)層：抓取數(shù)據(jù)
• 數(shù)據(jù)層：存儲數(shù)據(jù)

二、數(shù)據(jù)耦合的問題

系統(tǒng)兩類數(shù)據(jù)源，一類是用戶發(fā)布的數(shù)據(jù)，一類是爬蟲抓取的數(shù)據(jù)，兩類數(shù)據(jù)的特點不一樣：

• 自有數(shù)據(jù)相對結(jié)構(gòu)化，變化少
• 抓取數(shù)據(jù)源很多，數(shù)據(jù)結(jié)構(gòu)變化快

如果將自有數(shù)據(jù)和抓取數(shù)據(jù)耦合在一個庫里，經(jīng)常出現(xiàn)的情況是：

• -> 抓取數(shù)據(jù)結(jié)構(gòu)變化
• -> 需要修改數(shù)據(jù)結(jié)構(gòu)
• -> 影響前臺用戶展現(xiàn)
• -> 經(jīng)常被動修改前臺用戶展現(xiàn)邏輯，配合抓取升級

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

優(yōu)化思路：前臺展現(xiàn)數(shù)據(jù)，后臺抓取數(shù)據(jù)分離，解耦。

如上圖所示：

• 前臺展現(xiàn)的穩(wěn)定數(shù)據(jù)，庫獨(dú)立
• 后臺抓取的多變數(shù)據(jù)，庫獨(dú)立
• 任務(wù)層新增一個異步轉(zhuǎn)換的任務(wù)

如此這般：

• 頻繁變化的抓取程序，以及抓取的異構(gòu)數(shù)據(jù)存儲，解耦
• 前臺數(shù)據(jù)與web都不需要被動配合升級
• 即使出現(xiàn)問題，前臺用戶的發(fā)布與展現(xiàn)都不影響

三、系統(tǒng)耦合的問題

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

用戶側(cè)，前臺訪問的特點是：

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

運(yùn)營側(cè)，后臺訪問的特點是：

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

前臺和后臺的模式與訪問需求都不一樣，但是，如果前臺與后臺混用同一套服務(wù)和結(jié)構(gòu)化數(shù)據(jù)，會導(dǎo)致：

• 后臺的低性能訪問，對前臺用戶產(chǎn)生巨大的影響，本質(zhì)還是耦合

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

優(yōu)化思路：冗余數(shù)據(jù)，前臺與后臺服務(wù)與數(shù)據(jù)分離，解耦。

如上圖所示：

• 前臺和后臺獨(dú)立服務(wù)與數(shù)據(jù)，解耦
• 如果出現(xiàn)問題，相互不影響

• 通過不同的技術(shù)方案，在不同容忍度，業(yè)務(wù)對系統(tǒng)要求不同的情況下，可以使用不同的技術(shù)棧來滿足各自的需求，如上圖，后臺使用ES或者h(yuǎn)ive在進(jìn)行數(shù)據(jù)存儲，用以滿足“售各種奇形怪狀的，大批量分頁的，查詢需求”

四、總結(jié)

創(chuàng)業(yè)初期，快速實施架構(gòu)優(yōu)化，提升性能的“三大分離”優(yōu)化利器：

• 動靜分離：能夠100倍以上的提升靜態(tài)頁面/資源的訪問速度
• 讀寫分離：能夠快速的線性擴(kuò)充數(shù)據(jù)庫的讀性能
• 前后分離：前臺與后臺的數(shù)據(jù)與訪問分離

【本文為51CTO專欄作者“58沈劍”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】

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