摘要：前言客戶端服務(wù)器的通信會(huì)經(jīng)歷如下幾個(gè)階段客戶端輸入服務(wù)器解析階段服務(wù)器解析請(qǐng)求階段應(yīng)用服務(wù)器邏輯處理階段數(shù)據(jù)庫(kù)操作階段服務(wù)器模版渲染階段服務(wù)器將返回給客戶端解析階段當(dāng)客戶在瀏覽器輸入某個(gè)首先會(huì)經(jīng)歷域名解析階段，即向服務(wù)器解析目標(biāo)返回對(duì)應(yīng)目標(biāo)

客戶端－服務(wù)器的通信會(huì)經(jīng)歷如下幾個(gè)階段:

客戶端輸入U(xiǎn)RL

DNS服務(wù)器解析URL階段

Web服務(wù)器解析Http請(qǐng)求階段

應(yīng)用服務(wù)器邏輯處理階段

數(shù)據(jù)庫(kù)操作階段

Web服務(wù)器模版渲染階段

Web服務(wù)器將Html返回給客戶端

當(dāng)客戶在瀏覽器輸入某個(gè)URL, 首先會(huì)經(jīng)歷域名解析階段，即向DNS服務(wù)器解析目標(biāo)URL返回對(duì)應(yīng)目標(biāo)URL的Ip地址，再根據(jù)這個(gè)目標(biāo)Ip地址請(qǐng)起對(duì)應(yīng)的服務(wù)器.比如在瀏覽器中輸入www.xx.yy.com后，

瀏覽器在本地緩存查找www.xx.yy.com對(duì)應(yīng)的IP，如果沒(méi)找到

向DNS服務(wù)器請(qǐng)求www.xx.yy.com對(duì)應(yīng)的IP,如果DNS服務(wù)器解析不出來(lái)

向更上一級(jí)DNS服務(wù)器請(qǐng)求www.xx.yy.com對(duì)應(yīng)的IP,如果DNS服務(wù)器解析不出來(lái)

向更上一級(jí)DNS服務(wù)器請(qǐng)求www.xx.yy.com對(duì)應(yīng)的IP,直到給客戶端返回對(duì)應(yīng)的IP(192.0.0.1)

用戶向www.xx.yy.com對(duì)應(yīng)的IP地址發(fā)送Http請(qǐng)求(192.0.0.1)

客戶端得到對(duì)應(yīng)的IP之后，就可以和web服務(wù)器進(jìn)行正式的交互了

客戶端－(web+應(yīng)用)服務(wù)器－數(shù)據(jù)庫(kù)

客戶端向服務(wù)器發(fā)起Http請(qǐng)求

服務(wù)器中的web服務(wù)層能夠處理Http請(qǐng)求

服務(wù)器中的應(yīng)用層部分能夠調(diào)用業(yè)務(wù)邏輯，調(diào)用業(yè)務(wù)邏輯上的方法

如果有必要，服務(wù)器會(huì)和數(shù)據(jù)庫(kù)進(jìn)行數(shù)據(jù)交換. 然后將模版＋數(shù)據(jù)渲染成最終的Html, 返送給客戶端

客戶端－web服務(wù)器－應(yīng)用服務(wù)器－數(shù)據(jù)庫(kù)

類似模型1，只是將web服務(wù)和應(yīng)用服務(wù)解耦

客戶端向web服務(wù)器發(fā)起Http請(qǐng)求

web服務(wù)能夠處理Http請(qǐng)求，并且調(diào)用應(yīng)用服務(wù)器暴露在外的RESTFUL接口

應(yīng)用服務(wù)器的RESTFUL接口被調(diào)用，會(huì)執(zhí)行對(duì)應(yīng)的暴露方法.如果有必要和數(shù)據(jù)庫(kù)進(jìn)行數(shù)據(jù)交互，應(yīng)用服務(wù)器會(huì)和數(shù)據(jù)庫(kù)進(jìn)行交互后，將json數(shù)據(jù)返回給web服務(wù)器

web服務(wù)器將模版＋數(shù)據(jù)組合渲染成html返回給客戶端

客戶端－負(fù)載均衡器(Nginx)－中間服務(wù)器(Node)－應(yīng)用服務(wù)器－數(shù)據(jù)庫(kù)

整正暴露在外的不是真正web服務(wù)器的地址，而是負(fù)載均衡器器的地址

客戶向負(fù)載均衡器發(fā)起Http請(qǐng)求

負(fù)載均衡器能夠?qū)⒖蛻舳说腍ttp請(qǐng)求均勻的轉(zhuǎn)發(fā)給Node服務(wù)器集群

Node服務(wù)器接收到Http請(qǐng)求之后，能夠?qū)ζ溥M(jìn)行解析，并且能夠調(diào)用應(yīng)用服務(wù)器暴露在外的RESTFUL接口

應(yīng)用服務(wù)器的RESTFUL接口被調(diào)用，會(huì)執(zhí)行對(duì)應(yīng)的暴露方法.如果有必要和數(shù)據(jù)庫(kù)進(jìn)行數(shù)據(jù)交互，應(yīng)用服務(wù)器會(huì)和數(shù)據(jù)庫(kù)進(jìn)行交互后，將json數(shù)據(jù)返回給Node

Node層將模版＋數(shù)據(jù)組合渲染成html返回反向代理服務(wù)器

反向代理服務(wù)器將對(duì)應(yīng)html返回給客戶端

注意

首先來(lái)明晰一下Nginx概念. Nginx的優(yōu)點(diǎn)有: 作為反向代理能夠起到負(fù)載均衡的作用, 負(fù)載均衡就是能夠承受、高并發(fā)的大量的請(qǐng)求，然后將這些請(qǐng)求均勻的轉(zhuǎn)發(fā)給內(nèi)部的服務(wù)器，分?jǐn)倝毫? 并且反向代理能夠解決跨域引起的問(wèn)題，因?yàn)镹ginx，Node,應(yīng)用服務(wù)器，數(shù)據(jù)庫(kù)都在內(nèi)網(wǎng)段呀. 并且，Nginx非常擅長(zhǎng)處理靜態(tài)資源(img,css,js,video)，所以也經(jīng)常作為靜態(tài)資源服務(wù)器，也叫做CDN

特別的，前一個(gè)用戶訪問(wèn)index.html, 經(jīng)過(guò)Nginx－Node－應(yīng)用服務(wù)器－數(shù)據(jù)庫(kù)鏈路之后，Nginx會(huì)把index.html返回給用戶，并且會(huì)把index.html緩存在Nginx上

下一個(gè)用戶再想請(qǐng)求index.html的時(shí)候，請(qǐng)求Nginx服務(wù)器，Nginx發(fā)現(xiàn)有index.html的緩存，于是就不用去請(qǐng)求Node層了，會(huì)直接將緩存的頁(yè)面(如果沒(méi)過(guò)期的話)返回給用戶.

客戶端 - (靜態(tài)資源服務(wù)器CDN,負(fù)載均衡服務(wù)器Nginx)-中間服務(wù)器(Node)－應(yīng)用服務(wù)器－數(shù)據(jù)庫(kù)

客戶端的靜態(tài)請(qǐng)求(images,css,js等)全部走CDN

客戶端的動(dòng)態(tài)請(qǐng)求(html頁(yè)面上的數(shù)據(jù)需要從數(shù)據(jù)庫(kù)中取，而且需要邏輯處理)就走負(fù)載均衡器Nginx(反向代理)

比如針對(duì)頁(yè)面www.xx.yy.com/index.html來(lái)說(shuō),

客戶在瀏覽器中輸入www.xx.yy.com/index.html, 瀏覽器會(huì)查找本地DNS緩存試著找到該URL Hostname對(duì)應(yīng)的IP

如果本地沒(méi)有找到，瀏覽器會(huì)發(fā)送請(qǐng)求到最低層的DNS服務(wù)器，期望得到該URL對(duì)應(yīng)的IP

最低層DNS服務(wù)器解析該域名，如果解析不了，會(huì)再往高一級(jí)的DNS服務(wù)器發(fā)送請(qǐng)求，期望得到該URL對(duì)應(yīng)的IP,如此遞歸向上查詢，直到找到該URL對(duì)應(yīng)的域名，然后逐級(jí)向下返回給客戶端

客戶端拿到對(duì)應(yīng)的IP, 開(kāi)始向該地址發(fā)送Http請(qǐng)求.

其實(shí)這個(gè)IP就是nginx服務(wù)器的IP地址

Nginx服務(wù)器接收到客戶端的Http請(qǐng)求后，會(huì)根據(jù)調(diào)度算法轉(zhuǎn)發(fā)給合適的空閑的Node服務(wù)器

Node服務(wù)器接收到Http請(qǐng)求之后，能夠?qū)ζ溥M(jìn)行解析，并且能夠調(diào)用應(yīng)用服務(wù)器暴露在外的RESTFUL接口

應(yīng)用服務(wù)器的RESTFUL接口被調(diào)用，會(huì)執(zhí)行對(duì)應(yīng)的暴露方法.如果有必要和數(shù)據(jù)庫(kù)進(jìn)行數(shù)據(jù)交互，應(yīng)用服務(wù)器會(huì)和數(shù)據(jù)庫(kù)進(jìn)行交互后，將json數(shù)據(jù)返回給Node

Node層將模版＋數(shù)據(jù)組合渲染成html返回反向代理服務(wù)器

Nginx服務(wù)器將對(duì)應(yīng)html返回給客戶端

客戶端拿到的index.html如下

...
...
21

...

客戶端開(kāi)始解析index.html, 發(fā)現(xiàn)了img標(biāo)簽，于是得向cdn.xx.xx請(qǐng)求1.png

客戶端想得到cdn.xx.xx這個(gè)域名的IP, 于是查找本地DNS緩存

如果沒(méi)有緩存，于是向最低層DNS服務(wù)器發(fā)起域名解析，期望得到cdn.xx.xx對(duì)應(yīng)的IP

DNS服務(wù)器收到請(qǐng)求，發(fā)現(xiàn)用戶的Http-header里請(qǐng)求的是cdn.xx.xx，請(qǐng)求的是一個(gè)CDN服務(wù)器(其實(shí)是一個(gè)分散的集群)的IP地址. 于是DNS會(huì)動(dòng)態(tài)計(jì)算，這個(gè)域名對(duì)應(yīng)的CDN服務(wù)器集群，哪一臺(tái)服務(wù)器離用戶更近更快更合適

DNS服務(wù)器計(jì)算出最合適的CDN服務(wù)器IP之后，將該IP返回給客戶端

客戶端向這個(gè)IP請(qǐng)求靜態(tài)資源.

注意:

為什么CDN服務(wù)能夠極大地提高用戶請(qǐng)求靜態(tài)資源的效率?

就是因?yàn)槟阏?qǐng)求的CDN服務(wù)器URL對(duì)應(yīng)的IP是經(jīng)過(guò)了DNS服務(wù)器的計(jì)算得出的最優(yōu)解. 當(dāng)DNS服務(wù)器收到用戶的域名解析請(qǐng)求的時(shí)候，如果發(fā)現(xiàn)用戶請(qǐng)求的是CDN服務(wù)器集群的域名，那么DNS會(huì)根據(jù)用戶所在IP地址計(jì)算，找到離用戶最近的／網(wǎng)絡(luò)狀況最好的 CDN服務(wù)器對(duì)應(yīng)的IP地址，返回給客戶端.

其實(shí)，這和異地多機(jī)房部署是一個(gè)原理
很多大公司服務(wù)器一般會(huì)分南北兩個(gè)集群. 比如一個(gè)集群在廣州，一個(gè)集群在北京. 那么當(dāng)用戶訪問(wèn)該公司的URL的時(shí)候，首先肯定會(huì)向DNS服務(wù)器請(qǐng)求該URL Hostname對(duì)應(yīng)的IP地址. DNS服務(wù)器會(huì)根據(jù)該用戶的IP，來(lái)判斷到底是返回廣州地區(qū)服務(wù)器的IP，還是北京地區(qū)服務(wù)器的IP
如果用戶當(dāng)前的IP段是在天津，DNS就會(huì)將北京服務(wù)器的IP地址返回給客戶. 如果用戶當(dāng)前IP段在深圳，DNS服務(wù)器就會(huì)返回深圳服務(wù)器的IP給用戶. 這樣極大的提高了服務(wù)器的響應(yīng)速度(試想一下如果你在北京，你家對(duì)面就是該公司北京服務(wù)器的機(jī)房.但你發(fā)現(xiàn)自己的請(qǐng)求卻最終被發(fā)到了廣州機(jī)房，這是多么蛋疼的一件事情)
并且，不僅僅是提高服務(wù)器的響應(yīng)效率，多機(jī)房部署對(duì)于容災(zāi)等等也是必要的（萬(wàn)一廣州的機(jī)房失火了斷電了，公司可以去配置DNS服務(wù)器，不管用戶在那個(gè)IP段，都返回北京機(jī)房的IP地址,這樣就整個(gè)南方片區(qū)的請(qǐng)求只是變慢了而已，不至于全部癱瘓)

懶得更新了.最后上一張稍微復(fù)雜點(diǎn)的架構(gòu)圖醒醒腦吧