最近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.如果資料庫的讀寫比很高，通常還會考慮讀寫分離的方案
第五階段：分布式時代
web服務端的架構演變
此文已由作者肖凡授權網易雲社群發布。最近lofter專案碰到很多效能上的問題，特別是資料庫相關的，每次推送後，告警就會第一時間到來。這些問題隨著產品的不斷擴充套件，我想大家肯定都遇到過。目前我們解決效能問題一般都是兩種方法 一是加快取，減少資料庫壓力 二嘛，就是加伺服器了。如果產品的規模繼續迅速增長...
迷你web服務端
import re import socket from multiprocessing import process def handle client client skt 接收客戶端資料 recv data client skt.recv 1024 按照換行進行切割 request lines...
WEB應用服務架構的演變（掃盲）
1 一道面試題的背景引入 各位在面試的時候很容易會被問到，你們的系統是怎麼處理高併發的場景的？讓很多人頭疼不已，今天就給大家科普一下。2 先考慮乙個最簡單的系統架構 簡單的架構，單機部署,單資料庫。差不多每秒十次左右。此時假設你的系統使用者量總共就10萬左右。分攤到每一秒也就 10次。完全不用考慮併...