一個成熟的大型網(wǎng)站系統(tǒng)架構(gòu)并不是一開始就設(shè)計的非常完美甥厦，也不是一開始就具備高性能、高可用寇钉、安全性等特性刀疙，而是隨著用戶量的增加、業(yè)務(wù)功能的擴展逐步完善演變過來的摧莽。在這個過程中庙洼，開發(fā)模式、技術(shù)架構(gòu)等都會發(fā)生非常大的變化镊辕。而針對不同業(yè)務(wù)特征的系統(tǒng)油够，會有各自的側(cè)重點。
比如像淘寶這類的網(wǎng)站征懈，要解決的是海量商品搜索石咬、下單、支付等問題卖哎；
像騰訊鬼悠，要解決的是數(shù)億級別用戶的實時消息傳輸；
百度所要解決的是海量數(shù)據(jù)的搜索亏娜。每一個種類的業(yè)務(wù)都有自己不同的系統(tǒng)架構(gòu)焕窝。
我們簡單模擬一個架構(gòu)演變過程。我們以 javaweb 為例维贺，來搭建一個簡單的電商系統(tǒng)它掂，從這個系統(tǒng)中來看系統(tǒng)的演變歷史；要注意的是溯泣，接下來的演示模型虐秋，關(guān)注的是數(shù)據(jù)量、訪問量提升垃沦，網(wǎng)站結(jié)構(gòu)發(fā)生的變化客给， 而不是具體關(guān)注業(yè)務(wù)功能點。其次肢簿，這個過程是為了讓大家更好的了解網(wǎng)站演進(jìn)過程中的一些問題和應(yīng)對策略靶剑。
假如我們系統(tǒng)具備以下功能：
用戶模塊：用戶注冊和管理
商品模塊：商品展示和管理
交易模塊：創(chuàng)建交易及支付結(jié)算
階段一，單應(yīng)用架構(gòu)
網(wǎng)站的初期也可以認(rèn)為是互聯(lián)網(wǎng)發(fā)展的早起译仗，我們經(jīng)常會在單機上跑我們所有的程序和軟件抬虽。把所有軟件和應(yīng)用都部署在一臺機器上，這樣就完成一個簡單
系統(tǒng)的搭建纵菌，這個時候的講究的是效率
階段二阐污，應(yīng)用服務(wù)器和數(shù)據(jù)庫服務(wù)器分離
隨著網(wǎng)站的上線，訪問量逐步上升咱圆，服務(wù)器的負(fù)載慢慢提高笛辟，在服務(wù)器還沒有超載的時候功氨，我們應(yīng)該做好規(guī)劃，提升網(wǎng)站的負(fù)載能力手幢。假如代碼層面的優(yōu)化已經(jīng)沒辦法繼續(xù)提高捷凄，在不提高單臺機器的性能，增加機器是一個比較好的方式围来，投入產(chǎn)出比非常高跺涤。這個階段增加機器的主要目的是講 web 服務(wù)器和數(shù)據(jù)庫服務(wù)器拆分，這樣不僅提高了單機的負(fù)載能力监透，也提高了容災(zāi)能力
階段三桶错，應(yīng)用服務(wù)器負(fù)載告警,應(yīng)用服務(wù)器集群
隨著訪問量的繼續(xù)增加，單臺應(yīng)用服務(wù)器已經(jīng)無法滿足需求胀蛮。在假設(shè)數(shù)據(jù)庫服務(wù)器還沒有遇到性能問題的時候院刁，我們可以增加應(yīng)用服務(wù)器，通過應(yīng)用服務(wù)器集群將用戶請求分流到各個服務(wù)器中粪狼，從而繼續(xù)提升負(fù)載能力退腥。此時多臺應(yīng)用服務(wù)器之間沒有直接的交互，他們都是依賴數(shù)據(jù)庫各自對外提供服務(wù)
架構(gòu)發(fā)展到這個階段再榄，各種問題也會慢慢呈現(xiàn)
- 用戶請求由誰來轉(zhuǎn)發(fā)到具體的應(yīng)用服務(wù)器
F5硬件負(fù)載/Nginx和Haproxy軟件負(fù)載 - 用戶如果每次訪問到的服務(wù)器不一樣狡刘，那么如何維護(hù)session
這個可以參考： https://blog.csdn.net/fd2025/article/details/80484250
階段四，數(shù)據(jù)庫壓力變大困鸥，數(shù)據(jù)庫讀寫分離
架構(gòu)演變到這里颓帝，并不是終點。上面我們把應(yīng)用層的性能拉上來了窝革，但是數(shù)據(jù)庫的負(fù)載也在慢慢增大，那么怎么去提高數(shù)據(jù)庫層面的負(fù)載呢吕座？有了前面的思路以后虐译，自然會想到增加服務(wù)器。但是假如我們單純的把數(shù)據(jù)庫一分為二吴趴，然后對于后續(xù)數(shù)據(jù)庫的請求漆诽，分別負(fù)載到兩臺數(shù)據(jù)庫服務(wù)器上，那么一定會造成數(shù)據(jù)庫不統(tǒng)一的問題锣枝。所以我們一般先考慮讀寫分離的方式
這個架構(gòu)的變化會帶來幾個問題
-
主從數(shù)據(jù)庫之間的數(shù)據(jù)同步
`可以使用 mysql 自帶的master-slave方式實現(xiàn)主從復(fù)制 -
對應(yīng)數(shù)據(jù)源的選擇
采用第三方數(shù)據(jù)庫中間件厢拭，例如 mycat
階段五，使用搜索引擎緩解讀庫的壓力
數(shù)據(jù)庫做讀庫的話撇叁，嘗嘗對模糊查找效率不是特別好供鸠，像電商類的網(wǎng)站，搜索是非常核心的功能陨闹，即便是做了讀寫分離楞捂，這個問題也不能有效解決薄坏。那么這個時候就需要引入搜索引擎了使用搜索引擎能夠大大提高我們的查詢速度，但是同時也會帶來一些附加的問題寨闹，比如維護(hù)索引的構(gòu)建胶坠。
階段六，引入緩存機制緩解數(shù)據(jù)庫的壓力
隨著訪問量的持續(xù)增加繁堡，逐漸出現(xiàn)許多用戶訪問統(tǒng)一部分內(nèi)容的情況沈善，對于這些熱點數(shù)據(jù)，沒必要每次都從數(shù)據(jù)庫去讀取椭蹄，我們可以使用緩存技術(shù)闻牡，比如 memcache、redis 來作為我們應(yīng)用層的緩存塑娇；另外在某些場景下澈侠，比如我們對用戶的某些IP的訪問頻率做限制，那這個放內(nèi)存中又不合適埋酬，放數(shù)據(jù)庫又太麻煩哨啃，這個時候 可以使用Nosql 的方式比如 mongDB 來代替?zhèn)鹘y(tǒng)的關(guān)系型數(shù)據(jù)庫
階段七，數(shù)據(jù)庫的水平/垂直拆分
我們的網(wǎng)站演進(jìn)的變化過程写妥，交易拳球、商品、用戶的數(shù)據(jù)都還在同一個數(shù)據(jù)庫中珍特，盡管采取了增加緩存祝峻，讀寫分離的方式，但是隨著數(shù)據(jù)庫的壓力持續(xù)增加扎筒，數(shù)據(jù)庫的瓶頸仍然是個最大的問題莱找。因此我們可以考慮對數(shù)據(jù)的垂直拆分和水平拆分
垂直拆分：把數(shù)據(jù)庫中不同業(yè)務(wù)數(shù)據(jù)拆分到不同的數(shù)據(jù)庫水平拆分：把同一個表中的數(shù)據(jù)拆分到兩個甚至跟多的數(shù)據(jù)庫中
水平拆分的原因是某些業(yè)務(wù)數(shù)據(jù)量已經(jīng)達(dá)到了單個數(shù)據(jù)庫的瓶頸，這時可以采取講表拆分到多個數(shù)據(jù)庫中
