量變引起質(zhì)變。

項(xiàng)目需求

由于我們現(xiàn)在開(kāi)發(fā)的云平臺(tái)項(xiàng)目是一個(gè)跨云調(diào)度的重型計(jì)算平臺(tái)，所以會(huì)用到不同的云服務(wù)廠商的計(jì)算實(shí)例服務(wù)器，比如阿里云的ECS、亞馬遜的EC2或者谷歌云的compute engine等，同時(shí)也會(huì)在這些計(jì)算實(shí)例之間進(jìn)行數(shù)據(jù)傳輸。

這些云服務(wù)器之間的傳輸速度通常是不同的，即使是同一個(gè)云服務(wù)廠商內(nèi)的不同區(qū)域服務(wù)器之間傳輸數(shù)據(jù)，帶寬也會(huì)有所不同。

所以需要對(duì)這些服務(wù)器之間的帶寬速度進(jìn)行測(cè)量，以供調(diào)度進(jìn)程分配任務(wù)和傳輸數(shù)據(jù)。

總結(jié)起來(lái)這個(gè)功能實(shí)現(xiàn)起來(lái)有3個(gè)要求：

①對(duì)不同區(qū)域內(nèi)的云服務(wù)器的TCP/UDP傳輸速度進(jìn)行檢測(cè)。

②必須是滿帶寬的測(cè)速，也就是說(shuō)兩臺(tái)服務(wù)器在測(cè)速的時(shí)候不能有其它網(wǎng)絡(luò)程序運(yùn)行。

③多臺(tái)服務(wù)器之間需要高效地建立兩兩連接。

針對(duì)這3個(gè)問(wèn)題，我實(shí)行了以下解決方案。

基本結(jié)構(gòu)

一種簡(jiǎn)單的設(shè)想就是啟動(dòng)測(cè)速所需的客戶端和服務(wù)端，讓這些程序之間互相爭(zhēng)搶進(jìn)行測(cè)速。

但是這種方式在進(jìn)程的管理上很容易出現(xiàn)問(wèn)題，因?yàn)槊總�(gè)進(jìn)程既要操作自己的狀態(tài)還需要操作其它進(jìn)程的狀態(tài)，同時(shí)一下子起4個(gè)進(jìn)程也比較浪費(fèi)，因?yàn)槭聦?shí)上每次測(cè)速只會(huì)有一個(gè)進(jìn)程工作。

所以更好的方式是用主從結(jié)構(gòu)，由一個(gè)主進(jìn)程來(lái)啟停負(fù)責(zé)測(cè)速的客戶/服務(wù)端子進(jìn)程。

這樣不但能有效地避免資源的浪費(fèi)和爭(zhēng)搶?zhuān)�同時(shí)主進(jìn)程中也可以集成很多邏輯功能，比如對(duì)外提供 REST API，記錄日志、備份測(cè)試結(jié)果等。

當(dāng)然為了方便部署和程序控制，所有的進(jìn)程都是部署在 Docker 容器中。

由于主進(jìn)程需要訪問(wèn)宿主機(jī)的 Docker 服務(wù)，所以需要開(kāi)啟 Docker 的 remote API 服務(wù)，對(duì)容器提供REST API進(jìn)行操作。

功能實(shí)現(xiàn)

基本測(cè)速

TCP與UDP

網(wǎng)絡(luò)協(xié)議是一層一層封裝起來(lái)的，而TCP和UDP屬于同一層的兩種協(xié)議。

其中TCP協(xié)議在前后端開(kāi)發(fā)中非常常用，因?yàn)镽EST API請(qǐng)求依賴的HTTP(S)協(xié)議就是TCP的上層協(xié)議，而UDP協(xié)議在視頻、游戲、下載等業(yè)務(wù)中使用也非常多。

它們有一些共同點(diǎn)：請(qǐng)求的發(fā)起方稱為客戶端，請(qǐng)求的接收方稱為服務(wù)端，服務(wù)端和客戶端可以雙向通信。

而它們的側(cè)重點(diǎn)有所區(qū)別。TCP更注重穩(wěn)定，客戶端和服務(wù)端之間需要建立連接之后才能互相發(fā)送數(shù)據(jù)。

UDP則更注重速度，客戶端不需要和服務(wù)端建立連接即可直接發(fā)送數(shù)據(jù)，但是如果發(fā)送速度太快或者網(wǎng)絡(luò)不穩(wěn)定可能會(huì)造成丟包，導(dǎo)致對(duì)方接收的數(shù)據(jù)部分丟失。

測(cè)速工具

常用的命令行測(cè)速工具有iperf和speedtest，相較之下選擇了功能更強(qiáng)大的iperf。

iperf是一個(gè)比較理想的測(cè)速工具，支持TCP、UDP協(xié)議，還可以通過(guò)參數(shù)來(lái)制定傳輸數(shù)據(jù)大小、傳輸次數(shù)或者傳輸時(shí)間，以及輸出結(jié)果的格式。

但是由于前面UDP協(xié)議的特性，測(cè)速會(huì)略微麻煩一些，需要找到合適的帶寬。

比如按照1Gbps的速度發(fā)送數(shù)據(jù)，丟包率是70%和按照10Mbps的速度發(fā)送數(shù)據(jù)，丟包率是0，那么對(duì)數(shù)據(jù)完整性有要求的話肯定更偏向于后者。

當(dāng)然實(shí)際情況并不是對(duì)于丟包率為0就是最好的，而是在可容忍的范圍內(nèi)采用最大速度傳輸（數(shù)據(jù)丟了還可以重傳不是~）。

這就意味著需要根據(jù)實(shí)際網(wǎng)絡(luò)狀況不斷調(diào)整和嘗試。

而iperf并沒(méi)有這么智能，所以UDP這一塊采用團(tuán)隊(duì)內(nèi)部開(kāi)發(fā)的一款UDP傳輸工具，來(lái)找到理想的傳輸速度。

滿帶寬

要保證滿帶寬只需要保證測(cè)速時(shí)沒(méi)有其它程序占用帶寬即可。

由于我們可以啟動(dòng)一臺(tái)獨(dú)立的搶占式服務(wù)器來(lái)運(yùn)行測(cè)速程序，所以其它非測(cè)速程序的進(jìn)程不太可能占用帶寬，而容易爭(zhēng)搶帶寬的是用來(lái)測(cè)速的子程序。

所以需要讓子程序之間是互斥運(yùn)行，甚至是互斥存在的。

采用狀態(tài)管理基本上就可以實(shí)現(xiàn)，主程序在每次有進(jìn)程啟動(dòng)的時(shí)候?qū)�狀態(tài)置為”connecting”，測(cè)速完成后置為”waiting”，只有在”waiting”狀態(tài)下才可以啟動(dòng)新的子程序進(jìn)行測(cè)速。

但是這只是從代碼邏輯層面控制，對(duì)于穩(wěn)定健壯的程序而言，最好還有其它的硬性控制方式。

這時(shí)候使用容器的話就可以輕松辦到。

凡是需要進(jìn)行測(cè)速的進(jìn)程都在容器中啟動(dòng)，同時(shí)容器的名稱都統(tǒng)一，那么一旦程序出現(xiàn)bug，同時(shí)啟動(dòng)多個(gè)子程序時(shí)，Docke r服務(wù)則會(huì)報(bào)錯(cuò)，告知容器名稱沖突，從而創(chuàng)建失敗。

當(dāng)然這種方式也有一定的風(fēng)險(xiǎn)，比如上一個(gè)進(jìn)程測(cè)速過(guò)程中出現(xiàn)問(wèn)題沒(méi)有按時(shí)退出，那么則無(wú)法進(jìn)行新的測(cè)速，所以需要需要設(shè)定一個(gè)超時(shí)時(shí)間，超過(guò)一段時(shí)間后主動(dòng)停止當(dāng)前測(cè)速子程序。

同時(shí)如果主程序意外退出，導(dǎo)致停止失敗的話，也要進(jìn)行處理：在每次啟動(dòng)主程序的時(shí)候進(jìn)行檢查，及時(shí)銷(xiāo)毀未停止的子程序。

多節(jié)點(diǎn)

多節(jié)點(diǎn)算是非常棘手的問(wèn)題。試想如果在一段時(shí)間內(nèi)同時(shí)在多個(gè)云服務(wù)器上啟動(dòng)多個(gè)測(cè)速程序，如何保證他們有序的進(jìn)行測(cè)速呢？

要解決這個(gè)問(wèn)題，先思考一個(gè)簡(jiǎn)單些的問(wèn)題：

在一段時(shí)間內(nèi)，如何決定哪些云服務(wù)器啟動(dòng)服務(wù)端子程序哪些云服務(wù)器啟動(dòng)客戶端子程序呢？

如果按照“主-從”模式的話需要建立一個(gè)中心節(jié)點(diǎn)來(lái)進(jìn)行控制，但是這樣的缺點(diǎn)很多，最重要的一個(gè)缺點(diǎn)是如果某個(gè)節(jié)點(diǎn)與中心節(jié)點(diǎn)無(wú)法通信那么就無(wú)法獲得與其它節(jié)點(diǎn)通信的機(jī)會(huì)，及時(shí)它和其它節(jié)點(diǎn)之間網(wǎng)絡(luò)暢通。

同時(shí)中心節(jié)點(diǎn)和其它節(jié)點(diǎn)之間也存在多節(jié)點(diǎn)通信的問(wèn)題。

總而言之這種方式下通信的成本太高，服務(wù)端與客戶端傳輸數(shù)據(jù)需要的中間環(huán)節(jié)太多，很容易出現(xiàn)問(wèn)題。

所以簡(jiǎn)單的方式是讓云服務(wù)器之間互相發(fā)起測(cè)速請(qǐng)求并響應(yīng)。

這樣的話，主程序的邏輯要分為兩個(gè)模塊，一個(gè)模塊用來(lái)響應(yīng)請(qǐng)求、、分配端口、啟動(dòng)服務(wù)端容器。

另一個(gè)用來(lái)輪詢帶測(cè)速隊(duì)列并發(fā)起請(qǐng)求、啟動(dòng)客戶端容器建立連接。

工作流程大致如下：

這種處理方式還有一種極端情況，就是兩個(gè)云服務(wù)器之間互相請(qǐng)求進(jìn)行測(cè)試，如果雙方請(qǐng)求到達(dá)時(shí)間一致，那么就會(huì)同時(shí)給對(duì)方分配端口，然后同時(shí)受到對(duì)方分配的端口之后發(fā)現(xiàn)服務(wù)端已啟動(dòng)于是放棄連接。

于是出現(xiàn)了類(lèi)似進(jìn)程“死鎖”的狀態(tài)。

對(duì)于這種情況的處理方式是使用時(shí)間戳來(lái)記錄請(qǐng)求發(fā)起的時(shí)刻，雙方通過(guò)時(shí)間戳的先后來(lái)決定是否啟動(dòng)客戶端或服務(wù)端。

即使更極端的情況出現(xiàn)——雙方時(shí)間戳相同。那么通過(guò)超時(shí)回收或者發(fā)消息釋放端口來(lái)建立下一次連接。

弱網(wǎng)絡(luò)下的處理

弱網(wǎng)絡(luò)指的是網(wǎng)絡(luò)不穩(wěn)定或者帶寬較小的情況。

這種情況的處理方式原則上就是重測(cè)，但是關(guān)于重測(cè)有幾個(gè)需要注意的地方：

對(duì)于帶寬較小的情況需要考慮減小傳輸數(shù)據(jù)的體積以保證在制定的超時(shí)時(shí)間內(nèi)完成測(cè)速。

對(duì)于測(cè)速失敗的情況進(jìn)行判斷并重測(cè)，同時(shí)限定重測(cè)次數(shù)，避免無(wú)限重測(cè)。

重測(cè)時(shí)可以讓客戶端與服務(wù)端進(jìn)行互換測(cè)試，通過(guò)限定一方發(fā)起重測(cè)可實(shí)現(xiàn)。

總結(jié)

總體結(jié)構(gòu)圖如下：

很多時(shí)候?qū)崿F(xiàn)一個(gè)功能并不困難，但是要把功能實(shí)現(xiàn)好卻是一件不簡(jiǎn)單的事。

雖然理論上實(shí)現(xiàn)起來(lái)只是簡(jiǎn)單的調(diào)用測(cè)速工具就可以得到結(jié)果，但在實(shí)際場(chǎng)景下可用性會(huì)變得很低。

比如沒(méi)有對(duì)弱網(wǎng)絡(luò)的重測(cè)機(jī)制，那么偶然的網(wǎng)絡(luò)抖動(dòng)就會(huì)影響到測(cè)速結(jié)果。

如果沒(méi)有考慮到多節(jié)點(diǎn)爭(zhēng)搶連接的問(wèn)題，那么實(shí)際運(yùn)行在多個(gè)云服務(wù)器上可能會(huì)造成程序錯(cuò)誤或測(cè)速結(jié)果不準(zhǔn)確的問(wèn)題。

要怎么樣把功能實(shí)現(xiàn)好呢？

至少有兩個(gè)考慮方向：

倍數(shù)思維。比如當(dāng)前框架支持10個(gè)頁(yè)面沒(méi)問(wèn)題，那么如果100個(gè)、1000個(gè)會(huì)不會(huì)有性能問(wèn)題？

極限思維。就是一些極端情況下的處理機(jī)制，比如在本文中對(duì)超時(shí)的處理，對(duì)容器互斥的處理等。（來(lái)源：人和未來(lái)gtxlab；作者：朱德龍）

天下數(shù)據(jù)與全球近120多個(gè)國(guó)家頂級(jí)機(jī)房直接合作，提供包括香港、美國(guó)、韓國(guó)、日本、臺(tái)灣、新加坡、荷蘭、法國(guó)、英國(guó)、德國(guó)、埃及、南非、巴西、印度、越南等國(guó)家和地區(qū)的服務(wù)器、云服務(wù)器的租用服務(wù)，需要的請(qǐng)聯(lián)系天下數(shù)據(jù)客服！

本文鏈接：http://m.51huadong.com/cloundnews/11003247.html