李旗

【摘要】? ? 在科技時代所賦予的挑戰(zhàn)面前，以信息化數(shù)字化賦能產(chǎn)業(yè)發(fā)展，實現(xiàn)企業(yè)數(shù)字化轉(zhuǎn)型，是各行業(yè)的當(dāng)務(wù)之急。企業(yè)快速上云，依托智能化手段提質(zhì)增效，也是企業(yè)發(fā)展的關(guān)鍵所在。而各領(lǐng)域的企業(yè)應(yīng)用從傳統(tǒng)的局域網(wǎng)環(huán)境遷移至云上后出現(xiàn)一些新的狀況，如經(jīng)常有用戶反饋“本來好好的系統(tǒng)，為何上云后就變慢了呢？”筆者發(fā)現(xiàn)企業(yè)應(yīng)用上云的過程中，往往未做詳細調(diào)研，忽視應(yīng)用架構(gòu)的調(diào)整適應(yīng)，在云部署工作中生搬硬套地使用了局域網(wǎng)環(huán)境的方法，這會引起意料之外的問題;其中有何需要關(guān)注的呢？在本文中，筆者將運用兩個實際案例，講解關(guān)注應(yīng)用架構(gòu)對優(yōu)化云業(yè)務(wù)效率的意義所在。

【關(guān)鍵詞】? ? 上云? ? 適應(yīng)性? ? 企業(yè)

一、案例一：某醫(yī)院業(yè)務(wù)上云后問題排查

1.1 背景

客戶的業(yè)務(wù)遷移到移動云后，出現(xiàn)較大的延遲情況;客戶打開業(yè)務(wù)系統(tǒng)非常緩慢，之前服務(wù)端部署在該醫(yī)院內(nèi)網(wǎng)環(huán)境中，打開系統(tǒng)只需要1秒;而上云后約要30秒左右才能打開頁面，用戶嚴(yán)重懷疑移動云網(wǎng)絡(luò)或主機性能瓶頸，需要移動云管理人員盡快解決該故障;

附：前期排查進展：1.客戶側(cè)時延為30ms左右，為安徽-->上海資源池;2.通過fiddler抓到請求，發(fā)現(xiàn)客戶的應(yīng)用為CS架構(gòu)，客戶端訪問云端的是SQL 數(shù)據(jù)庫業(yè)務(wù)。

1.2 分析過程

1.2.1網(wǎng)絡(luò)傳輸質(zhì)量評估

從局域網(wǎng)環(huán)境中抓包，以及在云環(huán)境中提取訪問過程的數(shù)據(jù)，放在回溯系統(tǒng)上進行比較，圖1左邊是服務(wù)端再局域網(wǎng)內(nèi)的訪問過程，右邊的視圖是用戶通過專線訪問部署在云上的業(yè)務(wù)系統(tǒng)的訪問過程。

這兩組會話，均沒有丟包重傳，網(wǎng)絡(luò)延遲也很穩(wěn)定，訪問同一個業(yè)務(wù)產(chǎn)生的數(shù)據(jù)報文均為1580個包左右，其中客戶端向服務(wù)端發(fā)送了765次請求，服務(wù)端都回復(fù)了數(shù)據(jù)。

這兩個唯一的區(qū)別，內(nèi)網(wǎng)的網(wǎng)絡(luò)延遲為0.8ms，云中的網(wǎng)絡(luò)延遲為25ms;這點可以從圖1 TCP三次握手過程可以看到。

1.2.2交互過程分析

平時訪問游戲、主流的網(wǎng)頁，網(wǎng)絡(luò)延遲50ms以下都算不錯了;而這個醫(yī)院用戶部署在移動云內(nèi)的應(yīng)用，在其訪問過程中的網(wǎng)絡(luò)延遲為25ms，應(yīng)該屬于“優(yōu)秀水平”。

咋眼看去似乎25ms比0.8ms也沒大多少，對吧？其實不然，請看圖2。

如圖2右邊的交互視圖中可以看到，從第4個包開始，客戶端向服務(wù)端發(fā)起了第一次請求，每次新的請求，距離上一次應(yīng)答的時間約為25.9ms至38.9ms之間;而左邊的交互視圖中，每次的應(yīng)答時間距離上一次應(yīng)答的時間約為0.8ms至5ms之間;如此，經(jīng)過765次的請求和應(yīng)答后，會話的結(jié)束過程如下圖3所示。

圖3中左邊，局域網(wǎng)內(nèi)傳輸1580個包，用了1.05秒就完成這個過程;而從右邊的視圖中可以看到，一次訪問需要約765次的請求和應(yīng)答的前提下，經(jīng)過每次25ms至30ms的“加持”，總的過程經(jīng)歷了21秒后才完成了相同的過程。

1.3 小結(jié)與建議

1.3.1小結(jié)

用戶的業(yè)務(wù)采用CS架構(gòu)：①客戶-->② CS客戶端-->③SQL服務(wù)端，上述②和③之間，每次業(yè)務(wù)打開和運行的時候均需要有大量的數(shù)據(jù)交互;當(dāng)業(yè)務(wù)在同個局域網(wǎng)運行，其中的延遲用戶也許近似無法感知。不過把“③SQL服務(wù)端”架設(shè)在移動云上之后，用戶感受到的延遲就呈現(xiàn)數(shù)量級的上升，延遲上升的幅度取決于業(yè)務(wù)交互的次數(shù)。

1.3.2優(yōu)化建議

1.初步建議用戶調(diào)整數(shù)據(jù)庫部署的資源池，如果遷移到淮南節(jié)點，理論上網(wǎng)絡(luò)延遲降到10ms之內(nèi)，用戶打開業(yè)務(wù)的時間，可從20+秒減少至10秒以下;

2.建議用戶調(diào)整業(yè)務(wù)的訪問邏輯關(guān)系，采用BS的架構(gòu);或者CS架構(gòu)中，客戶-->應(yīng)用-->數(shù)據(jù)庫的業(yè)務(wù)流程中，應(yīng)用和數(shù)據(jù)庫同時上云，就能徹底解決延遲的問題。

二、案例二：某資源池用戶和阿里云間調(diào)用postman問題分析

2.1 背景

客戶的部分業(yè)務(wù)遷移到移動云后，出現(xiàn)較大的延遲情況;如下圖所示，客戶部署在杭州阿里云IP地址為47.xx.xxx.22的業(yè)務(wù)訪問已遷移至移動云雅安節(jié)點IP地址為36.xx.xxx.65（tcp）的業(yè)務(wù)過程中，發(fā)現(xiàn)移動云響應(yīng)杭州阿里這個地址的時候比較慢，達到14.78秒。

網(wǎng)絡(luò)環(huán)境和業(yè)務(wù)流程：

圖4

2.2 分析過程

1.從移動云的回溯系統(tǒng)中調(diào)取數(shù)據(jù)，經(jīng)分析后可見用戶反饋訪問慢的時間段內(nèi)，移動云和阿里云IP為47.96.119.93的地址間產(chǎn)生了接近300KB的流量，峰值流量約為200Kbps，持續(xù)了15秒左右，如圖5所示。

2.從22：23：27開始，看到阿里云IP 47.xx.xxx.93向移動云內(nèi)網(wǎng)IP 10.xx.xxx.17 POST了164次http：// yunnan.xxxxxxxx.com：81/zsa/......的請求，移動云每次均回復(fù)200 OK，服務(wù)端回復(fù)的延遲都很快，均低于0.01秒;最后一次訪問過程的結(jié)束時間為22：23：41，從第一次開始訪問至末次訪問結(jié)束剛好14秒多。（圖6）

3.而在這164的請求響應(yīng)過程中，每次請求間隔大約為0.09秒，從圖7中的“日期時間”可見。

4.進一步分析每次訪問的過程，這些請求響應(yīng)表現(xiàn)相近，均如圖8所示。

圖8

關(guān)于圖8中的三次握手和四次揮手，稍微延伸解釋一下，端到端的通信過程中為了建立TCP連接，通信雙方必須從對方了解這些信息：1）對方報文發(fā)送的開始序號。2）對方發(fā)送數(shù)據(jù)的緩沖區(qū)大小。3）能被接收的最大報文段長度MSS。4）被支持的TCP選項。因此雙方通過三次TCP報文實現(xiàn)對以上信息的了解，并在此基礎(chǔ)上建立一個TCP連接;而通信雙方的三次TCP報文的交換過程，也就是通常所說的TCP連接建立實現(xiàn)的三次握手（Three-Way Handshake）過程。

由于TCP連接是全雙工的，因此每個方向都必須單獨進行關(guān)閉。這個原則是當(dāng)一方完成它的數(shù)據(jù)發(fā)送任務(wù)后就能發(fā)送一個FIN來終止這個方向的連接。收到一個 FIN只意味著這一方向上沒有數(shù)據(jù)流動，一個TCP連接在收到一個FIN后仍能發(fā)送數(shù)據(jù)。首先進行關(guān)閉的一方將執(zhí)行主動關(guān)閉，而另一方執(zhí)行被動關(guān)閉。這就是通常所說的“四次揮手”的過程。

因為篇幅關(guān)系，關(guān)于三次握手和四次揮手的交互細節(jié)，在本文中筆者不展開講述。

如之前的會話交互所示，建立會話時間和結(jié)束會話的總時間為0.08秒左右;會話各環(huán)節(jié)的時間占比如右圖所示：

三次握手和四次揮手，均和網(wǎng)絡(luò)延遲有關(guān)，從阿里云到移動云之間的網(wǎng)絡(luò)延遲為39ms左右。（圖9）

每次請求都需要新建一次TCP會話，每次新的會話都需要等上一次的會話結(jié)束才能開始。

2.3 小結(jié)與建議

2.3.1小結(jié)

從上文的分析過程可得，在現(xiàn)有的應(yīng)用架構(gòu)中，每次的業(yè)務(wù)操作，需要分解為很多次的HTTP短鏈接，而短鏈接狀態(tài)中每一個會話持續(xù)時間0.09（秒） X 164（次） = 14.76秒，這就是導(dǎo)致部分業(yè)務(wù)遷移到移動云后，調(diào)用阿里云接口慢（14.78秒）的主要原因。

2.3.2優(yōu)化建議

根據(jù)交互內(nèi)容，建議應(yīng)用采用長連接，減少不必要的網(wǎng)絡(luò)建鏈和拆鏈過程，可有效降低時延。

2.3.3說明

在HTTP/1.0中默認(rèn)使用短連接。也就是說，客戶端和服務(wù)器每進行一次HTTP操作，就建立一次連接，任務(wù)結(jié)束就中斷連接。當(dāng)客戶端瀏覽器訪問的某個HTML或其他類型的Web頁中包含有其他的Web資源（如JavaScript文件、圖像文件、CSS文件等），每遇到這樣一個Web資源，瀏覽器就會重新建立一個HTTP會話。而從HTTP/1.1起，默認(rèn)使用長連接，用以保持連接特性。使用長連接的HTTP協(xié)議，會在響應(yīng)頭加入這段代碼：Connection：keep-alive;在使用長連接的情況下，當(dāng)一個網(wǎng)頁打開完成后，客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會關(guān)閉，客戶端再次訪問這個服務(wù)器時，會繼續(xù)使用這一條已經(jīng)建立的連接。Keep-Alive不會永久保持連接，它有一個保持時間，可以在不同的服務(wù)器軟件（如Apache）中設(shè)定這個時間。實現(xiàn)長連接需要客戶端和服務(wù)端都支持長連接。HTTP協(xié)議的長連接和短連接，實質(zhì)上是TCP協(xié)議的長連接和短連接。

2.4 優(yōu)化后效果評估

經(jīng)管理人員與研發(fā)人員討論后，對業(yè)務(wù)模式做了調(diào)整，用戶采用了長連接的會話方式調(diào)用移動云;后續(xù)對該業(yè)務(wù)進行跟蹤分析， 如圖10所示，修改后無數(shù)據(jù)交互時，阿里云IP47.xx.xxx.22和云主機10.xx.xxx.123之間，每隔4.95秒進行一次數(shù)據(jù)同步，維持會話的長連接狀態(tài)。

圖10

有業(yè)務(wù)產(chǎn)生的時候，客戶端直接調(diào)用移動云接口時，會通過47.xx.xxx.22的9333端口直接訪問移動云主機，這時候，只有兩個TCP會話產(chǎn)生數(shù)據(jù)產(chǎn)生。（圖11）

阿里云IP一次性把所有數(shù)據(jù)傳到移動云主機。（圖12）

這樣的調(diào)用效率高，所以延遲就比較低，用戶體驗明顯提升，而記錄到的時間延遲也大幅度降低了（從14.78秒減少至1.479秒）。（圖13）

三、結(jié)束語

在前文章節(jié)中的兩個案例，筆者作為主要分析人員參與了故障定位與優(yōu)化的過程，從而體會非常深刻，網(wǎng)絡(luò)延遲從局域網(wǎng)的“1毫秒”到互聯(lián)網(wǎng)的“30毫秒”，雖然只是增加了29毫秒，然而這短短的“29毫秒”，經(jīng)過交互次數(shù)的乘法后，對業(yè)務(wù)的開展影響竟然如此巨大。

本文案例一讓我們明白，“客戶-->應(yīng)用-->數(shù)據(jù)庫”的流程中，“應(yīng)用”和“數(shù)據(jù)庫”必須同時上云，通過減少長距離的交互次數(shù)，可有效降低業(yè)務(wù)延遲，如圖14所示。

本文案例二讓我們明白，業(yè)務(wù)拆分或者部分應(yīng)用上云后，如果拆分部分的交互次數(shù)較多的情況下，應(yīng)用的連接方式需從短鏈接長連接，通過減少不必要的網(wǎng)絡(luò)建鏈和拆鏈過程，可有效降低業(yè)務(wù)的整體時延。

兩個案例產(chǎn)生的根因是相同的：多次交互+單次延遲增加。

筆者建議企業(yè)應(yīng)用在上云的過程中，做好調(diào)研工作，特別需要關(guān)注業(yè)務(wù)的邏輯關(guān)系和產(chǎn)生數(shù)據(jù)的交互過程，必要的情況下，適度調(diào)整應(yīng)用架構(gòu)以適應(yīng)云環(huán)境的使用。