web服務端的架構演變

2021-07-03 19:58:24 字數 1373 閱讀 8685

最近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次。完全不用考慮併...