此文已由作者肖凡授權網易雲社群釋出。

歡迎訪問網易雲社群，瞭解更多網易技術產品運營經驗。

最近Lofter專案碰到很多效能上的問題，特別是資料庫相關的，每次推送後，告警就會第一時間到來。這些問題隨著產品的不斷擴充套件，我想大家肯定都遇到過。目前我們解決效能問題一般都是兩種方法：一是加快取，減少資料庫壓力；二嘛，就是加伺服器了。如果產品的規模繼續迅速增長，我們應該怎麼做？靠增加伺服器肯定不能解決根本問題，應該從架構上著手考慮。今天整理下web服務端架構從簡單到複雜的一個演變過程，為今後Lofter的架構調整積累下經驗吧。

第一階段：web伺服器和資料庫分離

好吧，我們的產品肯定不在這個階段。。。這個大家都知道就不多說了，直接上圖：

第二階段：增加快取

一段時間之後我們發現我們的網站越來越慢，查詢原因，發現是資料庫的操作太頻繁，導致資料連線競爭激烈，所以響應變慢，這個時候自然的會想到使用資料快取,如redis、memcache等（最近lofter把memcache換成了nkv），減少對資料庫的訪問。另一方面，web伺服器的負載也越來越大，我們需要對靜態資源做快取，可以使用反向代理伺服器（通常的使用apache或nginx，lofter使用的是nginx）；有時需要對某些特定的請求做快取，比如lofter投放在網易163首頁的iframe，訪問量很大，也需要快取，使用的是varnish。加入了這些快取之後，架構變成如下：

第三階段：增加伺服器

這個階段和上個階段往往是同時進行的。需要注意的幾個問題是：1、負載均衡，這個一般使用apache或nginx的負載均衡方案；2、如何保持狀態資訊的同步，可選的方案有cookie或統一session伺服器等；3、如何保持資料快取資訊的同步，一般使用分散式快取，如前面提到的memcache等

Lofter目前正處於這個階段。這個階段完了之後，架構如下圖：

第四階段：資料庫分庫、分表、讀寫分離

隨著業務的不斷增長，最先達到瓶頸的往往都是資料庫，這個階段基本上都是在解決資料庫的效能問題。常用的方法就是：

1.先按業務邏輯分庫，把不同業務的表放在不同的資料庫中，降低資料庫壓力；

2.分庫之後發現數據庫的壓力又慢慢上去了，往往都是大表造成的，這時候需要對大表進行分表，將大表拆成若干個小表；

3.如果資料庫的讀寫比很高，通常還會考慮讀寫分離的方案

這個階段需要注意的問題主要有：分庫分表方案、資料如何路由、分散式事務如何處理等，大家可以參考淘寶的解決方案TDDL。這個階段完了之後的架構圖如下：

第五階段：分散式時代

網易雲免費體驗館，0成本體驗20+款雲產品！ 

更多網易技術、產品、運營經驗分享請點選。

相關文章：
【推薦】 淺談js拖拽