具體以電子商務(wù)網(wǎng)站為例， 展示web應(yīng)用的架構(gòu)演變過程。

1.0時(shí)代

這個(gè)時(shí)候是一個(gè)web項(xiàng)目里包含了所有的模塊，一個(gè)數(shù)據(jù)庫里包含了所需要的所有表，這時(shí)候網(wǎng)站訪問量增加時(shí)，首先遇到瓶頸的是應(yīng)用服務(wù)器連接數(shù)，比如tomcat連接數(shù)不能無限增加，線程數(shù)上限受進(jìn)程內(nèi)存大小、CPU內(nèi)核數(shù)等因素影響，當(dāng)線程數(shù)到達(dá)一定數(shù)時(shí)候，線程上下文的切換對性能的損耗會越來越嚴(yán)重，響應(yīng)會變慢，通過增加web應(yīng)用服務(wù)器方式的橫向擴(kuò)展對架構(gòu)影響最小，這時(shí)候架構(gòu)會變成下面這樣：

2.0時(shí)代

這時(shí)候隨著網(wǎng)站訪問量繼續(xù)增加，繼續(xù)增加應(yīng)用服務(wù)器數(shù)量后發(fā)現(xiàn)數(shù)據(jù)庫成了瓶頸，而數(shù)據(jù)庫的最主要的瓶頸體現(xiàn)在兩方面：

• 數(shù)據(jù)庫的最大連接數(shù)是有限的，比如當(dāng)前數(shù)據(jù)庫的連接數(shù)設(shè)置8000，如果每個(gè)應(yīng)用服務(wù)器與數(shù)據(jù)庫的初始連接數(shù)設(shè)置40，那么200臺web服務(wù)器是極限， 并且連接數(shù)太多后，數(shù)據(jù)庫的讀寫壓力增大，耗時(shí)增加
• 當(dāng)單表數(shù)量過大時(shí)，對該表的操作耗時(shí)會增加，索引優(yōu)化也是緩兵之計(jì)

這時(shí)，根據(jù)業(yè)務(wù)特點(diǎn)，如果讀寫比差距不大，并且對數(shù)據(jù)一致性要求不是很高的情況下，數(shù)據(jù)庫可以采用主從方式進(jìn)行讀寫分離的方案，并且引入緩存機(jī)制來抗讀流量。如果讀寫比差距很大或者對數(shù)據(jù)一致性要求高時(shí)，就不適合用讀寫分離方案，需要考慮業(yè)務(wù)的垂直拆分，這時(shí)期的系統(tǒng)架構(gòu)圖如下：

3.0時(shí)代

3.1 讀寫分離

這時(shí)候仍然是垂直架構(gòu)，所有業(yè)務(wù)集中在一個(gè)項(xiàng)目里。項(xiàng)目維護(hù)、快速迭代問題會越來越嚴(yán)重，單個(gè)模塊的開發(fā)都需要發(fā)布整個(gè)項(xiàng)目，項(xiàng)目穩(wěn)定性也受到很大挑戰(zhàn)，這是需要考慮業(yè)務(wù)的垂直拆分，需要將一些大的模塊單獨(dú)拆出來，這時(shí)候的架構(gòu)圖如下：

4.0 業(yè)務(wù)垂直拆分

這時(shí)候?yàn)榱诉M(jìn)一步提升用戶體驗(yàn)，加速用戶的網(wǎng)站訪問速度，會使用CDN來緩存信息，用戶會訪問最近的CDN節(jié)點(diǎn)來提升訪問速度。此時(shí)的架構(gòu)圖如下：

4.1 使用CDN來緩存信息

隨著業(yè)務(wù)量增大，一些核心系統(tǒng)數(shù)據(jù)庫單表數(shù)量達(dá)到幾千萬甚至億級，這時(shí)候?qū)υ摫淼臄?shù)據(jù)操作效率會大大降低，并且雖然有緩存來抗讀的壓力，但是對于大量的寫操作和一些緩存miss的流量到達(dá)一定量時(shí)，單庫的負(fù)荷也會到達(dá)極限，這時(shí)候需要將表拆分，一般直接采用分庫分表，因?yàn)橹蛔龇直淼脑?，單個(gè)庫的連接瓶頸仍然無法解決。分庫分表后的架構(gòu)如下：

4.2分庫分表架構(gòu)

隨著流量的進(jìn)一步增大，這時(shí)候系統(tǒng)仍然會有瓶頸出現(xiàn)，以訂單系統(tǒng)為例：單個(gè)機(jī)房的機(jī)器是有限的，不能一直新增下去，并且基于容災(zāi)的考慮，一般采用同城雙機(jī)房的方式，機(jī)房之間用專線鏈接，同城跨機(jī)房質(zhì)檢的延時(shí)在幾毫秒，此時(shí)的架構(gòu)圖如下：

4.3 同城雙機(jī)房

由于數(shù)據(jù)庫主庫只能是在一個(gè)機(jī)房，所以仍然會有一半的數(shù)據(jù)庫訪問是跨機(jī)房的，雖然延時(shí)只有幾毫秒，但是一個(gè)調(diào)用鏈里的數(shù)據(jù)庫訪問太多后，這個(gè)延時(shí)也會積少成多。其次這個(gè)架構(gòu)還是沒能解決數(shù)據(jù)庫連接數(shù)瓶頸問題

• 隨著應(yīng)用服務(wù)器的增加，雖然是分庫分表，但每增加一臺應(yīng)用服務(wù)器，都會與每個(gè)分庫建立連接，比如數(shù)據(jù)庫連接池默認(rèn)連接數(shù)是40，而如果mysql數(shù)據(jù)庫的最大連接數(shù)是8000的話，那么200臺應(yīng)用服務(wù)器就是極限。
• 當(dāng)應(yīng)用的量級太大后，單個(gè)城市的機(jī)器、電、帶寬等資源無法滿足業(yè)務(wù)的持續(xù)增長。這時(shí)就需要考慮SET化架構(gòu)，也就是單元化架構(gòu)，大體思路就是將一些核心系統(tǒng)拆成多個(gè)中心，每個(gè)中心成為一個(gè)單元，流量會按照一定的規(guī)則分配給每個(gè)單元，這樣每個(gè)單元只負(fù)責(zé)處理自己的流量就可以了。每個(gè)單元要盡量自包含、高內(nèi)聚。這是從整體層面將流量分而治之的思路。這是單元化后的機(jī)構(gòu)簡圖如下：

5.0 單元化

從上面的架構(gòu)圖里能看到，流量從接入層按照路由規(guī)則（比如以用戶ID來路由）路由到不同單元，每個(gè)單元內(nèi)都是高內(nèi)聚，包含了核心系統(tǒng)，數(shù)據(jù)層面的分片邏輯是與接入層路有邏輯一致，也解決了數(shù)據(jù)庫連接的瓶頸問題，但是一些跨單元的調(diào)用是無法避免的，同時(shí)也有些無法拆分的業(yè)務(wù)需要放在中心單元，供所有其他單元調(diào)用。

參考文章

• 文章主要參考自 李智慧的 《大型網(wǎng)站技術(shù)架構(gòu)》
• https://blog.csdn.net/caoyuanyenang/article/details/86943397
• https://www.cnblogs.com/lfs2640666960/p/9021205.html
• http://www.hollischuang.com/archives/728

?

作者|頂尖架構(gòu)師棧文章來源地址http://www.zghlxwxcb.cn/news/detail-710688.html

到了這里，關(guān)于電商系統(tǒng)架構(gòu)演進(jìn)的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！