電商系統架構演進

具體以電子商務網站為例， 展示web應用的架構演變過程。

1.0時代

這個時候是一個web項目里包含了所有的模塊，一個資料庫里包含了所需要的所有表，這時候網站訪問量增加時，首先遇到瓶頸的是應用伺服器連接數，比如tomcat連接數不能無限增加，線程數上限受進程記憶體大小、CPU內核數等因素影響，當線程數到達一定數時候，線程上下文的切換對性能的損耗會越來越嚴重，響應會變慢，通過增加web應用伺服器方式的橫向擴展對架構影響最小，這時候架構會變成下麵這樣：

2.0時代

這時候隨著網站訪問量繼續增加，繼續增加應用伺服器數量後發現資料庫成了瓶頸，而資料庫的最主要的瓶頸體現在兩方面：

• 資料庫的最大連接數是有限的，比如當前資料庫的連接數設置8000，如果每個應用伺服器與資料庫的初始連接數設置40，那麼200台web伺服器是極限， 並且連接數太多後，資料庫的讀寫壓力增大，耗時增加
• 當單表數量過大時，對該表的操作耗時會增加，索引優化也是緩兵之計

這時，根據業務特點，如果讀寫比差距不大，並且對數據一致性要求不是很高的情況下，資料庫可以採用主從方式進行讀寫分離的方案，並且引入緩存機制來抗讀流量。如果讀寫比差距很大或者對數據一致性要求高時，就不適合用讀寫分離方案，需要考慮業務的垂直拆分，這時期的系統架構圖如下：

3.0時代

3.1 讀寫分離

這時候仍然是垂直架構，所有業務集中在一個項目里。項目維護、快速迭代問題會越來越嚴重，單個模塊的開發都需要發佈整個項目，項目穩定性也受到很大挑戰，這是需要考慮業務的垂直拆分，需要將一些大的模塊單獨拆出來，這時候的架構圖如下：

4.0 業務垂直拆分

這時候為了進一步提升用戶體驗，加速用戶的網站訪問速度，會使用CDN來緩存信息，用戶會訪問最近的CDN節點來提升訪問速度。此時的架構圖如下：

4.1 使用CDN來緩存信息

隨著業務量增大，一些核心系統資料庫單表數量達到幾千萬甚至億級，這時候對該表的數據操作效率會大大降低，並且雖然有緩存來抗讀的壓力，但是對於大量的寫操作和一些緩存miss的流量到達一定量時，單庫的負荷也會到達極限，這時候需要將表拆分，一般直接採用分庫分表，因為只做分表的話，單個庫的連接瓶頸仍然無法解決。分庫分表後的架構如下：

4.2分庫分表架構

隨著流量的進一步增大，這時候系統仍然會有瓶頸出現，以訂單系統為例：單個機房的機器是有限的，不能一直新增下去，並且基於容災的考慮，一般採用同城雙機房的方式，機房之間用專線鏈接，同城跨機房質檢的延時在幾毫秒，此時的架構圖如下：

4.3 同城雙機房

由於資料庫主庫只能是在一個機房，所以仍然會有一半的資料庫訪問是跨機房的，雖然延時只有幾毫秒，但是一個調用鏈里的資料庫訪問太多後，這個延時也會積少成多。其次這個架構還是沒能解決資料庫連接數瓶頸問題

• 隨著應用伺服器的增加，雖然是分庫分表，但每增加一臺應用伺服器，都會與每個分庫建立連接，比如資料庫連接池預設連接數是40，而如果mysql資料庫的最大連接數是8000的話，那麼200台應用伺服器就是極限。
• 當應用的量級太大後，單個城市的機器、電、帶寬等資源無法滿足業務的持續增長。這時就需要考慮SET化架構，也就是單元化架構，大體思路就是將一些核心系統拆成多個中心，每個中心成為一個單元，流量會按照一定的規則分配給每個單元，這樣每個單元只負責處理自己的流量就可以了。每個單元要儘量自包含、高內聚。這是從整體層面將流量分而治之的思路。這是單元化後的機構簡圖如下：

5.0 單元化

從上面的架構圖裡能看到，流量從接入層按照路由規則（比如以用戶ID來路由）路由到不同單元，每個單元內都是高內聚，包含了核心系統，數據層面的分片邏輯是與接入層路有邏輯一致，也解決了資料庫連接的瓶頸問題，但是一些跨單元的調用是無法避免的，同時也有些無法拆分的業務需要放在中心單元，供所有其他單元調用。

參考文章

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

作者|頂尖架構師棧

本文來自博客園，作者：古道輕風，轉載請註明原文鏈接：https://www.cnblogs.com/88223100/p/Evolution-of-E-commerce-System-Architecture.html