最近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。這個階段完了之後的架構圖如下：
第五階段：分布式時代