李旗
【摘要】? ? 在科技時(shí)代所賦予的挑戰(zhàn)面前,以信息化數(shù)字化賦能產(chǎn)業(yè)發(fā)展,實(shí)現(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)常有用戶反饋“本來(lái)好好的系統(tǒng),為何上云后就變慢了呢?”筆者發(fā)現(xiàn)企業(yè)應(yīng)用上云的過(guò)程中,往往未做詳細(xì)調(diào)研,忽視應(yīng)用架構(gòu)的調(diào)整適應(yīng),在云部署工作中生搬硬套地使用了局域網(wǎng)環(huán)境的方法,這會(huì)引起意料之外的問(wèn)題;其中有何需要關(guān)注的呢?在本文中,筆者將運(yùn)用兩個(gè)實(shí)際案例,講解關(guān)注應(yīng)用架構(gòu)對(duì)優(yōu)化云業(yè)務(wù)效率的意義所在。
【關(guān)鍵詞】? ? 上云? ? 適應(yīng)性? ? 企業(yè)
一、案例一:某醫(yī)院業(yè)務(wù)上云后問(wèn)題排查
1.1 背景
客戶的業(yè)務(wù)遷移到移動(dòng)云后,出現(xiàn)較大的延遲情況;客戶打開(kāi)業(yè)務(wù)系統(tǒng)非常緩慢,之前服務(wù)端部署在該醫(yī)院內(nèi)網(wǎng)環(huán)境中,打開(kāi)系統(tǒng)只需要1秒;而上云后約要30秒左右才能打開(kāi)頁(yè)面,用戶嚴(yán)重懷疑移動(dòng)云網(wǎng)絡(luò)或主機(jī)性能瓶頸,需要移動(dòng)云管理人員盡快解決該故障;
附:前期排查進(jìn)展:1.客戶側(cè)時(shí)延為30ms左右,為安徽-->上海資源池;2.通過(guò)fiddler抓到請(qǐng)求,發(fā)現(xiàn)客戶的應(yīng)用為CS架構(gòu),客戶端訪問(wèn)云端的是SQL 數(shù)據(jù)庫(kù)業(yè)務(wù)。
1.2 分析過(guò)程
1.2.1網(wǎng)絡(luò)傳輸質(zhì)量評(píng)估
從局域網(wǎng)環(huán)境中抓包,以及在云環(huán)境中提取訪問(wèn)過(guò)程的數(shù)據(jù),放在回溯系統(tǒng)上進(jìn)行比較,圖1左邊是服務(wù)端再局域網(wǎng)內(nèi)的訪問(wèn)過(guò)程,右邊的視圖是用戶通過(guò)專線訪問(wèn)部署在云上的業(yè)務(wù)系統(tǒng)的訪問(wèn)過(guò)程。
這兩組會(huì)話,均沒(méi)有丟包重傳,網(wǎng)絡(luò)延遲也很穩(wěn)定,訪問(wèn)同一個(gè)業(yè)務(wù)產(chǎn)生的數(shù)據(jù)報(bào)文均為1580個(gè)包左右,其中客戶端向服務(wù)端發(fā)送了765次請(qǐng)求,服務(wù)端都回復(fù)了數(shù)據(jù)。
這兩個(gè)唯一的區(qū)別,內(nèi)網(wǎng)的網(wǎng)絡(luò)延遲為0.8ms,云中的網(wǎng)絡(luò)延遲為25ms;這點(diǎn)可以從圖1 TCP三次握手過(guò)程可以看到。
1.2.2交互過(guò)程分析
平時(shí)訪問(wèn)游戲、主流的網(wǎng)頁(yè),網(wǎng)絡(luò)延遲50ms以下都算不錯(cuò)了;而這個(gè)醫(yī)院用戶部署在移動(dòng)云內(nèi)的應(yīng)用,在其訪問(wèn)過(guò)程中的網(wǎng)絡(luò)延遲為25ms,應(yīng)該屬于“優(yōu)秀水平”。
咋眼看去似乎25ms比0.8ms也沒(méi)大多少,對(duì)吧?其實(shí)不然,請(qǐng)看圖2。
如圖2右邊的交互視圖中可以看到,從第4個(gè)包開(kāi)始,客戶端向服務(wù)端發(fā)起了第一次請(qǐng)求,每次新的請(qǐng)求,距離上一次應(yīng)答的時(shí)間約為25.9ms至38.9ms之間;而左邊的交互視圖中,每次的應(yīng)答時(shí)間距離上一次應(yīng)答的時(shí)間約為0.8ms至5ms之間;如此,經(jīng)過(guò)765次的請(qǐng)求和應(yīng)答后,會(huì)話的結(jié)束過(guò)程如下圖3所示。
圖3中左邊,局域網(wǎng)內(nèi)傳輸1580個(gè)包,用了1.05秒就完成這個(gè)過(guò)程;而從右邊的視圖中可以看到,一次訪問(wèn)需要約765次的請(qǐng)求和應(yīng)答的前提下,經(jīng)過(guò)每次25ms至30ms的“加持”,總的過(guò)程經(jīng)歷了21秒后才完成了相同的過(guò)程。
1.3 小結(jié)與建議
1.3.1小結(jié)
用戶的業(yè)務(wù)采用CS架構(gòu):①客戶-->② CS客戶端-->③SQL服務(wù)端,上述②和③之間,每次業(yè)務(wù)打開(kāi)和運(yùn)行的時(shí)候均需要有大量的數(shù)據(jù)交互;當(dāng)業(yè)務(wù)在同個(gè)局域網(wǎng)運(yùn)行,其中的延遲用戶也許近似無(wú)法感知。不過(guò)把“③SQL服務(wù)端”架設(shè)在移動(dòng)云上之后,用戶感受到的延遲就呈現(xiàn)數(shù)量級(jí)的上升,延遲上升的幅度取決于業(yè)務(wù)交互的次數(shù)。
1.3.2優(yōu)化建議
1.初步建議用戶調(diào)整數(shù)據(jù)庫(kù)部署的資源池,如果遷移到淮南節(jié)點(diǎn),理論上網(wǎng)絡(luò)延遲降到10ms之內(nèi),用戶打開(kāi)業(yè)務(wù)的時(shí)間,可從20+秒減少至10秒以下;
2.建議用戶調(diào)整業(yè)務(wù)的訪問(wèn)邏輯關(guān)系,采用BS的架構(gòu);或者CS架構(gòu)中,客戶-->應(yīng)用-->數(shù)據(jù)庫(kù)的業(yè)務(wù)流程中,應(yīng)用和數(shù)據(jù)庫(kù)同時(shí)上云,就能徹底解決延遲的問(wèn)題。
二、案例二:某資源池用戶和阿里云間調(diào)用postman問(wèn)題分析
2.1 背景
客戶的部分業(yè)務(wù)遷移到移動(dòng)云后,出現(xiàn)較大的延遲情況;如下圖所示,客戶部署在杭州阿里云IP地址為47.xx.xxx.22的業(yè)務(wù)訪問(wèn)已遷移至移動(dòng)云雅安節(jié)點(diǎn)IP地址為36.xx.xxx.65(tcp)的業(yè)務(wù)過(guò)程中,發(fā)現(xiàn)移動(dòng)云響應(yīng)杭州阿里這個(gè)地址的時(shí)候比較慢,達(dá)到14.78秒。
網(wǎng)絡(luò)環(huán)境和業(yè)務(wù)流程:
圖4
2.2 分析過(guò)程
1.從移動(dòng)云的回溯系統(tǒng)中調(diào)取數(shù)據(jù),經(jīng)分析后可見(jiàn)用戶反饋訪問(wèn)慢的時(shí)間段內(nèi),移動(dòng)云和阿里云IP為47.96.119.93的地址間產(chǎn)生了接近300KB的流量,峰值流量約為200Kbps,持續(xù)了15秒左右,如圖5所示。
2.從22:23:27開(kāi)始,看到阿里云IP 47.xx.xxx.93向移動(dòng)云內(nèi)網(wǎng)IP 10.xx.xxx.17 POST了164次http:// yunnan.xxxxxxxx.com:81/zsa/......的請(qǐng)求,移動(dòng)云每次均回復(fù)200 OK,服務(wù)端回復(fù)的延遲都很快,均低于0.01秒;最后一次訪問(wèn)過(guò)程的結(jié)束時(shí)間為22:23:41,從第一次開(kāi)始訪問(wèn)至末次訪問(wèn)結(jié)束剛好14秒多。(圖6)
3.而在這164的請(qǐng)求響應(yīng)過(guò)程中,每次請(qǐng)求間隔大約為0.09秒,從圖7中的“日期時(shí)間”可見(jiàn)。
4.進(jìn)一步分析每次訪問(wèn)的過(guò)程,這些請(qǐng)求響應(yīng)表現(xiàn)相近,均如圖8所示。
圖8
關(guān)于圖8中的三次握手和四次揮手,稍微延伸解釋一下,端到端的通信過(guò)程中為了建立TCP連接,通信雙方必須從對(duì)方了解這些信息:1)對(duì)方報(bào)文發(fā)送的開(kāi)始序號(hào)。2)對(duì)方發(fā)送數(shù)據(jù)的緩沖區(qū)大小。3)能被接收的最大報(bào)文段長(zhǎng)度MSS。4)被支持的TCP選項(xiàng)。因此雙方通過(guò)三次TCP報(bào)文實(shí)現(xiàn)對(duì)以上信息的了解,并在此基礎(chǔ)上建立一個(gè)TCP連接;而通信雙方的三次TCP報(bào)文的交換過(guò)程,也就是通常所說(shuō)的TCP連接建立實(shí)現(xiàn)的三次握手(Three-Way Handshake)過(guò)程。
由于TCP連接是全雙工的,因此每個(gè)方向都必須單獨(dú)進(jìn)行關(guān)閉。這個(gè)原則是當(dāng)一方完成它的數(shù)據(jù)發(fā)送任務(wù)后就能發(fā)送一個(gè)FIN來(lái)終止這個(gè)方向的連接。收到一個(gè) FIN只意味著這一方向上沒(méi)有數(shù)據(jù)流動(dòng),一個(gè)TCP連接在收到一個(gè)FIN后仍能發(fā)送數(shù)據(jù)。首先進(jìn)行關(guān)閉的一方將執(zhí)行主動(dòng)關(guān)閉,而另一方執(zhí)行被動(dòng)關(guān)閉。這就是通常所說(shuō)的“四次揮手”的過(guò)程。
因?yàn)槠P(guān)系,關(guān)于三次握手和四次揮手的交互細(xì)節(jié),在本文中筆者不展開(kāi)講述。
如之前的會(huì)話交互所示,建立會(huì)話時(shí)間和結(jié)束會(huì)話的總時(shí)間為0.08秒左右;會(huì)話各環(huán)節(jié)的時(shí)間占比如右圖所示:
三次握手和四次揮手,均和網(wǎng)絡(luò)延遲有關(guān),從阿里云到移動(dòng)云之間的網(wǎng)絡(luò)延遲為39ms左右。(圖9)
每次請(qǐng)求都需要新建一次TCP會(huì)話,每次新的會(huì)話都需要等上一次的會(huì)話結(jié)束才能開(kāi)始。
2.3 小結(jié)與建議
2.3.1小結(jié)
從上文的分析過(guò)程可得,在現(xiàn)有的應(yīng)用架構(gòu)中,每次的業(yè)務(wù)操作,需要分解為很多次的HTTP短鏈接,而短鏈接狀態(tài)中每一個(gè)會(huì)話持續(xù)時(shí)間0.09(秒) X 164(次) = 14.76秒,這就是導(dǎo)致部分業(yè)務(wù)遷移到移動(dòng)云后,調(diào)用阿里云接口慢(14.78秒)的主要原因。
2.3.2優(yōu)化建議
根據(jù)交互內(nèi)容,建議應(yīng)用采用長(zhǎng)連接,減少不必要的網(wǎng)絡(luò)建鏈和拆鏈過(guò)程,可有效降低時(shí)延。
2.3.3說(shuō)明
在HTTP/1.0中默認(rèn)使用短連接。也就是說(shuō),客戶端和服務(wù)器每進(jìn)行一次HTTP操作,就建立一次連接,任務(wù)結(jié)束就中斷連接。當(dāng)客戶端瀏覽器訪問(wèn)的某個(gè)HTML或其他類型的Web頁(yè)中包含有其他的Web資源(如JavaScript文件、圖像文件、CSS文件等),每遇到這樣一個(gè)Web資源,瀏覽器就會(huì)重新建立一個(gè)HTTP會(huì)話。而從HTTP/1.1起,默認(rèn)使用長(zhǎng)連接,用以保持連接特性。使用長(zhǎng)連接的HTTP協(xié)議,會(huì)在響應(yīng)頭加入這段代碼:Connection:keep-alive;在使用長(zhǎng)連接的情況下,當(dāng)一個(gè)網(wǎng)頁(yè)打開(kāi)完成后,客戶端和服務(wù)器之間用于傳輸HTTP數(shù)據(jù)的TCP連接不會(huì)關(guān)閉,客戶端再次訪問(wèn)這個(gè)服務(wù)器時(shí),會(huì)繼續(xù)使用這一條已經(jīng)建立的連接。Keep-Alive不會(huì)永久保持連接,它有一個(gè)保持時(shí)間,可以在不同的服務(wù)器軟件(如Apache)中設(shè)定這個(gè)時(shí)間。實(shí)現(xiàn)長(zhǎng)連接需要客戶端和服務(wù)端都支持長(zhǎng)連接。HTTP協(xié)議的長(zhǎng)連接和短連接,實(shí)質(zhì)上是TCP協(xié)議的長(zhǎng)連接和短連接。
2.4 優(yōu)化后效果評(píng)估
經(jīng)管理人員與研發(fā)人員討論后,對(duì)業(yè)務(wù)模式做了調(diào)整,用戶采用了長(zhǎng)連接的會(huì)話方式調(diào)用移動(dòng)云;后續(xù)對(duì)該業(yè)務(wù)進(jìn)行跟蹤分析, 如圖10所示,修改后無(wú)數(shù)據(jù)交互時(shí),阿里云IP47.xx.xxx.22和云主機(jī)10.xx.xxx.123之間,每隔4.95秒進(jìn)行一次數(shù)據(jù)同步,維持會(huì)話的長(zhǎng)連接狀態(tài)。
圖10
有業(yè)務(wù)產(chǎn)生的時(shí)候,客戶端直接調(diào)用移動(dòng)云接口時(shí),會(huì)通過(guò)47.xx.xxx.22的9333端口直接訪問(wèn)移動(dòng)云主機(jī),這時(shí)候,只有兩個(gè)TCP會(huì)話產(chǎn)生數(shù)據(jù)產(chǎn)生。(圖11)
阿里云IP一次性把所有數(shù)據(jù)傳到移動(dòng)云主機(jī)。(圖12)
這樣的調(diào)用效率高,所以延遲就比較低,用戶體驗(yàn)明顯提升,而記錄到的時(shí)間延遲也大幅度降低了(從14.78秒減少至1.479秒)。(圖13)
三、結(jié)束語(yǔ)
在前文章節(jié)中的兩個(gè)案例,筆者作為主要分析人員參與了故障定位與優(yōu)化的過(guò)程,從而體會(huì)非常深刻,網(wǎng)絡(luò)延遲從局域網(wǎng)的“1毫秒”到互聯(lián)網(wǎng)的“30毫秒”,雖然只是增加了29毫秒,然而這短短的“29毫秒”,經(jīng)過(guò)交互次數(shù)的乘法后,對(duì)業(yè)務(wù)的開(kāi)展影響竟然如此巨大。
本文案例一讓我們明白,“客戶-->應(yīng)用-->數(shù)據(jù)庫(kù)”的流程中,“應(yīng)用”和“數(shù)據(jù)庫(kù)”必須同時(shí)上云,通過(guò)減少長(zhǎng)距離的交互次數(shù),可有效降低業(yè)務(wù)延遲,如圖14所示。
本文案例二讓我們明白,業(yè)務(wù)拆分或者部分應(yīng)用上云后,如果拆分部分的交互次數(shù)較多的情況下,應(yīng)用的連接方式需從短鏈接長(zhǎng)連接,通過(guò)減少不必要的網(wǎng)絡(luò)建鏈和拆鏈過(guò)程,可有效降低業(yè)務(wù)的整體時(shí)延。
兩個(gè)案例產(chǎn)生的根因是相同的:多次交互+單次延遲增加。
筆者建議企業(yè)應(yīng)用在上云的過(guò)程中,做好調(diào)研工作,特別需要關(guān)注業(yè)務(wù)的邏輯關(guān)系和產(chǎn)生數(shù)據(jù)的交互過(guò)程,必要的情況下,適度調(diào)整應(yīng)用架構(gòu)以適應(yīng)云環(huán)境的使用。