如果你經歷過快速迭代業務，經歷過用戶量不斷上漲，經歷過訪問并發越來越大，你一定會遇到以下系統問題：
- 用戶訪問頁面越來越慢
- 系統性能下降，數據庫扛不住，連接數經常打滿，最終數據庫掛掉，重啟后又快速掛掉
- 改了一個小地方，另外一個看似不相干的地方卻掛了，嚴重耦合
遇到上述痛點，經常使用“前臺與后臺分離”的架構優化方案。
業務早期，最常見的場景是什么？
虛擬一個類似于“AJK”租房買房的業務場景，這個業務的數據有兩大來源：
- 用戶發布的數據
- 爬蟲抓取來的數據
這個業務對應的系統有兩類使用者：
- 普通用戶，瀏覽與發布數據，俗稱“前臺用戶”
- 后臺用戶，運營與管理數據，俗稱“后臺用戶”
在創業公司，為了快速迭代，系統架構如上：
- web層：前臺web，后臺web
- 任務層：抓取數據
- 數據層：存儲數據
上述架構方案，存在什么問題？
系統兩類數據源，一類是用戶發布的數據，一類是爬蟲抓取的數據，兩類數據的特點不一樣：
- 自有數據相對結構化，變化少
- 抓取數據源很多，數據結構變化快
如果將自有數據和抓取數據耦合在一個庫里，經常出現的情況是：
- 抓取數據結構變化
- 需要修改數據結構
- 影響前臺用戶展現
- 經常被動修改前臺用戶展現邏輯，配合抓取升級
如果經歷過這個過程，其中的痛不欲生，是誰都不愿意再次回憶起的。
耦合的根本原因，是數據層的耦合。
應該怎么優化？
優化思路：前臺展現數據，后臺抓取數據分離，解耦。
如上圖所示：
- 前臺展現的穩定數據，庫獨立
- 后臺抓取的多變數據，庫獨立
- 任務層新增一個異步轉換的任務
如此這般：
- 頻繁變化的抓取程序，以及抓取的異構數據存儲，解耦
- 前臺數據與web都不需要被動配合升級
- 即使出現問題，前臺用戶的發布與展現都不影響
有些朋友說，自己使用的是“微服務架構”，數據庫為服務私有，不存在數據耦合。你以為微服務架構，就沒有問題了嗎？
微服務架構，服務耦合的新問題是什么？
上面解決了不同數據源寫入的耦合問題，再來看看前臺與后臺用戶訪問的耦合問題。
用戶側，前臺訪問的特點是：
- 訪問模式有限
- 訪問量較大，DAU不達到百萬都不好意思說是互聯網C端產品
- 對訪問時延敏感，用戶如果訪問慢，立馬就流失了
- 對服務可用性要求高，系統經常用不了，用戶還會再來么
- 對數據一致性的要求高，關乎用戶體驗的事情就是大事
運營側，后臺訪問的特點是：
- 訪問模式多種多樣，運營銷售各種奇形怪狀的需求，大批量分頁的，模糊搜索的
- 用戶量小，訪問量小
- 訪問延時不這么敏感，大批量分頁，幾十秒能出結果，也能接受
- 對可用性能容忍，系統掛了，10分鐘之內重啟能回復，也能接受
- 對一致性的要求始終，晚個30秒的數據，也能接受
前臺和后臺的模式與訪問需求都不一樣，但是，如果前臺與后臺混用同一套服務和結構化數據，會導致：
- 后臺的低性能訪問，對前臺用戶產生巨大的影響，本質還是耦合
- 隨著數據量變大，為了保證前臺用戶的時延，質量，做一些類似與分庫分表的升級，數據庫一旦變化，可能很多后臺的需求難以滿足
耦合的根本原因，是服務層的耦合。
應該怎么優化？
優化思路：冗余數據，前臺與后臺服務與數據分離，解耦。
如上圖所示：
- 前臺和后臺獨立服務與數據，解耦
- 如果出現問題，相互不影響
- 通過不同的技術方案，在不同容忍度，業務對系統要求不同的情況下，可以使用不同的技術棧來滿足各自的需求，如上圖，后臺使用ES或者hive在進行數據存儲，用以滿足“售各種奇形怪狀的，大批量分頁的，查詢需求”
小結
- 創業早期，可能存在數據耦合，需要進行前臺與后臺分離，數據解耦
- 微服務架構，可能存在服務耦合，需要進行前臺與后臺分離，服務解耦
“前臺與后臺分離”的架構設計方案，是最常見的解耦與優化方案之一。
