亚洲综合网伊人中文|亚洲一区二区无码动漫|成年性午夜免费视频网站不卡|色爱区综合激情五月综合色

我們以Java Web為例，來(lái)搭建一個(gè)簡(jiǎn)單的電商系統網(wǎng)站，看看這個(gè)網(wǎng)站可以如何一步步演變。

該系統具備的功能：

• 用戶(hù)模塊：用戶(hù)注冊和管理

• 商品模塊：商品展示和管理

• 交易模塊：創(chuàng )建交易和管理
  

階段一：?jiǎn)螜C構建網(wǎng)站
網(wǎng)站的初期，我們經(jīng)常會(huì )在單機上跑我們所有的程序和軟件。此時(shí)我們使用一個(gè)容器，如tomcat、jetty、jboos，然后直接使用JSP/servlet技術(shù)，或者使用一些開(kāi)源的框架如maven+spring+struct+hibernate、maven+spring+springmvc+mybatis；最后再選擇一個(gè)數據庫管理系統來(lái)存儲數據，如mysql、sqlserver、oracle，然后通過(guò)JDBC進(jìn)行數據庫的連接和操作。把以上的所有軟件都裝載同一臺機器上，應用跑起來(lái)了，也算是一個(gè)小系統了。此時(shí)系統結果如下：

階段二：應用服務(wù)器與數據庫分離
隨著(zhù)網(wǎng)站的上線(xiàn)，訪(fǎng)問(wèn)量逐步上升，服務(wù)器的負載慢慢提高，在服務(wù)器還沒(méi)有超載的時(shí)候，我們應該就要做好準備，提升網(wǎng)站的負載能力。假如我們代碼層面已難以?xún)?yōu)化，在不提高單臺機器的性能的情況下，增加機器是一個(gè)不錯的方式，不僅可以有效地提高系統的負載能力，而且性?xún)r(jià)比高。

增加的機器用來(lái)做什么呢？此時(shí)我們可以把數據庫，web服務(wù)器拆分開(kāi)來(lái)，這樣不僅提高了單臺機器的負載能力，也提高了容災能力。應用服務(wù)器與數據庫分開(kāi)后的架構如下圖所示：

階段三：應用服務(wù)器集群
隨著(zhù)訪(fǎng)問(wèn)量繼續增加，單臺應用服務(wù)器已經(jīng)無(wú)法滿(mǎn)足需求了。在假設數據庫服務(wù)器沒(méi)有壓力的情況下，我們可以把應用服務(wù)器從一臺變成了兩臺甚至多臺，把用戶(hù)的請求分散到不同的服務(wù)器中，從而提高負載能力。多臺應用服務(wù)器之間沒(méi)有直接的交互，他們都是依賴(lài)數據庫各自對外提供服務(wù)。著(zhù)名的做故障切換的軟件有keepalived，keepalived是一個(gè)類(lèi)似于layer3、4、7交換機制的軟件，他不是某個(gè)具體軟件故障切換的專(zhuān)屬品，而是可以適用于各種軟件的一款產(chǎn)品。keepalived配合上ipvsadm又可以做負載均衡，可謂是神器。

我們以增加了一臺應用服務(wù)器為例，增加后的系統結構圖如下：

系統演變到這里，將會(huì )出現下面四個(gè)問(wèn)題：

1. 用戶(hù)的請求由誰(shuí)來(lái)轉發(fā)到到具體的應用服務(wù)器

2. 有什么轉發(fā)的算法

3. 應用服務(wù)器如何返回用戶(hù)的請求

4. 用戶(hù)如果每次訪(fǎng)問(wèn)到的服務(wù)器不一樣，那么如何維護session的一致性

我們來(lái)看看解決問(wèn)題的方案：

1、第一個(gè)問(wèn)題即是負載均衡的問(wèn)題，一般有5種解決方案：

1、http重定向。HTTP重定向就是應用層的請求轉發(fā)。用戶(hù)的請求其實(shí)已經(jīng)到了HTTP重定向負載均衡服務(wù)器，服務(wù)器根據算法要求用戶(hù)重定向，用戶(hù)收到重定向請求后，再次請求真正的集群

優(yōu)點(diǎn)：簡(jiǎn)單。

缺點(diǎn)：性能較差。

2、DNS域名解析負載均衡。DNS域名解析負載均衡就是在用戶(hù)請求DNS服務(wù)器，獲取域名對應的IP地址時(shí)，DNS服務(wù)器直接給出負載均衡后的服務(wù)器IP。

優(yōu)點(diǎn)：交給DNS，不用我們去維護負載均衡服務(wù)器。

缺點(diǎn)：當一個(gè)應用服務(wù)器掛了，不能及時(shí)通知DNS，而且DNS負載均衡的控制權在域名服務(wù)商那里，網(wǎng)站無(wú)法做更多的改善和更強大的管理。

3、反向代理服務(wù)器。在用戶(hù)的請求到達反向代理服務(wù)器時(shí)（已經(jīng)到達網(wǎng)站機房），由反向代理服務(wù)器根據算法轉發(fā)到具體的服務(wù)器。常用的apache，nginx都可以充當反向代理服務(wù)器。

優(yōu)點(diǎn)：部署簡(jiǎn)單。

缺點(diǎn)：代理服務(wù)器可能成為性能的瓶頸，特別是一次上傳大文件。

4、IP層負載均衡。在請求到達負載均衡器后，負載均衡器通過(guò)修改請求的目的IP地址，從而實(shí)現請求的轉發(fā)，做到負載均衡。

優(yōu)點(diǎn)：性能更好。

缺點(diǎn)：負載均衡器的寬帶成為瓶頸。

5、數據鏈路層負載均衡。在請求到達負載均衡器后，負載均衡器通過(guò)修改請求的mac地址，從而做到負載均衡，與IP負載均衡不一樣的是，當請求訪(fǎng)問(wèn)完服務(wù)器之后，直接返回客戶(hù)。而無(wú)需再經(jīng)過(guò)負載均衡器。

2、第二個(gè)問(wèn)題即是集群調度算法問(wèn)題，常見(jiàn)的調度算法有10種。

1、rr 輪詢(xún)調度算法。顧名思義，輪詢(xún)分發(fā)請求。

優(yōu)點(diǎn)：實(shí)現簡(jiǎn)單

缺點(diǎn)：不考慮每臺服務(wù)器的處理能力

2、wrr 加權調度算法。我們給每個(gè)服務(wù)器設置權值weight，負載均衡調度器根據權值調度服務(wù)器，服務(wù)器被調用的次數跟權值成正比。

優(yōu)點(diǎn)：考慮了服務(wù)器處理能力的不同

3、sh 原地址散列：提取用戶(hù)IP，根據散列函數得出一個(gè)key，再根據靜態(tài)映射表，查處對應的value，即目標服務(wù)器IP。過(guò)目標機器超負荷，則返回空。

4、dh 目標地址散列：同上，只是現在提取的是目標地址的IP來(lái)做哈希。

優(yōu)點(diǎn)：以上兩種算法的都能實(shí)現同一個(gè)用戶(hù)訪(fǎng)問(wèn)同一個(gè)服務(wù)器。

5、lc 最少連接。優(yōu)先把請求轉發(fā)給連接數少的服務(wù)器。

優(yōu)點(diǎn)：使得集群中各個(gè)服務(wù)器的負載更加均勻。

6、wlc 加權最少連接。在lc的基礎上，為每臺服務(wù)器加上權值。算法為：（活動(dòng)連接數*256+非活動(dòng)連接數）÷權重 ，計算出來(lái)的值小的服務(wù)器優(yōu)先被選擇。

優(yōu)點(diǎn)：可以根據服務(wù)器的能力分配請求。

7、sed 最短期望延遲。其實(shí)sed跟wlc類(lèi)似，區別是不考慮非活動(dòng)連接數。算法為：（活動(dòng)連接數+1)*256÷權重，同樣計算出來(lái)的值小的服務(wù)器優(yōu)先被選擇。

8、nq 永不排隊。改進(jìn)的sed算法。我們想一下什么情況下才能“永不排隊”，那就是服務(wù)器的連接數為0的時(shí)候，那么假如有服務(wù)器連接數為0，均衡器直接把請求轉發(fā)給它，無(wú)需經(jīng)過(guò)sed的計算。

9、LBLC 基于局部性的最少連接。均衡器根據請求的目的IP地址，找出該IP地址最近被使用的服務(wù)器，把請求轉發(fā)之，若該服務(wù)器超載，最采用最少連接數算法。

10、LBLCR 帶復制的基于局部性的最少連接。均衡器根據請求的目的IP地址，找出該IP地址最近使用的“服務(wù)器組”，注意，并不是具體某個(gè)服務(wù)器，然后采用最少連接數從該組中挑出具體的某臺服務(wù)器出來(lái)，把請求轉發(fā)之。若該服務(wù)器超載，那么根據最少連接數算法，在集群的非本服務(wù)器組的服務(wù)器中，找出一臺服務(wù)器出來(lái)，加入本服務(wù)器組，然后把請求轉發(fā)之。

3、第三個(gè)問(wèn)題是集群模式問(wèn)題，一般3種解決方案：

1、NAT：負載均衡器接收用戶(hù)的請求，轉發(fā)給具體服務(wù)器，服務(wù)器處理完請求返回給均衡器，均衡器再重新返回給用戶(hù)。

2、DR：負載均衡器接收用戶(hù)的請求，轉發(fā)給具體服務(wù)器，服務(wù)器出來(lái)玩請求后直接返回給用戶(hù)。需要系統支持IP Tunneling協(xié)議，難以跨平臺。

3、TUN：同上，但無(wú)需IP Tunneling協(xié)議，跨平臺性好，大部分系統都可以支持。

4、第四個(gè)問(wèn)題是session問(wèn)題，一般有4種解決方案：

1、Session Sticky。session sticky就是把同一個(gè)用戶(hù)在某一個(gè)會(huì )話(huà)中的請求，都分配到固定的某一臺服務(wù)器中，這樣我們就不需要解決跨服務(wù)器的session問(wèn)題了，常見(jiàn)的算法有ip_hash法，即上面提到的兩種散列算法。

優(yōu)點(diǎn)：實(shí)現簡(jiǎn)單。

缺點(diǎn)：應用服務(wù)器重啟則session消失。

2、Session Replication。session replication就是在集群中復制session，使得每個(gè)服務(wù)器都保存有全部用戶(hù)的session數據。

優(yōu)點(diǎn)：減輕負載均衡服務(wù)器的壓力，不需要要實(shí)現ip_hasp算法來(lái)轉發(fā)請求。

缺點(diǎn)：復制時(shí)寬帶開(kāi)銷(xiāo)大，訪(fǎng)問(wèn)量大的話(huà)session占用內存大且浪費。

3、Session數據集中存儲：session數據集中存儲就是利用數據庫來(lái)存儲session數據，實(shí)現了session和應用服務(wù)器的解耦。

優(yōu)點(diǎn)：相比session replication的方案，集群間對于寬帶和內存的壓力減少了很多。

缺點(diǎn)：需要維護存儲session的數據庫。

4、Cookie Base：cookie base就是把session存在cookie中，有瀏覽器來(lái)告訴應用服務(wù)器我的session是什么，同樣實(shí)現了session和應用服務(wù)器的解耦。

優(yōu)點(diǎn)：實(shí)現簡(jiǎn)單，基本免維護。

缺點(diǎn)：cookie長(cháng)度限制，安全性低，寬帶消耗。

值得一提的是：

nginx目前支持的負載均衡算法有wrr、sh（支持一致性哈希）、fair（本人覺(jué)得可以歸結為lc）。但nginx作為均衡器的話(huà)，還可以一同作為靜態(tài)資源服務(wù)器。

keepalived+ipvsadm比較強大，目前支持的算法有：rr、wrr、lc、wlc、lblc、sh、dh

keepalived支持集群模式有：NAT、DR、TUN

nginx本身并沒(méi)有提供session同步的解決方案，而apache則提供了session共享的支持。

好了，解決了以上的問(wèn)題之后，系統的結構如下：

階段四：數據庫讀寫(xiě)分離化
上面我們總是假設數據庫負載正常，但隨著(zhù)訪(fǎng)問(wèn)量的的提高，數據庫的負載也在慢慢增大。那么可能有人馬上就想到跟應用服務(wù)器一樣，把數據庫一份為二再負載均衡即可。但對于數據庫來(lái)說(shuō)，并沒(méi)有那么簡(jiǎn)單。假如我們簡(jiǎn)單的把數據庫一分為二，然后對于數據庫的請求，分別負載到A機器和B機器，那么顯而易見(jiàn)會(huì )造成兩臺數據庫數據不統一的問(wèn)題。那么對于這種情況，我們可以先考慮使用讀寫(xiě)分離的方式。

讀寫(xiě)分離后的數據庫系統結構如下：

這個(gè)結構變化后也會(huì )帶來(lái)兩個(gè)問(wèn)題：

1. 主從數據庫之間數據同步問(wèn)題

2. 應用對于數據源的選擇問(wèn)題

解決問(wèn)題方案：

1. 我們可以使用MYSQL自帶的master+slave的方式實(shí)現主從復制。

2. 采用第三方數據庫中間件，例如mycat。mycat是從cobar發(fā)展而來(lái)的，而cobar是阿里開(kāi)源的數據庫中間件，后來(lái)停止開(kāi)發(fā)。mycat是國內比較好的mysql開(kāi)源數據庫分庫分表中間件。
   

階段五、用搜索引擎緩解讀庫的壓力
數據庫做讀庫的話(huà)，常常對模糊查找力不從心，即使做了讀寫(xiě)分離，這個(gè)問(wèn)題還未能解決。以我們所舉的交易網(wǎng)站為例，發(fā)布的商品存儲在數據庫中，用戶(hù)最常使用的功能就是查找商品，尤其是根據商品的標題來(lái)查找對應的商品。對于這種需求，一般我們都是通過(guò)like功能來(lái)實(shí)現的，但是這種方式的代價(jià)非常大。此時(shí)我們可以使用搜索引擎的倒排索引來(lái)完成。

搜索引擎具有以下優(yōu)點(diǎn)：

它能夠大大提高查詢(xún)速度。

引入搜索引擎后也會(huì )帶來(lái)以下的開(kāi)銷(xiāo)：

• 帶來(lái)大量的維護工作，我們需要自己實(shí)現索引的構建過(guò)程，設計全量/增加的構建方式來(lái)應對非實(shí)時(shí)與實(shí)時(shí)的查詢(xún)需求。

• 需要維護搜索引擎集群

搜索引擎并不能替代數據庫，他解決了某些場(chǎng)景下的“讀”的問(wèn)題，是否引入搜索引擎，需要綜合考慮整個(gè)系統的需求。引入搜索引擎后的系統結構如下：

階段六：用緩存緩解讀庫的壓力

1、后臺應用層和數據庫層的緩存

隨著(zhù)訪(fǎng)問(wèn)量的增加，逐漸出現了許多用戶(hù)訪(fǎng)問(wèn)同一部分內容的情況，對于這些比較熱門(mén)的內容，沒(méi)必要每次都從數據庫讀取。我們可以使用緩存技術(shù)，例如可以使用google的開(kāi)源緩存技術(shù)guava或者使用memcacahe作為應用層的緩存，也可以使用redis作為數據庫層的緩存。

另外，在某些場(chǎng)景下，關(guān)系型數據庫并不是很適合，例如我想做一個(gè)“每日輸入密碼錯誤次數限制”的功能，思路大概是在用戶(hù)登錄時(shí)，如果登錄錯誤，則記錄下該用戶(hù)的IP和錯誤次數，那么這個(gè)數據要放在哪里呢？假如放在內存中，那么顯然會(huì )占用太大的內容；假如放在關(guān)系型數據庫中，那么既要建立數據庫表，還要簡(jiǎn)歷對應的java bean，還要寫(xiě)SQL等等。而分析一下我們要存儲的數據，無(wú)非就是類(lèi)似{ip:errorNumber}這樣的key:value數據。對于這種數據，我們可以用NOSQL數據庫來(lái)代替傳統的關(guān)系型數據庫。

2、頁(yè)面緩存

除了數據緩存，還有頁(yè)面緩存。比如使用HTML5的localstroage或者cookie。

優(yōu)點(diǎn)：

• 減輕數據庫的壓力

• 大幅度提高訪(fǎng)問(wèn)速度

缺點(diǎn)：

• 需要維護緩存服務(wù)器

• 提高了編碼的復雜性

值得一提的是：

緩存集群的調度算法不同與上面提到的應用服務(wù)器和數據庫。最好采用“一致性哈希算法”，這樣才能提高命中率。這個(gè)就不展開(kāi)講了，有興趣的可以查閱相關(guān)資料。

加入緩存后的結構：

我們的網(wǎng)站演進(jìn)到現在，交易、商品、用戶(hù)的數據都還在同一個(gè)數據庫中。盡管采取了增加緩存，讀寫(xiě)分離的方式，但隨著(zhù)數據庫的壓力繼續增加，數據庫的瓶頸越來(lái)越突出，此時(shí)，我們可以有數據垂直拆分和水平拆分兩種選擇。

7.1、數據垂直拆分

垂直拆分的意思是把數據庫中不同的業(yè)務(wù)數據拆分道不同的數據庫中，結合現在的例子，就是把交易、商品、用戶(hù)的數據分開(kāi)。

優(yōu)點(diǎn)：

• 解決了原來(lái)把所有業(yè)務(wù)放在一個(gè)數據庫中的壓力問(wèn)題。

• 可以根據業(yè)務(wù)的特點(diǎn)進(jìn)行更多的優(yōu)化

缺點(diǎn)：

• 需要維護多個(gè)數據庫

問(wèn)題：

1. 需要考慮原來(lái)跨業(yè)務(wù)的事務(wù)

2. 跨數據庫的join

解決問(wèn)題方案：

1. 我們應該在應用層盡量避免跨數據庫的事物，如果非要跨數據庫，盡量在代碼中控制。

2. 我們可以通過(guò)第三方應用來(lái)解決，如上面提到的mycat，mycat提供了豐富的跨庫join方案，詳情可參考mycat官方文檔。

垂直拆分后的結構如下：

7.2、數據水平拆分

數據水平拆分就是把同一個(gè)表中的數據拆分到兩個(gè)甚至多個(gè)數據庫中。產(chǎn)生數據水平拆分的原因是某個(gè)業(yè)務(wù)的數據量或者更新量到達了單個(gè)數據庫的瓶頸，這時(shí)就可以把這個(gè)表拆分到兩個(gè)或更多個(gè)數據庫中。

優(yōu)點(diǎn)：

• 如果我們能客服以上問(wèn)題，那么我們將能夠很好地對數據量及寫(xiě)入量增長(cháng)的情況。

問(wèn)題：

1. 訪(fǎng)問(wèn)用戶(hù)信息的應用系統需要解決SQL路由的問(wèn)題，因為現在用戶(hù)信息分在了兩個(gè)數據庫中，需要在進(jìn)行數據操作時(shí)了解需要操作的數據在哪里。

2. 主鍵的處理也變得不同，例如原來(lái)自增字段，現在不能簡(jiǎn)單地繼續使用了。

3. 如果需要分頁(yè)，就麻煩了。

解決問(wèn)題方案：

1. 我們還是可以通過(guò)可以解決第三方中間件，如mycat。mycat可以通過(guò)SQL解析模塊對我們的SQL進(jìn)行解析，再根據我們的配置，把請求轉發(fā)到具體的某個(gè)數據庫。

2. 我們可以通過(guò)UUID保證唯一或自定義ID方案來(lái)解決。

3. mycat也提供了豐富的分頁(yè)查詢(xún)方案，比如先從每個(gè)數據庫做分頁(yè)查詢(xún)，再合并數據做一次分頁(yè)查詢(xún)等等。

數據水平拆分后的結構：

階段八：應用的拆分
8.1、拆分應用
隨著(zhù)業(yè)務(wù)的發(fā)展，業(yè)務(wù)越來(lái)越多，應用越來(lái)越大。我們需要考慮如何避免讓?xiě)迷絹?lái)越臃腫。這就需要把應用拆開(kāi)，從一個(gè)應用變?yōu)閭z個(gè)甚至更多。還是以我們上面的例子，我們可以把用戶(hù)、商品、交易拆分開(kāi)。變成“用戶(hù)、商品”和“用戶(hù)，交易”兩個(gè)子系統。拆分后的結構：

問(wèn)題：

1. 這樣拆分后，可能會(huì )有一些相同的代碼，如用戶(hù)相關(guān)的代碼，商品和交易都需要用戶(hù)信息，所以在兩個(gè)系統中都保留差不多的操作用戶(hù)信息的代碼。如何保證這些代碼可以復用是一個(gè)需要解決的問(wèn)題。

解決問(wèn)題：

1. 通過(guò)走服務(wù)化的路線(xiàn)來(lái)解決

8.2、走服務(wù)化的道路

為了解決上面拆分應用后所出現的問(wèn)題，我們把公共的服務(wù)拆分出來(lái)，形成一種服務(wù)化的模式，簡(jiǎn)稱(chēng)SOA。

采用服務(wù)化之后的系統結構：

優(yōu)點(diǎn)：

• 相同的代碼不會(huì )散落在不同的應用中了，這些實(shí)現放在了各個(gè)服務(wù)中心，使代碼得到更好的維護。

• 我們把對數據庫的交互放在了各個(gè)服務(wù)中心，讓”前端“的web應用更注重與瀏覽器交互的工作。

問(wèn)題：

1. 如何進(jìn)行遠程的服務(wù)調用

解決方法：

1. 我們可以通過(guò)下面的引入消息中間件來(lái)解決

階段九：引入消息中間件

隨著(zhù)網(wǎng)站的繼續發(fā)展，我們的系統中可能出現不同語(yǔ)言開(kāi)發(fā)的子模塊和部署在不同平臺的子系統。此時(shí)我們需要一個(gè)平臺來(lái)傳遞可靠的，與平臺和語(yǔ)言無(wú)關(guān)的數據，并且能夠把負載均衡透明化，能在調用過(guò)程中收集調用數據并分析之，推測出網(wǎng)站的訪(fǎng)問(wèn)增長(cháng)率等等一系列需求，對于網(wǎng)站應該如何成長(cháng)做出預測。開(kāi)源消息中間件有阿里的dubbo，可以搭配Google開(kāi)源的分布式程序協(xié)調服務(wù)zookeeper實(shí)現服務(wù)器的注冊與發(fā)現。

總結
可以說(shuō)同樣是網(wǎng)站，既可以是簡(jiǎn)單的簡(jiǎn)單的單機構建網(wǎng)站，也可以是復雜的服務(wù)體系。愛(ài)用建站致力于通過(guò)穩定的SAAS云服務(wù)以及先進(jìn)應用架構，為企業(yè)提供穩定可靠的網(wǎng)站服務(wù)。保障每一次線(xiàn)上商機觸達。