如果你經曆過創業，經曆過快速疊代業務，經曆過使用者量不斷上漲，經曆過通路并發越來越大，你一定會遇到以下系統問題：
- 使用者通路頁面越來越慢
- 系統性能下降，資料庫扛不住，連接配接數經常打滿，最終資料庫挂掉，重新開機後又快速挂掉
- 改了一個小地方，另外一個看似不相幹的地方卻挂了，嚴重耦合
如果你沒有經曆過，很可能是：
- 沒到這一步項目就死了
- 身在所謂的大公司，用着所謂先進的架構體系
創業初期遇到上述痛點，很容易想到“三個分離”的架構優化方案：
- 動靜分離：能夠100倍以上的提升靜态頁面/資源的通路速度，詳見《必備，動靜分離架構實踐》
- 讀寫分離：能夠快速的線性擴充資料庫的讀性能，詳見《必備，讀寫分離架構實踐》
- 前後分離：前台與背景的資料與通路分離，也就是本文将要重點介紹的内容
一、業務場景介紹
虛拟一個類似于“安居客”租房買房的業務場景，這個業務的資料有兩大來源：
- 使用者釋出的資料
- 爬蟲從競對抓取來的資料
這個業務對應的系統有兩類使用者：
- 普通使用者，浏覽與釋出資料，俗稱“前台使用者”
- 背景使用者，營運與管理資料，俗稱“背景使用者”
在一個創業公司，為了快速疊代，系統架構如上：
- web層：前台web，背景web
- 任務層：抓取資料
- 資料層：存儲資料
二、資料耦合的問題
系統兩類資料源，一類是使用者釋出的資料，一類是爬蟲抓取的資料，兩類資料的特點不一樣：
- 自有資料相對結構化，變化少
- 抓取資料源很多，資料結構變化快
如果将自有資料和抓取資料耦合在一個庫裡，經常出現的情況是：
- -> 抓取資料結構變化
- -> 需要修改資料結構
- -> 影響前台使用者展現
- -> 經常被動修改前台使用者展現邏輯，配合抓取更新
如果經曆過這個過程，其中的痛不欲生，是誰都不願意再次回憶起的。
優化思路：前台展現資料，背景抓取資料分離，解耦。
如上圖所示：
- 前台展現的穩定資料，庫獨立
- 背景抓取的多變資料，庫獨立
- 任務層新增一個異步轉換的任務
如此這般：
頻繁變化的抓取程式，以及抓取的異構資料存儲，解耦
前台資料與web都不需要被動配合更新
即使出現問題，前台使用者的釋出與展現都不影響
三、系統耦合的問題
上面解決了不同資料源寫入的耦合問題，再來看看前台與背景使用者通路的耦合問題。
使用者側，前台通路的特點是：
- 通路模式有限
- 通路量較大，DAU不達到百萬都不好意思說是網際網路C端産品
- 對通路時延敏感，使用者如果通路慢，立馬就流失了
- 對服務可用性要求高，系統經常用不了，使用者還會再來麼
- 對資料一緻性的要求高，關乎使用者體驗的事情就是大事
營運側，背景通路的特點是：
通路模式多種多樣，營運銷售各種奇形怪狀的，大批量分頁的，查詢需求
使用者量小，通路量小
通路延時不這麼敏感，大批量分頁，幾十秒能出結果，也能接受
對可用性能容忍，系統挂了，10分鐘之内重新開機能回複，也能接受
對一緻性的要求始終，晚個30秒的資料，也能接受
前台和背景的模式與通路需求都不一樣，但是，如果前台與背景混用同一套服務和結構化資料，會導緻：
- 背景的低性能通路，對前台使用者産生巨大的影響，本質還是耦合
随着資料量變大，為了保證前台使用者的時延，品質，做一些類似與分庫分表的更新，資料庫一旦變化，可能很多背景的需求難以滿足
優化思路：備援資料，前台與背景服務與資料分離，解耦。
- 前台和背景獨立服務與資料，解耦
- 如果出現問題，互相不影響
- 通過不同的技術方案，在不同容忍度，業務對系統要求不同的情況下，可以使用不同的技術棧來滿足各自的需求，如上圖，背景使用ES或者hive在進行資料存儲，用以滿足“售各種奇形怪狀的，大批量分頁的，查詢需求”
四、總結
創業初期，快速實施架構優化，提升性能的“三大分離”優化利器：
- 動靜分離：能夠100倍以上的提升靜态頁面/資源的通路速度
- 讀寫分離：能夠快速的線性擴充資料庫的讀性能
- 前後分離：前台與背景的資料與通路分離
本文原計劃昨天釋出的，朋友做免費網際網路技術分享，轉了他一篇文章，不僅被罵得很慘，還取關了一大片，非常抱歉，也很遺憾。