切圖崽的自我修養—[HTTP] 常見B/S架構簡單梳理

前言

客戶端－服務器的通訊會經歷以下幾個階段:

1. 客戶端輸入URL

2. DNS服務器解析URL階段

3. Web服務器解析Http請求階段

4. 應用服務器邏輯處理階段

5. 數據庫操做階段

6. Web服務器模版渲染階段

7. Web服務器將Html返回給客戶端

---

解析URL階段

當客戶在瀏覽器輸入某個URL, 首先會經歷域名解析階段，即向DNS服務器解析目標URL返回對應目標URL的Ip地址，再根據這個目標Ip地址請起對應的服務器.好比在瀏覽器中輸入www.xx.yy.com後，

1. 瀏覽器在本地緩存查找www.xx.yy.com對應的IP，若是沒找到

2. 向DNS服務器請求www.xx.yy.com對應的IP,若是DNS服務器解析不出來

3. 向更上一級DNS服務器請求www.xx.yy.com對應的IP,若是DNS服務器解析不出來

4. 向更上一級DNS服務器請求www.xx.yy.com對應的IP,直到給客戶端返回對應的IP(192.0.0.1)

5. 用戶向www.xx.yy.com對應的IP地址發送Http請求(192.0.0.1)

---

客戶端獲得對應的IP以後，就能夠和web服務器進行正式的交互了

---

模型1

客戶端－(web+應用)服務器－數據庫

1. 客戶端向服務器發起Http請求

2. 服務器中的web服務層可以處理Http請求

3. 服務器中的應用層部分可以調用業務邏輯，調用業務邏輯上的方法

4. 若是有必要，服務器會和數據庫進行數據交換. 而後將模版＋數據渲染成最終的Html, 返送給客戶端

---

模型2

客戶端－web服務器－應用服務器－數據庫

相似模型1，只是將web服務和應用服務解耦

1. 客戶端向web服務器發起Http請求

2. web服務可以處理Http請求，而且調用應用服務器暴露在外的RESTFUL接口

3. 應用服務器的RESTFUL接口被調用，會執行對應的暴露方法.若是有必要和數據庫進行數據交互，應用服務器會和數據庫進行交互後，將json數據返回給web服務器

4. web服務器將模版＋數據組合渲染成html返回給客戶端

---

模型3

客戶端－負載均衡器(Nginx)－中間服務器(Node)－應用服務器－數據庫

1. 整正暴露在外的不是真正web服務器的地址，而是負載均衡器器的地址

2. 客戶向負載均衡器發起Http請求

3. 負載均衡器可以將客戶端的Http請求均勻的轉發給Node服務器集羣

4. Node服務器接收到Http請求以後，可以對其進行解析，而且可以調用應用服務器暴露在外的RESTFUL接口

5. 應用服務器的RESTFUL接口被調用，會執行對應的暴露方法.若是有必要和數據庫進行數據交互，應用服務器會和數據庫進行交互後，將json數據返回給Node

6. Node層將模版＋數據組合渲染成html返回反向代理服務器

7. 反向代理服務器將對應html返回給客戶端

注意

1. 首先來明晰一下Nginx概念. Nginx的優勢有: 做爲反向代理可以起到負載均衡的做用, 負載均衡就是可以承受、高併發的大量的請求，而後將這些請求均勻的轉發給內部的服務器，分攤壓力. 而且反向代理可以解決跨域引發的問題，由於Nginx，Node,應用服務器，數據庫都在內網段呀. 而且，Nginx很是擅長處理靜態資源(img,css,js,video)，因此也常常做爲靜態資源服務器，也叫作CDN

2. 特別的，前一個用戶訪問index.html, 通過Nginx－Node－應用服務器－數據庫鏈路以後，Nginx會把index.html返回給用戶，而且會把index.html緩存在Nginx上

3. 下一個用戶再想請求index.html的時候，請求Nginx服務器，Nginx發現有index.html的緩存，因而就不用去請求Node層了，會直接將緩存的頁面(若是沒過時的話)返回給用戶.

---

模型4

客戶端 - (靜態資源服務器CDN,負載均衡服務器Nginx)-中間服務器(Node)－應用服務器－數據庫

1. 客戶端的靜態請求(images,css,js等)所有走CDN

2. 客戶端的動態請求(html頁面上的數據須要從數據庫中取，並且須要邏輯處理)就走負載均衡器Nginx(反向代理)

3. 好比針對頁面www.xx.yy.com/index.html來講,

4. 客戶在瀏覽器中輸入www.xx.yy.com/index.html, 瀏覽器會查找本地DNS緩存試着找到該URL Hostname對應的IP

5. 若是本地沒有找到，瀏覽器會發送請求到最低層的DNS服務器，指望獲得該URL對應的IP

6. 最低層DNS服務器解析該域名，若是解析不了，會再往高一級的DNS服務器發送請求，指望獲得該URL對應的IP,如此遞歸向上查詢，直到找到該URL對應的域名，而後逐級向下返回給客戶端

1. 客戶端拿到對應的IP, 開始向該地址發送Http請求.

2. 其實這個IP就是nginx服務器的IP地址

3. Nginx服務器接收到客戶端的Http請求後，會根據調度算法轉發給合適的空閒的Node服務器

4. Node服務器接收到Http請求以後，可以對其進行解析，而且可以調用應用服務器暴露在外的RESTFUL接口

5. 應用服務器的RESTFUL接口被調用，會執行對應的暴露方法.若是有必要和數據庫進行數據交互，應用服務器會和數據庫進行交互後，將json數據返回給Node

6. Node層將模版＋數據組合渲染成html返回反向代理服務器

7. Nginx服務器將對應html返回給客戶端

1. 客戶端拿到的index.html以下

<!--index.html-->
...
...
<div class="number">21</div>
<img src="Http://cdn.xx.xx/images/1.png">
...

1. 客戶端開始解析index.html, 發現了img標籤，因而得向cdn.xx.xx請求1.png

2. 客戶端想獲得cdn.xx.xx這個域名的IP, 因而查找本地DNS緩存

3. 若是沒有緩存，因而向最低層DNS服務器發起域名解析，指望獲得cdn.xx.xx對應的IP

4. DNS服務器收到請求，發現用戶的Http-header裏請求的是cdn.xx.xx，請求的是一個CDN服務器(實際上是一個分散的集羣)的IP地址. 因而DNS會動態計算，這個域名對應的CDN服務器集羣，哪一臺服務器離用戶更近更快更合適

5. DNS服務器計算出最合適的CDN服務器IP以後，將該IP返回給客戶端

6. 客戶端向這個IP請求靜態資源.

注意:

爲何CDN服務可以極大地提升用戶請求靜態資源的效率?

就是由於你請求的CDN服務器URL對應的IP是通過了DNS服務器的計算得出的最優解. 當DNS服務器收到用戶的域名解析請求的時候，若是發現用戶請求的是CDN服務器集羣的域名，那麼DNS會根據用戶所在IP地址計算，找到離用戶最近的／網絡情況最好的 CDN服務器對應的IP地址，返回給客戶端.

其實，這和異地多機房部署是一個原理
不少大公司服務器通常會分南北兩個集羣. 好比一個集羣在廣州，一個集羣在北京. 那麼當用戶訪問該公司的URL的時候，首先確定會向DNS服務器請求該URL Hostname對應的IP地址. DNS服務器會根據該用戶的IP，來判斷究竟是返回廣州地區服務器的IP，仍是北京地區服務器的IP
若是用戶當前的IP段是在天津，DNS就會將北京服務器的IP地址返回給客戶. 若是用戶當前IP段在深圳，DNS服務器就會返回深圳服務器的IP給用戶. 這樣極大的提升了服務器的響應速度(試想一下若是你在北京，你家對面就是該公司北京服務器的機房.但你發現本身的請求卻最終被髮到了廣州機房，這是多麼蛋疼的一件事情)
而且，不只僅是提升服務器的響應效率，多機房部署對於容災等等也是必要的（萬一廣州的機房失火了斷電了，公司能夠去配置DNS服務器，無論用戶在那個IP段，都返回北京機房的IP地址,這樣就整個南方片區的請求只是變慢了而已，不至於所有癱瘓)

---

結語

懶得更新了.最後上一張稍微複雜點的架構圖醒醒腦吧