企業(yè)應(yīng)用上云過(guò)程中系統(tǒng)架構(gòu)的適應(yīng)性研究

　　【摘要】 在科技時(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所示。

　　關(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ò)程。

　　推薦閱讀：計(jì)算機(jī)信息管理在企業(yè)中的應(yīng)用