聊聊電商系統架構演進

具體以電子商務網站為例， 展示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