企業應用上云過程中系統架構的適應性研究

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

　　【關鍵詞】 上云 適應性 企業

　　一、案例一：某醫院業務上云后問題排查

　　1.1 背景

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

　　附：前期排查進展：1.客戶側時延為30ms左右，為安徽-->上海資源池;2.通過fiddler抓到請求，發現客戶的應用為CS架構，客戶端訪問云端的是SQL 數據庫業務。

　　1.2 分析過程

　　1.2.1網絡傳輸質量評估

　　從局域網環境中抓包，以及在云環境中提取訪問過程的數據，放在回溯系統上進行比較，圖1左邊是服務端再局域網內的訪問過程，右邊的視圖是用戶通過專線訪問部署在云上的業務系統的訪問過程。

　　這兩組會話，均沒有丟包重傳，網絡延遲也很穩定，訪問同一個業務產生的數據報文均為1580個包左右，其中客戶端向服務端發送了765次請求，服務端都回復了數據。

　　這兩個唯一的區別，內網的網絡延遲為0.8ms，云中的網絡延遲為25ms;這點可以從圖1 TCP三次握手過程可以看到。

　　1.2.2交互過程分析

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

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

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

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

　　1.3 小結與建議

　　1.3.1小結

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

　　1.3.2優化建議

　　1.初步建議用戶調整數據庫部署的資源池，如果遷移到淮南節點，理論上網絡延遲降到10ms之內，用戶打開業務的時間，可從20+秒減少至10秒以下;

　　2.建議用戶調整業務的訪問邏輯關系，采用BS的架構;或者CS架構中，客戶-->應用-->數據庫的業務流程中，應用和數據庫同時上云，就能徹底解決延遲的問題。

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

　　2.1 背景

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

　　網絡環境和業務流程：

　　圖4

　　2.2 分析過程

　　1.從移動云的回溯系統中調取數據，經分析后可見用戶反饋訪問慢的時間段內，移動云和阿里云IP為47.96.119.93的地址間產生了接近300KB的流量，峰值流量約為200Kbps，持續了15秒左右，如圖5所示。

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

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

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

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

　　推薦閱讀：計算機信息管理在企業中的應用