大型網(wǎng)站架構(gòu)演變-創(chuàng)新互聯(lián)

1、簡(jiǎn)介

大型網(wǎng)站架構(gòu)的演進(jìn)最開(kāi)始都是由小及大慢慢演變過(guò)來(lái)的，任何一個(gè)好的架構(gòu)都不是設(shè)計(jì)出來(lái)的，是經(jīng)過(guò)業(yè)務(wù)發(fā)展迭代而來(lái)的，這個(gè)觀點(diǎn)我是贊同的。對(duì)于網(wǎng)站架構(gòu)技術(shù)非常有興趣，一直持續(xù)關(guān)注學(xué)習(xí)架構(gòu)技術(shù)，本次想通過(guò)大型網(wǎng)站技術(shù)發(fā)展歷程，剖析大型網(wǎng)站技術(shù)架構(gòu)模式，深入分析大型互聯(lián)網(wǎng)架構(gòu)設(shè)計(jì)。這篇文章我們只關(guān)注架構(gòu)的演變歷程。

通過(guò)電商業(yè)務(wù)為例，該系統(tǒng)的功能有用戶模塊【用戶注冊(cè)和管理】、商品模塊【商品展示和管理】、交易模塊【創(chuàng)建交易和管理】。通過(guò)圖例分析一個(gè)最初從單臺(tái)LAMP怎么發(fā)展到龐大的分布架構(gòu)體系。

創(chuàng)新互聯(lián)服務(wù)緊隨時(shí)代發(fā)展步伐，進(jìn)行技術(shù)革新和技術(shù)進(jìn)步，經(jīng)過(guò)10余年的發(fā)展和積累，已經(jīng)匯集了一批資深網(wǎng)站策劃師、設(shè)計(jì)師、專業(yè)的網(wǎng)站實(shí)施團(tuán)隊(duì)以及高素質(zhì)售后服務(wù)人員，并且完全形成了一套成熟的業(yè)務(wù)流程，能夠完全依照客戶要求對(duì)網(wǎng)站進(jìn)行做網(wǎng)站、成都網(wǎng)站建設(shè)、建設(shè)、維護(hù)、更新和改版，實(shí)現(xiàn)客戶網(wǎng)站對(duì)外宣傳展示的首要目的，并為客戶企業(yè)品牌互聯(lián)網(wǎng)化提供全面的解決方案。

線上系統(tǒng)高可用參考指標(biāo)：

2、架構(gòu)演變歷程

2.1. 第一階段【單機(jī)構(gòu)建網(wǎng)站】

網(wǎng)站程序用到的開(kāi)源框架如maven+spring+struct+hibernate、maven+spring+springmvc+mybatis；網(wǎng)站初期，我們經(jīng)常會(huì)用單機(jī)跑所有的程序和軟件。通常由app server 和DB server組成，如tomcat和mysq；最后通過(guò)JDBC進(jìn)行數(shù)據(jù)庫(kù)的連接和操作。

一般5萬(wàn)pv到30萬(wàn)pv訪問(wèn)量，結(jié)合內(nèi)核參數(shù)調(diào)優(yōu)、web應(yīng)用性能參數(shù)調(diào)優(yōu)、數(shù)據(jù)庫(kù)調(diào)優(yōu)，基本上能夠穩(wěn)定的運(yùn)行。

2.2. 第二階段【應(yīng)用服務(wù)器與數(shù)據(jù)庫(kù)分離】

隨著網(wǎng)站的發(fā)展當(dāng)訪問(wèn)量逐漸增大，服務(wù)器的負(fù)載慢慢提高，系統(tǒng)的壓力越來(lái)越大，響應(yīng)速度越來(lái)越慢，這個(gè)時(shí)候比較明顯的是數(shù)據(jù)庫(kù)和應(yīng)用互相影響，應(yīng)用出問(wèn)題了，數(shù)據(jù)庫(kù)也很容易出現(xiàn)問(wèn)題，而數(shù)據(jù)庫(kù)出問(wèn)題的時(shí)候，應(yīng)用也容易出問(wèn)題。在服務(wù)器還沒(méi)有超載的時(shí)候，我們應(yīng)該提前做好準(zhǔn)備，提升網(wǎng)站的負(fù)載能力。假如我們代碼層面已難以優(yōu)化，在不提高單臺(tái)機(jī)器的性能的情況下，將應(yīng)用和數(shù)據(jù)庫(kù)從物理上分離，增加機(jī)器是一個(gè)不錯(cuò)的方式，不僅可以有效地提高系統(tǒng)的負(fù)載能力，而且性價(jià)比高。此時(shí)我們可以把數(shù)據(jù)庫(kù)、web服務(wù)器拆分開(kāi)來(lái)，這樣不僅提高了單臺(tái)機(jī)器的負(fù)載能力，也提高了容災(zāi)能力。

隨著用戶量的增大、對(duì)帶寬需求的增大、對(duì)CPU處理能力的增大；不足以融合所有用戶的需求了，或者網(wǎng)站業(yè)務(wù)量的需求了。此處很少也不應(yīng)該直接就對(duì)它做負(fù)載均衡式的擴(kuò)展，因?yàn)閿?shù)據(jù)同步很麻。所以我們架構(gòu)擴(kuò)展，不會(huì)上來(lái)就直接做負(fù)載均衡式的每一組組件當(dāng)做一個(gè)整體來(lái)進(jìn)行擴(kuò)展，而是功能上切割 。這個(gè)時(shí)候技術(shù)上沒(méi)有什么新的要求，但你發(fā)現(xiàn)確實(shí)起到效果了，系統(tǒng)又恢復(fù)到以前的響應(yīng)速度了，并且支撐住了更高的流量，并且不會(huì)因?yàn)閿?shù)據(jù)庫(kù)和應(yīng)用形成互相的影響。

2.3. 第三階段【應(yīng)用服務(wù)器負(fù)載均衡】

隨著訪問(wèn)量繼續(xù)增加，單臺(tái)應(yīng)用服務(wù)器已經(jīng)無(wú)法滿足需求了。假設(shè)數(shù)據(jù)庫(kù)服務(wù)器沒(méi)有壓力，我們可以把應(yīng)用服務(wù)器從一臺(tái)變成了兩臺(tái)甚至多臺(tái)，把用戶的請(qǐng)求分散到不同的服務(wù)器中，從而提高負(fù)載能力。此時(shí)我們應(yīng)該選擇一款合適的負(fù)載均衡產(chǎn)品，一般來(lái)講keepalived配合上ipvsadm做負(fù)載均衡，可謂是神器。這一階段是需要掌握更多基礎(chǔ)知識(shí)的關(guān)鍵節(jié)點(diǎn)。以下可以使用DNS解析對(duì)用戶請(qǐng)求做負(fù)載均衡：

需要注意：負(fù)載均衡產(chǎn)品的選擇、負(fù)載均衡算法的選擇、用戶session保持的問(wèn)題、應(yīng)用占用資源的角度選擇合理的服務(wù)器配置。
解決方案：根據(jù)以下技術(shù)特性選擇適合業(yè)務(wù)的產(chǎn)品、技術(shù)。例如nginx+keepalived一臺(tái)服務(wù)器、apache+tomcat一臺(tái)服務(wù)器、mysql一臺(tái)服務(wù)器。

三種負(fù)載均衡器的優(yōu)缺點(diǎn)說(shuō)明如下：摘自（互聯(lián)網(wǎng)）
LVS的優(yōu)點(diǎn)：
1、抗負(fù)載能力強(qiáng)、工作在第4層僅作分發(fā)之用，沒(méi)有流量的產(chǎn)生，這個(gè)特點(diǎn)也決定了它在負(fù)載均衡軟件里的性能最強(qiáng)的；無(wú)流量，同時(shí)保證了均衡器IO的性能不會(huì)受到大流量的影響；
2、工作穩(wěn)定，自身有完整的雙機(jī)熱備方案，如LVS+Keepalived和LVS+Heartbeat；
3、應(yīng)用范圍比較廣，可以對(duì)所有應(yīng)用做負(fù)載均衡；
4、配置性比較低，這是一個(gè)缺點(diǎn)也是一個(gè)優(yōu)點(diǎn)，因?yàn)闆](méi)有可太多配置的東西，所以并不需要太多接觸，大大減少了人為出錯(cuò)的幾率；
LVS的缺點(diǎn)：
1、軟件本身不支持正則處理，不能做動(dòng)靜分離，這就凸顯了Nginx/HAProxy+Keepalived的優(yōu)勢(shì)。
2、如果網(wǎng)站應(yīng)用比較龐大，LVS/DR+Keepalived就比較復(fù)雜了，特別是后面有Windows Server應(yīng)用的機(jī)器，實(shí)施及配置還有維護(hù)過(guò)程就比較麻煩，相對(duì)而言，Nginx/HAProxy+Keepalived就簡(jiǎn)單多了。

Nginx的優(yōu)點(diǎn)：
1、工作在OSI第7層，可以針對(duì)http應(yīng)用做一些分流的策略。比如針對(duì)域名、目錄結(jié)構(gòu)。它的正則比HAProxy更為強(qiáng)大和靈活；
2、Nginx對(duì)網(wǎng)絡(luò)的依賴非常小，理論上能ping通就就能進(jìn)行負(fù)載功能，這個(gè)也是它的優(yōu)勢(shì)所在；
3、Nginx安裝和配置比較簡(jiǎn)單，測(cè)試起來(lái)比較方便；
4、可以承擔(dān)高的負(fù)載壓力且穩(wěn)定，一般能支撐超過(guò)幾萬(wàn)次的并發(fā)量；
5、Nginx可以通過(guò)端口檢測(cè)到服務(wù)器內(nèi)部的故障，比如根據(jù)服務(wù)器處理網(wǎng)頁(yè)返回的狀態(tài)碼、超時(shí)等等，并且會(huì)把返回錯(cuò)誤的請(qǐng)求重新提交到另一個(gè)節(jié)點(diǎn)；
6、Nginx不僅僅是一款優(yōu)秀的負(fù)載均衡器/反向代理軟件，它同時(shí)也是功能強(qiáng)大的Web應(yīng)用服務(wù)器。LNMP現(xiàn)在也是非常流行的web環(huán)境，大有和LAMP環(huán)境分庭抗禮之勢(shì)，Nginx在處理靜態(tài)頁(yè)面、特別是抗高并發(fā)方面相對(duì)apache有優(yōu)勢(shì)；
7、Nginx現(xiàn)在作為Web反向加速緩存越來(lái)越成熟了，速度比傳統(tǒng)的Squid服務(wù)器更快，有需求的朋友可以考慮用其作為反向代理加速器；
Nginx的缺點(diǎn)：
1、Nginx不支持url來(lái)檢測(cè)。
2、Nginx僅能支持http和Email，這個(gè)它的弱勢(shì)。
3、Nginx的Session的保持，Cookie的引導(dǎo)能力相對(duì)欠缺。

HAProxy的優(yōu)點(diǎn)：
1、HAProxy是支持虛擬主機(jī)的，可以工作在4、7層(支持多網(wǎng)段)；
2、能夠補(bǔ)充Nginx的一些缺點(diǎn)比如Session的保持，Cookie的引導(dǎo)等工作；
3、支持url檢測(cè)后端的服務(wù)器；
4、它跟LVS一樣，本身僅僅就只是一款負(fù)載均衡軟件；單純從效率上來(lái)講HAProxy更會(huì)比Nginx有更出色的負(fù)載均衡速度，在并發(fā)處理上也是優(yōu)于Nginx的；
5、HAProxy可以對(duì)Mysql讀進(jìn)行負(fù)載均衡，對(duì)后端的MySQL節(jié)點(diǎn)進(jìn)行檢測(cè)和負(fù)載均衡，不過(guò)在后端的MySQL slaves數(shù)量超過(guò)10臺(tái)時(shí)性能不如LVS；
6、HAProxy的算法較多，達(dá)到8種；

負(fù)載均衡的基礎(chǔ)技術(shù)：
1、http重定向。HTTP重定向就是應(yīng)用層的請(qǐng)求轉(zhuǎn)發(fā)，用戶的請(qǐng)求到了HTTP重定向負(fù)載均衡服務(wù)器，根據(jù)算法要求用戶重定向，瀏覽器自動(dòng)重新請(qǐng)求實(shí)際服務(wù)器的IP地址。
優(yōu)點(diǎn)：簡(jiǎn)單
缺點(diǎn)：性能較差

2、DNS域名解析負(fù)載均衡。DNS域名解析負(fù)載均衡就是在用戶請(qǐng)求DNS服務(wù)器，獲取域名對(duì)應(yīng)的IP地址時(shí)，DNS服務(wù)器直接解析到負(fù)載均衡后的服務(wù)器IP。
優(yōu)點(diǎn)：使用DNS省心，不用我們?nèi)ゾS護(hù)。
缺點(diǎn)：使用DNS，它不具備故障檢測(cè)功能，DNS解析結(jié)果會(huì)被緩存因此效果一般，DNS負(fù)載均衡多數(shù)為商業(yè)產(chǎn)品，其功能、管理權(quán)限有限。

3、反向代理服務(wù)器。反向代理服務(wù)器轉(zhuǎn)發(fā)的請(qǐng)求在HTTP協(xié)議層面，因此也叫應(yīng)用層負(fù)載均衡。用戶的請(qǐng)求到達(dá)反向代理服務(wù)器，由反向代理服務(wù)器根據(jù)算法轉(zhuǎn)發(fā)到具體的服務(wù)器。反向代理軟件常用的有apache、nginx。
優(yōu)點(diǎn)：部署簡(jiǎn)單。
缺點(diǎn)：反向代理服務(wù)器是所有請(qǐng)求和響應(yīng)的分發(fā)服務(wù)器，其性能可能會(huì)成為瓶頸。特別是上傳大文件。

4、IP層負(fù)載均衡。用戶的請(qǐng)求到達(dá)負(fù)載均衡器后，通過(guò)修改請(qǐng)求的目的IP地址，實(shí)現(xiàn)負(fù)載均衡。代表實(shí)現(xiàn)LVS的NAT模式
優(yōu)點(diǎn)：性能更好。
缺點(diǎn)：負(fù)載均衡器的寬帶成為瓶頸。

5、數(shù)據(jù)鏈路層負(fù)載均衡。用戶的請(qǐng)求到達(dá)負(fù)載均衡器后，通過(guò)修改請(qǐng)求的mac地址，實(shí)現(xiàn)負(fù)載均衡。與IP負(fù)載均衡不同當(dāng)請(qǐng)求訪問(wèn)完服務(wù)器之后，直接返回客戶而無(wú)需再經(jīng)過(guò)負(fù)載均衡器。代表實(shí)現(xiàn)LVS的DR模式

常見(jiàn)的調(diào)度算法：摘自（互聯(lián)網(wǎng)）
1、rr 輪詢調(diào)度算法。顧名思義，輪詢分發(fā)請(qǐng)求。
優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單
缺點(diǎn)：不考慮每臺(tái)服務(wù)器的處理能力

2、wrr 加權(quán)調(diào)度算法。我們給每個(gè)服務(wù)器設(shè)置權(quán)值weight，負(fù)載均衡調(diào)度器根據(jù)權(quán)值調(diào)度服務(wù)器，服務(wù)器被調(diào)用的次數(shù)跟權(quán)值成正比。
優(yōu)點(diǎn)：考慮了服務(wù)器處理能力的不同

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

4、dh 目標(biāo)地址散列：同上，只是現(xiàn)在提取的是目標(biāo)地址的IP來(lái)做哈希。
優(yōu)點(diǎn)：以上兩種算法的都能實(shí)現(xiàn)同一個(gè)用戶訪問(wèn)同一個(gè)服務(wù)器。

5、lc 最少連接。優(yōu)先把請(qǐng)求轉(zhuǎn)發(fā)給連接數(shù)少的服務(wù)器。
優(yōu)點(diǎn)：使得集群中各個(gè)服務(wù)器的負(fù)載更加均勻。

6、wlc 加權(quán)最少連接。在lc的基礎(chǔ)上，為每臺(tái)服務(wù)器加上權(quán)值。算法為：（活動(dòng)連接數(shù)*256+非活動(dòng)連接數(shù)）÷權(quán)重 ，計(jì)算出來(lái)的值小的服務(wù)器優(yōu)先被選擇。
優(yōu)點(diǎn)：可以根據(jù)服務(wù)器的能力分配請(qǐng)求。

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

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

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

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

session會(huì)話保持：
session sticky
ip based
cookie based
session replication
session server

1、Session Sticky。始終將同一個(gè)請(qǐng)求者的連接定向至同一個(gè)RS（第一次請(qǐng)求時(shí)仍由調(diào)度方法選擇）；沒(méi)有容錯(cuò)能力，有損均衡效果。常見(jiàn)的算法有ip_hash法，即上面提到的兩種散列算法。
優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單。
缺點(diǎn)：無(wú)高可用，反均衡。

2、Session Replication。在RS之間同步session，因此每個(gè)RS持集群中所有的session；對(duì)于大規(guī)模集群環(huán)境不適用。
優(yōu)點(diǎn)：減輕負(fù)載均衡服務(wù)器的壓力，可以隨意調(diào)度。
缺點(diǎn)：帶寬、內(nèi)存占用量大，并發(fā)能力有限。

3、Session Server：利用單獨(dú)部署的服務(wù)器來(lái)統(tǒng)一管理session; 實(shí)現(xiàn)了session和應(yīng)用服務(wù)器的解耦。
優(yōu)點(diǎn)：相比session replication的方案，集群間對(duì)于寬帶和內(nèi)存的壓力減少了很多。
缺點(diǎn)：需要維護(hù)存儲(chǔ)session的數(shù)據(jù)庫(kù)。

4、Cookie Base：cookie base就是把session存在cookie中，由瀏覽器來(lái)告訴應(yīng)用服務(wù)器用戶的session是什么，同樣實(shí)現(xiàn)了session和應(yīng)用服務(wù)器的解耦。
優(yōu)點(diǎn)：實(shí)現(xiàn)簡(jiǎn)單，基本免維護(hù)。
缺點(diǎn)：cookie長(zhǎng)度限制，安全性低，寬帶消耗。

應(yīng)用從資源占用的角度分類：
1、CPU Bound 【CPU密集型】一般指aap server
2、IO Bound 【IO密集型】一般指db server

有了以上理論經(jīng)驗(yàn)，根據(jù)業(yè)務(wù)我們可以重新對(duì)架構(gòu)演進(jìn)為以下方案：

2.4. 第四階段【數(shù)據(jù)庫(kù)讀寫(xiě)分離】

前面幾個(gè)階段我們都是假設(shè)后端數(shù)據(jù)庫(kù)負(fù)載沒(méi)問(wèn)題，但隨著訪問(wèn)量的增大，數(shù)據(jù)庫(kù)的負(fù)載也在慢慢增高。那么可能有人馬上想到跟應(yīng)用服務(wù)器一樣，把數(shù)據(jù)庫(kù)一分為二再負(fù)載均衡即可。但對(duì)于數(shù)據(jù)庫(kù)來(lái)說(shuō)，并沒(méi)有那么簡(jiǎn)單。假如我們簡(jiǎn)單的把數(shù)據(jù)庫(kù)一分為二，然后對(duì)于數(shù)據(jù)庫(kù)的請(qǐng)求，分別負(fù)載到A機(jī)器和B機(jī)器，那么顯然會(huì)造成兩臺(tái)數(shù)據(jù)庫(kù)數(shù)據(jù)不一致的問(wèn)題。那么對(duì)于這種情況，我們可以先考慮使用讀寫(xiě)分離的方式。

需要注意：引用MySQL主從勢(shì)必會(huì)面臨的問(wèn)題，數(shù)據(jù)復(fù)制的問(wèn)題、應(yīng)用選擇數(shù)據(jù)源的問(wèn)題
解決方案：使用MySQL自帶的master+slave的方式實(shí)現(xiàn)主從復(fù)制。采用第三方數(shù)據(jù)庫(kù)中間件，例如mycat。mycat是從cobar發(fā)展而來(lái)的。mycat目前是國(guó)內(nèi)比較好的mysql開(kāi)源數(shù)據(jù)庫(kù)分庫(kù)分表中間件。

2.5. 第五階段【引入搜索引擎實(shí)現(xiàn)全文搜索】

MySQL對(duì)于全局搜索能力支持不強(qiáng)，MySQL只對(duì)MyISAM引擎做全文索引但不支持事務(wù)，而MySQL對(duì)InnoDB引擎不支持全文索引。當(dāng)一個(gè)站點(diǎn)到了這一個(gè)階段其用戶搜索量是非常大的。做為一個(gè)電商站點(diǎn)的交易達(dá)成有70%是通過(guò)搜索進(jìn)行的，由此像這種越來(lái)越多的搜索需求使得我們數(shù)據(jù)庫(kù)根本就沒(méi)辦法應(yīng)付這種需要，因?yàn)槊恳淮嗡阉鞫际且淮稳娌樵?，常常?duì)模糊查找力不從心，即使做了讀寫(xiě)分離，這個(gè)問(wèn)題還未能解決。我們要想應(yīng)付這種需求，一般只能自己構(gòu)建搜索引擎來(lái)緩解讀庫(kù)的壓力。

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

2.6. 第六階段【引入緩存】

1、頁(yè)面緩存
web服務(wù)器壓力較大時(shí)，如果讓站點(diǎn)的一部分內(nèi)容能緩存，一部分內(nèi)容不能緩存，我們可以使用ESI動(dòng)態(tài)緩存技術(shù)。web緩存服務(wù)器還可以對(duì)jpg、jpeg、gif、png、html、css、js格式的頁(yè)面做緩存。例如：varnish, squid

2、數(shù)據(jù)緩存
隨著訪問(wèn)量的增加，逐漸出現(xiàn)了許多用戶訪問(wèn)同一部分內(nèi)容的情況，對(duì)于這些比較熱門(mén)的內(nèi)容，沒(méi)必要每次都從數(shù)據(jù)庫(kù)讀取，我們可以使用緩存技術(shù)。例如：memcached, redis

優(yōu)點(diǎn)：減輕數(shù)據(jù)庫(kù)的壓力、大幅度提高訪問(wèn)速度
缺點(diǎn)：需要維護(hù)緩存服務(wù)器、提高了編碼的復(fù)雜性

緩存服務(wù)器集群的調(diào)度算法不同與上面提到的應(yīng)用服務(wù)器和數(shù)據(jù)庫(kù)，最好采用“一致性哈希算法”。

2.7. 第七階段【數(shù)據(jù)庫(kù)拆分】

當(dāng)訪問(wèn)量逐漸增大，單一應(yīng)用增加機(jī)器帶來(lái)的效果不明顯，需要考結(jié)合業(yè)務(wù)考慮數(shù)據(jù)庫(kù)拆分，來(lái)提升系統(tǒng)運(yùn)行效率。我們的網(wǎng)站演進(jìn)到現(xiàn)在，交易、商品、用戶的數(shù)據(jù)都還在同一個(gè)數(shù)據(jù)庫(kù)中。盡管采取了增加緩存，讀寫(xiě)分離的方式，但隨著數(shù)據(jù)庫(kù)的壓力繼續(xù)增加，數(shù)據(jù)庫(kù)的瓶頸越來(lái)越突出，此時(shí)主庫(kù)寫(xiě)操作壓力只能做數(shù)據(jù)庫(kù)拆分，我們可以有垂直拆分和水平拆分兩種選擇。

1、垂直拆分：把數(shù)據(jù)庫(kù)中不同的業(yè)務(wù)的數(shù)據(jù)拆分到不同的數(shù)據(jù)庫(kù)服務(wù)器中。

2、水平拆分：把一個(gè)單獨(dú)的表中的數(shù)據(jù)拆分到多個(gè)不同的數(shù)據(jù)庫(kù)服務(wù)器上。

2.8. 第八階段【應(yīng)用拆分】

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

需要注意：這樣拆分后，可能會(huì)有一些相同的代碼，如用戶相關(guān)的代碼，商品和交易都需要用戶信息，所以在兩個(gè)系統(tǒng)中都保留差不多的操作用戶信息的代碼。如何保證這些代碼可以復(fù)用是一個(gè)需要解決的問(wèn)題。
解決方案：通過(guò)走服務(wù)化的路線來(lái)解決，把公共的服務(wù)拆分出來(lái)，形成一種服務(wù)化的模式，簡(jiǎn)稱SOA。

服務(wù)化之后的系統(tǒng)結(jié)構(gòu)：

需要注意：如何進(jìn)行遠(yuǎn)程的服務(wù)調(diào)用
解決方案：我們可以通過(guò)引入消息中間件來(lái)解決

2.9. 第九階段【引入消息中間件】

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

引入消息中間件后的結(jié)構(gòu)：

3、高性能設(shè)計(jì)

三層架構(gòu)(3-tier architecture) 通常意義上的三層架構(gòu)就是將整個(gè)業(yè)務(wù)應(yīng)用劃分為：界面層（User Interface layer）、業(yè)務(wù)邏輯層（Business Logic Layer）、數(shù)據(jù)訪問(wèn)層（Data access layer）。區(qū)分層次的目的即為了“高內(nèi)聚低耦合”的思想。在軟件體系架構(gòu)設(shè)計(jì)中，分層式結(jié)構(gòu)是最常見(jiàn)，也是最重要的一種結(jié)構(gòu)。微軟推薦的分層式結(jié)構(gòu)一般分為三層，從下至上分別為：數(shù)據(jù)訪問(wèn)層、業(yè)務(wù)邏輯層（又或稱為領(lǐng)域?qū)樱?、表示層。（百度百科?/p>

微服務(wù)的特點(diǎn)：
單一職責(zé)：微服務(wù)中每一個(gè)服務(wù)都對(duì)應(yīng)唯一的業(yè)務(wù)能力，做到單一職責(zé)。
微：微服務(wù)的服務(wù)拆分粒度很小，例如一個(gè)用戶管理就可以作為一個(gè)服務(wù)。每個(gè)服務(wù)雖小，但“五臟俱全”。
面向服務(wù)：面向服務(wù)是說(shuō)每個(gè)服務(wù)都要對(duì)外暴露服務(wù)接口API。并不關(guān)心服務(wù)的技術(shù)實(shí)現(xiàn)，做到與平臺(tái)和語(yǔ)言無(wú)關(guān)，也不限定用什么技術(shù)實(shí)現(xiàn)，只要提供Rest的接口即可。
自治：自治是說(shuō)服務(wù)間互相獨(dú)立，互不干擾
團(tuán)隊(duì)獨(dú)立：每個(gè)服務(wù)都是一個(gè)獨(dú)立的開(kāi)發(fā)團(tuán)隊(duì)，人數(shù)不能過(guò)多。
技術(shù)獨(dú)立：因?yàn)槭敲嫦蚍?wù)，提供Rest接口，使用什么技術(shù)沒(méi)有別人干涉
前后端分離：采用前后端分離開(kāi)發(fā)，提供統(tǒng)一Rest接口，后端不用再為PC、移動(dòng)段開(kāi)發(fā)不同接口
數(shù)據(jù)庫(kù)分離：每個(gè)服務(wù)都使用自己的數(shù)據(jù)源
部署獨(dú)立，服務(wù)間雖然有調(diào)用，但要做到服務(wù)重啟不影響其它服務(wù)。有利于持續(xù)集成和持續(xù)交付。每個(gè)服務(wù)都是獨(dú)立的組件，可復(fù)用，可替換，降低耦合，易維護(hù)。

架構(gòu)優(yōu)化：
? 以用戶為中心，提供快速的網(wǎng)頁(yè)訪問(wèn)體驗(yàn)。主要參數(shù)有較短的響應(yīng)時(shí)間，較大的并發(fā)處理能力，較高的吞吐量，穩(wěn)定的性能參數(shù)；
? 可分為前端優(yōu)化，應(yīng)用層優(yōu)化，代碼層優(yōu)化，存儲(chǔ)層優(yōu)化；
? 前端優(yōu)化：網(wǎng)站業(yè)務(wù)邏輯之前的部分；
? 瀏覽器優(yōu)化：減少Http請(qǐng)求數(shù)，使用瀏覽器緩存，啟用壓縮，Css Js位置，Js異步，減少Cookie傳輸；
? CDN加速，反向代理；
? 應(yīng)用層優(yōu)化：處理網(wǎng)站業(yè)務(wù)的服務(wù)器。使用緩存，異步，集群；
? 代碼優(yōu)化：合理的架構(gòu)，多線程，資源復(fù)用（對(duì)象池，線程池等），良好的數(shù)據(jù)結(jié)構(gòu)，JVM調(diào)優(yōu)，單例，Cache等；
? 存儲(chǔ)優(yōu)化：緩存，固態(tài)硬盤(pán)，光纖傳輸，優(yōu)化讀寫(xiě)，磁盤(pán)冗余，分布式存儲(chǔ)（HDFS），NOSQL等。

另外有需要云服務(wù)器可以了解下創(chuàng)新互聯(lián)scvps.cn，海內(nèi)外云服務(wù)器15元起步，三天無(wú)理由+7*72小時(shí)售后在線，公司持有idc許可證，提供“云服務(wù)器、裸金屬服務(wù)器、高防服務(wù)器、香港服務(wù)器、美國(guó)服務(wù)器、虛擬主機(jī)、免備案服務(wù)器”等云主機(jī)租用服務(wù)以及企業(yè)上云的綜合解決方案，具有“安全穩(wěn)定、簡(jiǎn)單易用、服務(wù)可用性高、性價(jià)比高”等特點(diǎn)與優(yōu)勢(shì)，專為企業(yè)上云打造定制，能夠滿足用戶豐富、多元化的應(yīng)用場(chǎng)景需求。

本文標(biāo)題：大型網(wǎng)站架構(gòu)演變-創(chuàng)新互聯(lián)
分享URL：http://bm7419.com/article6/iphig.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站改版、電子商務(wù)、網(wǎng)站維護(hù)、自適應(yīng)網(wǎng)站、網(wǎng)站排名、App開(kāi)發(fā)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請(qǐng)盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場(chǎng)，如需處理請(qǐng)聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來(lái)源： 創(chuàng)新互聯(lián)