具體以電子商務網站爲例， 展示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
作者|頂尖架構師棧