1、淺談web網站架構演變過程刖b我們以javaweb為例，來搭建一個簡單的電商系統，看看這個系統可 以如何一步步演變。該系統具備的功能：?用戶模塊：用戶注冊和管理商品模塊：商品展示和管理交易模塊: 創建交易和管理階段一、單機構建網站網站的初期，我們經常會在單機上跑我們所有的程序和軟件。此時我 們使用一個容器，如tomcat> jetty、jboos,然后直接使用jsp/servlet技術, 或者使用一些開源的框架如maven+spring+struct+hibernate>maven+spring+springmvc+mybatis；最后再選擇一個數據庫管理系統來 存儲數據,如mys

2、ql sqlserver、oracle,然后通過jdbc進行數據庫的連接 和操作。把以上的所有軟件都裝載同一臺機器上，應用跑起來了，也算是一個 小系統了。此時系統結果如下：階段二、應用服務器與數據庫分離隨著網站的上線，訪問量逐步上升，服務器的負載慢慢提高，在服務器還沒有超載的時候，我們應該就要做好準備，提升網站的負載能力。假 如我們代碼層面已難以優化，在不提高單臺機器的性能的情況下，增加機 器是一個不錯的方式，不僅可以有效地提高系統的負載能力，而且性價比 高。增加的機器用來做什么呢？此時我們可以把數據庫，web服務器拆分 開來，這樣不僅提高了單臺機器的負載能力，也提高了容災能力。應用服務器與數

3、據庫分開后的架構如下圖所示：階段三、應用服務器集群隨著訪問量繼續增加，單臺應用服務器己經無法滿足需求了。在假設 數據庫服務器沒有壓力的情況下，我們可以把應用服務器從一臺變成了兩 臺甚至多臺，把用戶的請求分散到不同的服務器屮，從而提高負載能力。 多臺應用服務器之間沒有直接的交互，他們都是依賴數據庫各自對外提供 服務。著名的做故障切換的軟件有keepalived, keepalived是一個類似于 layers. 4. 7交換機制的軟件，他不是某個具體軟件故障切換的專屬品， 而是可以適用于各種軟件的一款產品。keepalived配合上ipvsadm又可以 做負載均衡，可謂是神器。我們以增加了一臺應

4、用服務器為例，增加后的系統結構圖如下：系統演變到這里，將會出現下面四個問題：1. 用戶的請求由誰來轉發到到具體的應用服務器2. 有什么轉發的算法3. 應用服務器如何返回用戶的請求4. 用戶如果每次訪問到的服務器不一樣，那么如何維護session的一致性我們來看看解決問題的方案：11、http重定向。http重定向就是應用層的請求轉發。用戶的請求其 實已經到了 http重定向負載均衡服務器，服務器根據算法要求用戶重定 向，用戶收到重定向請求后，再次請求真正的集群優點：簡單。缺點：性能較差。2、dns域名解析負載均衡。dns域名解析負載均衡就是在用戶請求dns服務器，獲取域名對應的ip地址時，dn

5、s服務器直接給出負載均衡后 的服務器ipo優點：交給dns,不用我們去維護負載均衡服務器。缺點：當一個應用服務器掛了，不能及時通知dns,而 dns負載均 衡的控制權在域名服務商那里，網站無法做更多的改善和更強大的管理。3、反向代理服務器。在用戶的請求到達反向代理服務器時（己經到 達網站機房），由反向代理服務器根據算法轉發到具體的服務器。常用的 apache, nginx都可以充當反向代理服務器。優點：部署簡單。缺點：代理服務器可能成為性能的瓶頸，特別是一次上傳大文件。4、ip層負載均衡。在請求到達負載均衡器后，負載均衡器通過修改 請求的目的ip地址，從而實現請求的轉發，做到負載均衡。優點：性

6、能更好。缺點：負載均衡器的寬帶成為瓶頸。5、數據鏈路層負載均衡。在請求到達負載均衡器后，負載均衡器通 過修改請求的mac地址，從而做到負載均衡，與ip負載均衡不一樣的是， 當請求訪問完服務器z后，直接返回客戶。而無需再經過負載均衡器。2、第二個問題即是集群調度算法問題，常見的調度算法有10種。1> rr輪詢調度算法。顧名思義，輪詢分發請求。優點：實現簡單缺點：不考慮毎臺服務器的處理能力2、wrr加權調度算法。我們給每個服務器設置權值weight,負載均衡 調度器根據權值調度服務器，服務器被調用的次數跟權值成正比。優點：考慮了服務器處理能力的不同3、sh原地址散列：提取用戶ip,根據散列函

7、數得出一個key,再根 據靜態映射表，查處對應的value,即目標服務器ip。過目標機器超負荷, 則返回空。4、dh目標地址散列：同上，只是現在提取的是目標地址的ip來做哈希。優點：以上兩種算法的都能實現同一個用戶訪問同一個服務器。5、lc最少連接。優先把請求轉發給連接數少的服務器。優點：使得集群中各個服務器的負載更加均勻。6、wlc加權最少連接。在lc的基礎上，為每臺服務器加上權值。算法為：（活動連接數*256+非活動連接數）一權重，計算出來的值小的服 務器優先被選擇。優點：可以根據服務器的能力分配請求。7、sed最短期望延遲。其實sed跟wlc類似，區別是不考慮非活動連 接數。算法為：（活

8、動連接數+1）*256-權重，同樣計算出來的值小的服務 器優先被選擇。8、nq永不排隊。改進的sed算法。我們想一下什么情況下才能"永 不排隊”，那就是服務器的連接數為0的時候，那么假如有服務器連接數 為0,均衡器直接把請求轉發給它，無需經過sed的計算。9、lblc基于局部性的最少連接。均衡器根據請求的冃的ip地址，找 出該ip地址最近被使用的服務器，把請求轉發之，若該服務器超載，最采 用最少連接數算法。10、lblcr帶復制的基于局部性的最少連接。均衡器根據請求的目的 ip地址，找出該ip地址最近使用的“服務器組”，注意，并不是具體某個 服務器，然后釆用最少連接數從該組屮挑出具體

9、的某臺服務器出來，把請 求轉發之。若該服務器超載，那么根據最少連接數算法，在集群的非本服 務器組的服務器中，找出一臺服務器出來，加入本服務器組，然后把請求 轉發之。3、第三個問題是集群模式問題，一般3種解決方案：1、nat：負載均衡器接收用戶的請求，轉發給具體服務器，服務器處 理完請求返回給均衡器，均衡器再重新返回給用戶。2、dr：負載均衡器接收用戶的請求，轉發給具體服務器，服務器出 來玩請求后直接返回給用戶。需要系統支持ip tunneling協議，難以跨平 臺。3、tun：同上，但無需ip tunneling協議，跨平臺性好，大部分系統 都可以支持。4、第四個問題是session問題，一般

10、有4種解決方案:1、session stickyo session sticky就是把同一個用戶在某一個會話中的 請求，都分配到固定的某一臺服務器屮，這樣我們就不需耍解決跨服務器 的session問題了，常見的算法有ip.hash法，即上面提到的兩種散列算法。優點：實現簡單。缺點：應用服務器重啟則session消失。2、session replication。session replication 就是在集群中復制 session, 使得每個服務器都保存有全部用戶的session數據。優點：減輕負載均衡服務器的壓力，不需要要實現ip_hasp算法來轉 發請求。缺點：復制時寬帶開銷大，訪問量大的

11、話session占用內存大且浪費。3、session數據集中存儲：session數據集中存儲就是利用數據庫來存 儲session數據，實現了 session和應用服務器的解耦。優點：相比session replication的方案，集群間對于寬帶和內存的壓力 減少了很多。缺點：需要維護存儲session的數據庫。4、cookie base： cookie base 就是把 session 存在 cookie 中,有瀏覽器 來告訴應用服務器我的session是什么，同樣實現了 session和應用服務器 的解耦。優點：實現簡單，基本免維護。缺點：cookie長度限制，安全性低，寬帶消耗。值得一提

12、的是：nginx目前支持的負載均衡算法有wrr、sh （支持一致性哈希）、fair （本 人覺得可以歸結為lc）。但nginx作為均衡器的話，還可以一同作為靜態資 源服務器。keepalived+ipvsadm比較強大，冃前支持的算法有：rr> wrr> lc、wlc、iblc、sh、dhkeepalived支持集群模式有:nat> dr> tunnginx本身并沒有提供session同步的解決方案，而apache則提供了 session共享的支持。好了，解決了以上的問題之后，系統的結構如下：階段四、數據庫讀寫分離化上面我們總是假設數據庫負載止常，但隨著訪問量的的提高，

13、數據庫 的負載也在慢慢增大。那么可能有人馬上就想到跟應用服務器一樣，把數 據庫一份為二再負載均衡即可。但對于數據庫來說，并沒有那么簡單。假 如我們簡單的把數據庫一分為二，然后對于數據庫的請求，分別負載到a 機器和b機器，那么顯而易見會造成兩臺數據庫數據不統一的問題。那么 對于這種情況，我們可以先考慮使用讀寫分離的方式。讀寫分離后的數據庫系統結構如下：這個結構變化后也會帶來兩個問題：1. 主從數據庫之間數據同步問題2. 應用對于數據源的選擇問題解決問題方案：1. 我們可以使用mysql自帶的master+slave的方式實現主從復制。2. 采用第三方數據庫中間件，例如mycat。mycat是從c

14、obar發展而來 的，而cobar是阿里開源的數據庫中間件，后來停止開發。mycat是國內比較好的mysql開源數據庫分庫分表中間件。階段五、用搜索引擎緩解讀庫的壓力數據庫做讀庫的話，常常對模糊查找力不從心，即使做了讀寫分離， 這個問題還未能解決。以我們所舉的交易網站為例，發布的商品存儲在數 據庫中，用戶最常使用的功能就是查找商甜，尤其是根據商品的標題來查 找對應的商品。對于這種需求，一般我們都是通過like功能來實現的，但 是這種方式的代價非常大。此時我們可以使用搜索引擎的倒排索引來完成。搜索引擎具有以下優點：?它能夠大大提高查詢速度。引入搜索引擎后也會帶來以下的開銷：?帶來大量的維護工作，

15、我們需要自己實現索引的構建過程，設計全 量/增加的構建方式來應對非實時與實時的查詢需求。?需要維護搜索引擎集群搜索引擎并不能替代數據庫，他解決了某些場景下的“讀”的問題， 是否引入搜索引擎，需要綜合考慮整個系統的需求。引入搜索引擎后的系 統結構如下：階段六、用緩存緩解讀庫的壓力1、后臺應用層和數據庫層的緩存隨著訪問量的增加，逐漸岀現了許多用戸訪問同一部分內容的情況，對于這些比較熱門的內容，沒必要每次都從數據庫讀取。我們可以使用緩 存技術，例如可以使用google的開源緩存技術guava或者使用memcacahe 作為應用層的緩存，也可以使用redis作為數據庫層的緩存。另外，在某些場景下，關系

16、型數據庫并不是很適合，例如我想做一個 “每日輸入密碼錯誤次數限制”的功能，思路大概是在用戶登錄時，如果登錄 錯誤，則記錄下該用戶的ip和錯誤次數，那么這個數據要放在哪里呢？假如放在內 存中，那么顯然會占用太大的內容；假如放在關系型數據庫中，那么既要 建立數據庫表，還要簡歷對應的java bean,還要寫sql等等。而分析一下 我們耍存儲的數據，無非就是類似ip:errornumber這樣的key:value數據。 對于這種數據，我們可以用nosql數據庫來代替傳統的關系型數據庫。2、頁面緩存除了數據緩存，還有頁面緩存。比如使用html5的localstroage或者 cookieo優點：?減輕

17、數據庫的壓力大幅度提高訪問速度缺點：?需要維護緩存服務器提高了編碼的復雜性值得一提的是： 緩存集群的調度算法不同與上面提到的應用服務器和數據庫。最好采 用“一致性哈希算法”，這樣才能提高命中率。這個就不展開講了，有興 趣的可以查閱相關資料。加入緩存后的結構：階段七、數據庫水平拆分與垂直拆分我們的網站演進到現在，交易、商品、用戶的數據都還在同一個數據 庫中。盡管采取了增加緩存，讀寫分離的方式，但隨著數據庫的壓力繼續 增加，數據庫的瓶頸越來越突出，此時，我們可以有數據垂直拆分和水平 拆分兩種選擇。7.1. 數據垂直拆分垂直拆分的意思是把數據庫屮不同的業務數據拆分道不同的數據庫 中，結合現在的例子，

18、就是把交易、商甜、用戶的數據分開。優點：?解決了原來把所冇業務放在一個數據庫中的壓力問題。可以根據 業務的特點進行更多的優化缺點：?需要維護多個數據庫問題：1. 需要考慮原來跨業務的事務2. 跨數據庫的join解決問題方案：1. 我們應該在應用層盡量避免跨數據庫的事物，如果非要跨數據庫,盡量在代碼中控制。2. 我們可以通過第三方應用來解決，如上面提到的mycat, mycat提 供了豐富的跨庫join方案，詳情可參考mycat官方文檔。垂直拆分后的結構如下：7.2、數據水平拆分數據水平拆分就是把同一個表中的數據拆分到兩個甚至多個數據庫 中。產生數據水平拆分的原因是某個業務的數據量或者更新量到達

19、了單個 數據庫的瓶頸，這時就可以把這個表拆分到兩個或更多個數據庫屮。優點：?如果我們能客服以上問題，那么我們將能夠很好地對數據量及寫入 量增長的情況。問題：1. 訪問用戶信息的應用系統需要解決sql路由的問題，因為現在用戶 信息分在了兩個數據庫中，需要在進行數據操作時了解需要操作的數據在哪里。2. 主鍵的處理也變得不同，例如原來自增字段，現在不能簡單地繼續 使用了。3如果需要分頁，就麻煩了。解決問題方案:1. 我們還是可以通過可以解決第三方中間件，如mycat。mycat可以 通過sql解析模塊對我們的sql進行解析，再根據我們的配置，把請求轉發到 具體的某個數據庫。2. 我們可以通過uuid

20、保證唯一或口定義id方案來解決。3. mycat也提供了豐富的分頁查詢方案，比如先從每個數據庫做分頁 查詢，再合并數據做一次分頁查詢等等。數據水平拆分后的結構：階段八、應用的拆分8.1拆分應用隨著業務的發展，業務越來越多，應用越來越人。我們需要考慮如何 避免讓應用越來越臃腫。這就需要把應用拆開，從一個應用變為倆個甚至 更多。還是以我們上面的例子，我們可以把用戶、商品、交易拆分開。變 成“用戶、商品”和“用戶，交易”兩個子系統。拆分后的結構：問題：1.這樣拆分后，可能會有一些相同的代碼，如用戶相關的代碼，商品 和交易都需耍用戶信息，所以在兩個系統屮都保留差不多的操作用戶信息的代 碼。如何保證這些代碼可以復用是一個需要解決的問題。解決問題:1.通過走服務化的路線來解決8.2