Cloudflare如何在全球范圍內(nèi)動態(tài)路由流量

想象一下這種情景：您身處機(jī)場，正在通過安檢口。很多工作人員在掃描您的登機(jī)牌和護(hù)照，然后將您送到登機(jī)口。突然之間，一些工作人員開始休息。也許是安檢口處出現(xiàn)設(shè)施故障，也許是多個航班在下午6時起飛，一大批旅客同時涌現(xiàn)。無論哪種情況，這種局部供需不平衡都可能導(dǎo)致排長隊和造成旅客的不滿——他們只是想盡快通過隊伍并登上他們的航班。那么，機(jī)場通過什么方式來處理這種情況？

有些機(jī)場可能什么都不做，只會讓您繼續(xù)排隊、持續(xù)等待，隊伍越排越長。一些機(jī)場可能會收費提供通過安檢的快速通道。但大多數(shù)機(jī)場會告訴您去稍遠(yuǎn)一點的另一個安檢口，以確保您能盡快通過并到達(dá)登機(jī)口。他們甚至可能會設(shè)置醒目的指示牌，告訴您每條排隊線路的長度，以便您在嘗試通過時可以更容易做出決策。

在Cloudflare，我們也面臨同樣的問題。我們打造的網(wǎng)絡(luò)分布于世界各地300個城市，旨在為我們的所有產(chǎn)品套件接收最終用戶流量。在理想情況下，我們始終有足夠的計算機(jī)和帶寬在最接近的位置處理每個用戶的流量。但實際情況并不總是理想的：有時我們會讓一個數(shù)據(jù)中心下線以進(jìn)行維護(hù)，或者與數(shù)據(jù)中心的連接中斷，或者某些設(shè)備出現(xiàn)故障，等等。當(dāng)這種情況發(fā)生時，我們可能沒有足夠的人員來為每個地方的每個人提供“安檢服務(wù)”。這并不是因為我們沒有建立足夠的站點，而是因為我們的數(shù)據(jù)中心發(fā)生了一些問題，導(dǎo)致我們無法為每個人提供服務(wù)。

因此，我們打造了Traffic Manager（流量管理器）：這個工具用于在我們的整個全球網(wǎng)絡(luò)中平衡供應(yīng)和需求。本篇文章將主要介紹Traffic Manager：它的由來，我們是如何構(gòu)建它的，以及它現(xiàn)在的運行狀況。

在Traffic Manager出現(xiàn)之前

Traffic Manager現(xiàn)在所做的工作過去是由網(wǎng)絡(luò)工程師手動操作的：我們的網(wǎng)絡(luò)正常運行，直到某個數(shù)據(jù)中心出現(xiàn)問題并影響到用戶流量。當(dāng)出現(xiàn)此類事件時，用戶請求會開始出現(xiàn)“499”或“500”錯誤，因為沒有足夠的機(jī)器來處理用戶的請求負(fù)載。這將為我們的網(wǎng)絡(luò)工程師觸發(fā)一個頁面，他們會刪除該數(shù)據(jù)中心的一些Anycast路由。最終結(jié)果：通過不再在受影響的數(shù)據(jù)中心廣告這些前綴，用戶流量會被轉(zhuǎn)移至距離用戶試圖連接的另一個最近的廣告這些前綴的數(shù)據(jù)中心。這就是Anycast的基本工作原理：用戶流量會被引導(dǎo)到廣告用戶試圖連接的廣告前綴的數(shù)據(jù)中心，這是由邊界網(wǎng)關(guān)協(xié)議決定的。如需了解Anycast是什么，請查看這篇參考文章。

根據(jù)問題的嚴(yán)重程度，工程師會移除數(shù)據(jù)中心的部分甚至全部路由。當(dāng)數(shù)據(jù)中心再次能夠吸收所有流量時，工程師將把數(shù)據(jù)中心的路由恢復(fù)，流量將自然返回數(shù)據(jù)中心。

您可以想象，每次我們的網(wǎng)絡(luò)中任何硬件出現(xiàn)問題時，網(wǎng)絡(luò)工程師都要進(jìn)行這樣的操作，這是一件極具挑戰(zhàn)性的任務(wù)。這種做法不能規(guī)?；?/p>

永遠(yuǎn)不要派人去做機(jī)器的工作

人工手動操作不僅會給我們的網(wǎng)絡(luò)運營團(tuán)隊造成負(fù)擔(dān)，也會導(dǎo)致我們的客戶體驗不佳；我們的工程師需要花時間診斷和重新路由流量。為了解決這兩個問題，我們希望打造一款服務(wù)，它可以立即自動檢測用戶是否無法到達(dá)Cloudflare數(shù)據(jù)中心，并從數(shù)據(jù)中心撤回路由，直到用戶不再看到問題。一旦服務(wù)通知顯示受影響的數(shù)據(jù)中心可以吸收流量，它就可以將路由恢復(fù)并重新連接該數(shù)據(jù)中心。這款服務(wù)被稱為Traffic Manager，它的工作就是管理進(jìn)入Cloudflare網(wǎng)絡(luò)的流量。

不容忽視的后續(xù)連帶因果

當(dāng)網(wǎng)絡(luò)工程師從路由器中移除一條路由時，他們可以盡可能猜測用戶請求會轉(zhuǎn)移到哪里，并嘗試確保備用數(shù)據(jù)中心有足夠的資源來處理請求——如果沒有，他們可以在初始數(shù)據(jù)中心移除路由之前相應(yīng)地調(diào)整那里的路由。為了實現(xiàn)這個過程的自動化，我們需要從直覺判斷轉(zhuǎn)向依據(jù)數(shù)據(jù)做科學(xué)判斷——更準(zhǔn)確地預(yù)測當(dāng)一條路線被取消時，流量會轉(zhuǎn)移到哪里，并將這些信息提供給Traffic Manager，以便確保這樣做不會使情況變得更糟。

再介紹一下Traffic Predictor

盡管我們可以調(diào)整哪些數(shù)據(jù)中心廣告路由，但我們無法影響每個數(shù)據(jù)中心接收的流量比例。每次我們增加一個新的數(shù)據(jù)中心，或者一個新的對等互連，流量的分布就會發(fā)生變化，由于我們的網(wǎng)絡(luò)覆蓋超過300個城市，擁有12500個對等互連，對于人類來說，跟蹤或預(yù)測流量在我們的網(wǎng)絡(luò)如何移動已經(jīng)變得十分困難。Traffic Manager需要一個拍檔：Traffic Predictor為了完成其工作，Traffic Predictor進(jìn)行一系列持續(xù)的測試，以查看流量實際的移動情況。Traffic Predictor依賴于一個測試系統(tǒng)，該系統(tǒng)模擬將數(shù)據(jù)中心從服務(wù)中移除，并測量如果該數(shù)據(jù)中心不再服務(wù)流量，流量會轉(zhuǎn)移到哪里。為了幫助大家理解這個系統(tǒng)是如何工作的，讓我們模擬一下移除新西蘭基督城數(shù)據(jù)中心的一個子集：

首先，Traffic Predictor獲取通常連接到基督城數(shù)據(jù)中心的所有IP地址的列表。Traffic Predictor將向最近發(fā)出請求的數(shù)十萬個IP發(fā)送ping請求。

Traffic Predictor記錄每個IP是否響應(yīng)，以及響應(yīng)是否使用專門為Traffic Predictor配置的特殊Anycast IP范圍返回到基督城數(shù)據(jù)中心。

一旦Traffic Predictor獲得一個將響應(yīng)發(fā)送到基督城數(shù)據(jù)中心的IP列表，它就會從基督城數(shù)據(jù)中心移除包含該特殊范圍的路由，等待幾分鐘以使互聯(lián)網(wǎng)路由表更新，然后再次運行測試。

這些響應(yīng)不再被路由到基督城數(shù)據(jù)中心，而是被引導(dǎo)到其周圍的其他數(shù)據(jù)中心。然后，Traffic Predictor使用每個數(shù)據(jù)中心的響應(yīng)情況，并將結(jié)果記錄為基督城數(shù)據(jù)中心的故障轉(zhuǎn)移。

這樣一來，無需讓基督城數(shù)據(jù)中心實際下線，我們就能模擬該數(shù)據(jù)中心下線的情況。

但是，Traffic Predictor并不是簡單地以同樣的方法對所有數(shù)據(jù)中心都執(zhí)行這種操作。為了增加額外的韌性，Traffic Predictor甚至計算第二層間接性：對于每個數(shù)據(jù)中心故障情景，Traffic Predictor也會計算周圍數(shù)據(jù)中心的故障情景并創(chuàng)建發(fā)生故障時的策略。

使用上面的例子，當(dāng)Traffic Predictor測試基督城時，它將運行一系列的測試，將包括基督城在內(nèi)周圍幾個數(shù)據(jù)中心從服務(wù)中移除，以計算不同的故障情景。這確保即使發(fā)生了影響一個地區(qū)內(nèi)多個數(shù)據(jù)中心的災(zāi)難性事件，我們?nèi)匀挥心芰Ψ?wù)用戶流量。如果您認(rèn)為這個數(shù)據(jù)模型很復(fù)雜，沒錯：計算所有這些故障路徑和策略需要幾天時間。

當(dāng)我們將全球所有數(shù)據(jù)中心的故障路徑和故障轉(zhuǎn)移情景可視化時，看起來是這樣的：

對于人類來說，這可能有點復(fù)雜，所以讓我們深入介紹一下上述基督城示例的情景，使它更清晰一些。查看基督城的故障轉(zhuǎn)移路徑時，我們看到如下圖的樣子：

在這個情景中，我們預(yù)測基督城99.8%的流量會轉(zhuǎn)移到奧克蘭數(shù)據(jù)中心，后者能夠在災(zāi)難性的宕機(jī)事件發(fā)生時吸收基督城數(shù)據(jù)中心的所有流量。

Traffic Predictor不僅允許我們看到發(fā)生故障時流量將轉(zhuǎn)移到哪里，還允許我們預(yù)先配置Traffic Manager策略，以便將請求從發(fā)生故障的數(shù)據(jù)中心轉(zhuǎn)移出來，以防止出現(xiàn)驚群效應(yīng)：如果第一個數(shù)據(jù)中心出現(xiàn)問題，突然涌入的請求可能導(dǎo)致第二個數(shù)據(jù)中心發(fā)生故障。借助Traffic Predictor，Traffic Manager不僅在一個數(shù)據(jù)中心發(fā)生故障時將流量轉(zhuǎn)移出去，還會主動將流量從其他數(shù)據(jù)中心轉(zhuǎn)移出去，以確保服務(wù)的無縫延續(xù)。

精耕細(xì)作

利用Traffic Predictor，Traffic Manager能夠動態(tài)地廣告和撤回前綴，同時確保每個數(shù)據(jù)中心都能處理所有流量。但是，有時以撤回前綴作為流量管理的手段可能有些過度。其中一個原因是，我們向數(shù)據(jù)中心添加或移除流量的唯一方式是通過從面向互聯(lián)網(wǎng)的路由器廣告路由。我們的每個路由都包含數(shù)千個IP地址，因此即使只刪除一個也會影響一大部分的流量。

具體而言，互聯(lián)網(wǎng)應(yīng)用將至少從一個/24子網(wǎng)向互聯(lián)網(wǎng)廣告前綴，但許多應(yīng)用廣告的前綴要大于/24。這通常是為了防止路由泄露或路由劫持：許多服務(wù)提供商實際上會過濾掉比/24更具體的路由（有關(guān)更多信息，請查看這篇博客文章）。如果我們假設(shè)Cloudflare將受保護(hù)資產(chǎn)映射到IP地址的比例為1:1，那么每個/24子網(wǎng)將能夠為256個客戶提供服務(wù)，這是/24子網(wǎng)中的IP地址數(shù)量。如果每個IP地址每秒發(fā)出一個請求，且需要每秒轉(zhuǎn)移1000個請求（RPS）計算，我們將不得不從數(shù)據(jù)中心移出4個/24子網(wǎng)。

但實際上，Cloudflare將單一IP地址映射到數(shù)十萬個受保護(hù)資產(chǎn)。所以，對于Cloudflare來說，一個/24子網(wǎng)可能會接收到每秒3000個請求，但是如果我們需要移出1000個RPS，那么我們別無選擇，只能移出一個/24子網(wǎng)。這還只是假設(shè)我們在/24級別進(jìn)行路由廣告。如果我們使用/20來進(jìn)行廣告，我們可以撤回的數(shù)量就會變得不那么精細(xì)了：如果網(wǎng)站到IP地址映射為1:1，每個前綴每秒處理4096個請求，如果網(wǎng)站到IP地址的映射是多對一，那么處理的請求數(shù)就更多了。

雖然撤回前綴廣告可為那些可能已看到“499”或“500”錯誤的用戶改善體驗——但可能有大部分用戶并沒有受到問題的影響，并仍然被從他們應(yīng)該去的數(shù)據(jù)中心移走，那么他們的速度可能會下降，即便延遲只有一點點。這種移出比必要更多的流量的概念被稱為“擱淺容量”：理論上，數(shù)據(jù)中心能夠為一個地區(qū)的更多用戶提供服務(wù)，但由于Traffic Manager的工作方式，它無法做到這一點。

因此我們希望進(jìn)一步改進(jìn)Traffic Manager，使其只將相對最少的用戶從出現(xiàn)問題的數(shù)據(jù)中心移出，而不是擱淺更多的容量。為了做到這一點，我們需要轉(zhuǎn)移一定比例的前綴，這樣我們可以做到更加精細(xì)化，只轉(zhuǎn)移絕對需要移出的部分。為了解決這個問題，我們?yōu)槲覀兊牡谒膶迂?fù)載均衡器Unimog構(gòu)建了一個擴(kuò)展，名為Plurimog。

快速重溫下Unimog和第四層負(fù)載平衡：我們的每一臺機(jī)器都包含一個服務(wù)，用于確定該機(jī)器是否可以接受用戶請求。如果該機(jī)器可以接受用戶請求，那么它會將請求發(fā)送到我們的HTTP堆棧，后者將處理請求并將返回用戶。如果該機(jī)器無法接受請求，則其會將請求發(fā)送到數(shù)據(jù)中心中可以接受請求的另一臺機(jī)器。這些機(jī)器之所以能夠做到這一點，是因為它們一直在進(jìn)行通信，以了解彼此是否可以服務(wù)用戶。

Plurimog做同樣的事情，但Plurimog是在數(shù)據(jù)中心和入網(wǎng)點之間進(jìn)行通信，而不是在機(jī)器之間。如果一個請求進(jìn)入費城數(shù)據(jù)中心，而它無法接受該請求，Plurimog則會將其轉(zhuǎn)發(fā)到另一個可以接受該請求的數(shù)據(jù)中心，比如阿什本，并在那里解密并處理請求。因為Plurimog在第四層運行，它可以將單個TCP或UDP請求發(fā)送到其他地方，使得它可以非常精細(xì)：它可以非常容易地將一定比例的流量發(fā)送到其他數(shù)據(jù)中心，意味著我們只需要轉(zhuǎn)移出足夠的流量，以確保每個人都可以盡快得到服務(wù)?？匆幌逻@在法蘭克福數(shù)據(jù)中心是如何工作的，我們能夠逐步將越來越多的流量轉(zhuǎn)移出去，以便處理我們數(shù)據(jù)中心的問題。下列圖表顯示隨著時間的推移，對免費流量采取將其轉(zhuǎn)移出法蘭克福數(shù)據(jù)中心的操作數(shù)量。

但即使在數(shù)據(jù)中心內(nèi)部，我們也可以路由流量到其他部分，以防止流量離開數(shù)據(jù)中心。我們的大型數(shù)據(jù)中心，即多個共存入網(wǎng)點（MCP），包含在數(shù)據(jù)中心內(nèi)部的計算邏輯部分，它們彼此并不相同。這些MCP數(shù)據(jù)中心啟用了另一個版本的Unimog，稱為Duomog，它用于自動在計算邏輯部分之間轉(zhuǎn)移流量。這使得MCP數(shù)據(jù)中心具備不犧牲客戶性能的容錯性，并允許Traffic Manager在一個數(shù)據(jù)中心內(nèi)以及數(shù)據(jù)中心之間工作。

在評估要轉(zhuǎn)移的請求部分時，Traffic Manager執(zhí)行以下操作：

Traffic Manager確定需要從數(shù)據(jù)中心或數(shù)據(jù)中心的子部分移出的請求的比例，以便能夠服務(wù)所有請求。

然后，Traffic Manager計算每個目標(biāo)的匯總空間指標(biāo)，以查看每個故障轉(zhuǎn)移數(shù)據(jù)中心可以接受多少請求。

然后，Traffic Manager確定我們在每個計劃中需要移出多少流量，并通過Plurimog/Duomog轉(zhuǎn)移計劃的一部分或全部，直到我們移出了足夠的流量。我們首先轉(zhuǎn)移Free計劃客戶，如果數(shù)據(jù)中心中沒有更多Free客戶，我們將轉(zhuǎn)移Pro客戶，然后如果需要，再轉(zhuǎn)移Business客戶。

讓我們看一下弗吉尼亞州的阿什本示例：這是我們的其中一個MCP。阿什本有九個不同的容量子區(qū)，每個子區(qū)都可以接受流量。在8月28日，其中一個子區(qū)（IAD02）出現(xiàn)了一個問題，導(dǎo)致它能夠處理的流量減少。

在這段時間內(nèi)，Duomog將更多流量從IAD02轉(zhuǎn)移到阿什本內(nèi)的其他子區(qū)，確保阿什本始終在線，在這一問題持續(xù)期間性能沒有受到影響。然后，一旦IAD02再次能夠接受流量，Duomog就自動將流量轉(zhuǎn)移回來。下面的時間序列圖中可以看到這些操作的可視化，其中跟蹤了IAD02內(nèi)部在子區(qū)之間隨時間轉(zhuǎn)移的流量百分比（以綠色顯示）：

Traffic Manager如何判斷要轉(zhuǎn)移多少流量？

盡管我們在上面的示例中使用了每秒請求數(shù)，但是在實際轉(zhuǎn)移流量時，使用每秒請求數(shù)作為度量是不夠準(zhǔn)確的。這是因為不同的客戶對我們的服務(wù)有不同的資源成本；一個主要從緩存中提供服務(wù)而禁用WAF的網(wǎng)站，與一個啟用所有WAF規(guī)則而禁用緩存的網(wǎng)站相比，在CPU時間使用方面要便宜得多。因此，我們記錄每個請求在CPU中占用的時間。然后，我們可以聚合每個計劃的CPU時間，以找到每個計劃的CPU時間使用情況。我們以毫秒為單位記錄CPU時間，并取每秒的值，結(jié)果的單位是毫秒/秒。

CPU時間是一個重要的度量，因為它可能對延遲和客戶性能產(chǎn)生影響。例如，考慮一下用戶請求完全通過Cloudflare前線服務(wù)器所需的時間：我們稱之為cfcheck延遲。如果這個數(shù)字變得過高，那么我們的客戶會開始注意到，而且體驗將變差。當(dāng)cfcheck延遲變高時，通常是因為CPU利用率很高。下圖顯示了95百分位cfcheck延遲與同一數(shù)據(jù)中心中所有機(jī)器CPU利用率的關(guān)系，可以看到很強(qiáng)的相關(guān)性：

因此，讓Traffic Manager查看數(shù)據(jù)中心的CPU時間是一種非常好的方式，以確保我們?yōu)榭蛻籼峁┳罴洋w驗，而不會造成問題。

在獲得每個計劃的CPU時間之后，我們需要弄清楚有多少CPU時間可以轉(zhuǎn)移到其他數(shù)據(jù)中心。為此，我們匯總所有服務(wù)器的CPU利用率，以獲得整個數(shù)據(jù)中心的單一CPU利用率。如果數(shù)據(jù)中心中的部分服務(wù)器由于網(wǎng)絡(luò)設(shè)備故障、電源故障等原因而出現(xiàn)故障，那么到達(dá)這些服務(wù)器的請求將由Duomog自動路由到數(shù)據(jù)中心的其他地方。隨著服務(wù)器的數(shù)量減少，數(shù)據(jù)中心的整體CPU利用率將增加。Traffic Manager為每個數(shù)據(jù)中心設(shè)置了三個閾值：最大閾值、目標(biāo)閾值和可接受閾值。

最大閾值：性能開始下降的CPU水平，Traffic Manager將在此水平采取行動

目標(biāo)閾值：Traffic Manager將嘗試將CPU利用率降至這個水平以恢復(fù)最佳用戶服務(wù)

可接受閾值：在此水平，數(shù)據(jù)中心可以接收從另一個數(shù)據(jù)中心轉(zhuǎn)發(fā)的請求，或者撤銷活動的轉(zhuǎn)移

當(dāng)數(shù)據(jù)中心超過最大閾值時，Traffic Manager會取所有計劃的總CPU時間與當(dāng)前CPU利用率的比值，然后將其應(yīng)用于目標(biāo)CPU利用率以找到目標(biāo)CPU時間。通過這樣做，我們可以將擁有100臺服務(wù)器的數(shù)據(jù)中心和擁有10臺服務(wù)器的數(shù)據(jù)中心做類比，而無需擔(dān)心每個數(shù)據(jù)中心中的服務(wù)器數(shù)量。假設(shè)負(fù)載線性增加-這便足以印證我們的目的了。

目標(biāo)比率等于當(dāng)前比率：

因此：

從當(dāng)前CPU時間減去目標(biāo)CPU時間，我們得到要轉(zhuǎn)移的CPU時間：

例如，如果整個數(shù)據(jù)中心的當(dāng)前CPU利用率為90%，目標(biāo)為85%，并且所有計劃的CPU時間為18000，那么我們將有：

這意味著Traffic Manager將需要轉(zhuǎn)移1000 CPU時間：

現(xiàn)在我們知道了需要轉(zhuǎn)移的總CPU時間，我們可以遍歷計劃，直到達(dá)到所需的轉(zhuǎn)移時間。

最大閾值是多少？

我們經(jīng)常遇到的一個問題是確定Traffic Manager應(yīng)該在哪個點對一個數(shù)據(jù)中心開始采取行動——它應(yīng)該觀察什么指標(biāo)，什么是可接受的水平？

如前所述，不同的服務(wù)在CPU利用率方面有不同的需求，并且在許多情況下，數(shù)據(jù)中心具有非常不同的利用率模式。

為了解決這個問題，我們求助于機(jī)器學(xué)習(xí)。我們創(chuàng)建了一項服務(wù)，其將根據(jù)面向客戶的指標(biāo)自動調(diào)整每個數(shù)據(jù)中心的最大閾值。對于我們的主要服務(wù)水平指標(biāo)（SLI），我們決定使用前面描述的cfcheck延遲度量。

但是我們還需要定義一個服務(wù)水平目標(biāo)（SLO），以便我們的機(jī)器學(xué)習(xí)應(yīng)用能夠調(diào)整閾值。我們將SLO設(shè)為20毫秒。將我們的SLO與SLI進(jìn)行比較，我們的第95百分位cfcheck延遲不應(yīng)該超過20毫秒，如果超過了，我們需要采取行動。下圖顯示隨著時間的推移，第95百分位的cfcheck延遲，當(dāng)cfcheck延遲進(jìn)入紅色區(qū)域時，客戶開始變得不滿：

如果當(dāng)CPU利用率過高導(dǎo)致客戶體驗變差，那么Traffic Manager最大閾值的目標(biāo)就是確?？蛻舻男阅懿皇苡绊懀⒃谛阅荛_始下降之前開始重定向流量。在預(yù)定的時間間隔內(nèi)，Traffic Manager服務(wù)將為每個數(shù)據(jù)中心獲取一系列指標(biāo)，并應(yīng)用一系列機(jī)器學(xué)習(xí)算法。在清理數(shù)據(jù)的異常值后，我們應(yīng)用一種簡單的二次曲線擬合，我們目前正在測試一種線性回歸算法。

在擬合模型之后，我們可以使用它們來預(yù)測當(dāng)SLI等于我們的SLO時的CPU使用情況，然后將其用作我們的最大閾值。如果我們根據(jù)SLI繪制CPU值，可以清楚地看到為什么這些方法對我們的數(shù)據(jù)中心如此有效，正如以下關(guān)于巴塞羅那示例的圖表所示，它們是分別根據(jù)曲線擬合和線性回歸擬合繪制的。

在這些圖表中，垂直線是SLO，這條線與擬合模型的交點代表將用作最大閾值的值。這個模型已經(jīng)被證明非常準(zhǔn)確，而且我們能夠顯著減少SLO違反情況。讓我們看一下我們在里斯本開始部署這項服務(wù)時的情況：

在更改之前，cfcheck延遲持續(xù)出現(xiàn)峰值，但由于最大閾值是靜態(tài)的，所以Traffic Manager沒有采取行動。但是在7月29日之后，我們看到cfcheck延遲從未達(dá)到SLO，因為我們在持續(xù)測量以確保客戶永遠(yuǎn)不會受到CPU利用率增加的影響。

流量發(fā)送到哪里？

在獲得最大閾值后，我們需要找到第三個CPU利用率閾值——可接受閾值，這個閾值在計算需要轉(zhuǎn)移多少流量時沒有使用。當(dāng)一個數(shù)據(jù)中心低于這個閾值時，它有未使用的容量，只要它本身不轉(zhuǎn)發(fā)流量，就可以在需要時供其他數(shù)據(jù)中心使用。為了計算出每個數(shù)據(jù)中心能夠接收多少數(shù)量，我們使用與上述相同的方法，將“目標(biāo)”替換為“可接受”：

因此：

從可接受的CPU時間中減去當(dāng)前CPU時間，我們得到數(shù)據(jù)中心可接受的CPU時間值：

為了找到發(fā)送流量的位置，Traffic Manager將獲取所有數(shù)據(jù)中心的可用CPU時間，然后根據(jù)到需要轉(zhuǎn)移流量的數(shù)據(jù)中心的延遲對它們進(jìn)行排序。它會遍歷每個數(shù)據(jù)中心，根據(jù)最大閾值使用所有可用容量，然后再移動到下一個數(shù)據(jù)中心。在查找要轉(zhuǎn)移哪些計劃時，我們從最低優(yōu)先級的計劃到最高優(yōu)先級，但在尋找要發(fā)送它們的目的地時，我們以相反方向操作。

為了更清楚地說明這一點，讓我們舉一個例子：

我們需要從數(shù)據(jù)中心A轉(zhuǎn)移1000個CPU時間，我們有以下每個計劃的使用量：Free：500毫秒/秒，Pro：400毫秒/，Business：200毫秒/秒，Enterprise：1000毫秒/秒。

我們將轉(zhuǎn)移100%的Free（500毫秒/秒），100%的Pro（400毫秒/秒），50%的Business（100毫秒/秒），以及0%的Enterprise。

附近的數(shù)據(jù)中心有以下可用的CPU時間：B：300毫秒/秒，C：300毫秒/秒，D：1000毫秒/秒。

延遲為：A-B：100毫秒，A-C：110毫秒，A-D：120毫秒。

從需要采取行動的最低延遲和最高優(yōu)先級的計劃開始，我們可將所有的Business計劃CPU時間和一半的Pro計劃CPU時間轉(zhuǎn)移到數(shù)據(jù)中心B。接下來我們會移動到數(shù)據(jù)中心C，并能夠轉(zhuǎn)移剩下的Pro計劃，以及20%的Free計劃。剩下的Pro計劃可以轉(zhuǎn)發(fā)到數(shù)據(jù)中心D。結(jié)果是以下操作：Business：50%→B，Pro：50%→B，50%→C，F(xiàn)ree：20%→C，80%→D。。

撤銷操作

就像Traffic Manager不斷保持?jǐn)?shù)據(jù)中心不超過閾值一樣，它也尋求將任何轉(zhuǎn)發(fā)的流量恢復(fù)到正在轉(zhuǎn)發(fā)流量的數(shù)據(jù)中心。

在上面，我們看到了Traffic Manager如何計算一個數(shù)據(jù)中心能夠從另一個數(shù)據(jù)中心接收多少流量——它稱之為可用CPU時間。當(dāng)有活動的轉(zhuǎn)移時，我們使用可用的CPU時間將流量帶回數(shù)據(jù)中心——我們總是優(yōu)先考慮恢復(fù)活動的轉(zhuǎn)移，而不是接受來自另一個數(shù)據(jù)中心的流量。

將以上組合在一起，就能得到一個系統(tǒng)，它不斷地測量每個數(shù)據(jù)中心的系統(tǒng)和客戶健康指標(biāo)，并分散流量，以確保每個請求都可以在我們網(wǎng)絡(luò)當(dāng)前狀態(tài)下得到服務(wù)。當(dāng)我們將所有這些在數(shù)據(jù)中心之間的轉(zhuǎn)移放在地圖上時，它看起來像這樣，這是一個小時內(nèi)Traffic Manager所有轉(zhuǎn)移操作的地圖。這張地圖并沒有顯示我們?nèi)康臄?shù)據(jù)中心部署，但它確實顯示了這段時間內(nèi)正在發(fā)送或接收被轉(zhuǎn)移流量的數(shù)據(jù)中心：

紅色或黃色的數(shù)據(jù)中心正在承受負(fù)載，并將流量轉(zhuǎn)移到其他數(shù)據(jù)中心，直到它們變?yōu)榫G色，這意味著所有的指標(biāo)都顯示為健康。圓圈的大小表示從這些數(shù)據(jù)中心移出或轉(zhuǎn)移到這些數(shù)據(jù)中心的請求數(shù)量。流量的轉(zhuǎn)移方向由線條的移動方向指示。這在全球規(guī)模上難以看到，因此讓我們放大到美國，看看在同一時間段內(nèi)的實際情況：

圖中可以看到多倫多、底特律、紐約和堪薩斯城由于硬件問題無法服務(wù)一些請求，因此它們會將這些請求發(fā)送到達(dá)拉斯、芝加哥和阿什本，直到用戶和數(shù)據(jù)中心恢復(fù)平衡。一旦底特律等數(shù)據(jù)中心能夠處理它們接收到的所有請求，而無需將流量發(fā)送出去，底特律將逐漸停止向芝加哥轉(zhuǎn)發(fā)請求，直到數(shù)據(jù)中心的問題得以完全解決，此時它將不再轉(zhuǎn)發(fā)任何東西。在以上整個過程中，最終用戶都是始終在線的，底特律或任何其他發(fā)送流量的地點可能發(fā)生的任何物理問題都沒有對最終用戶造成影響。

網(wǎng)絡(luò)順暢，產(chǎn)品正常運行

因為Traffic Manager與用戶體驗息息相關(guān)，所以它是Cloudflare網(wǎng)絡(luò)的基本組成部分：它讓我們的產(chǎn)品保持在線，并確保它們盡可能地快速、可靠。它是我們的實時負(fù)載均衡器，通過只將必要的流量從出現(xiàn)問題的數(shù)據(jù)中心轉(zhuǎn)移出去，幫助我們的產(chǎn)品保持快速運行。由于轉(zhuǎn)移的流量減少了，我們的產(chǎn)品和服務(wù)保持快速運行。

同時Traffic Manager也可以幫助我們確保Cloudflare的產(chǎn)品始終在線和可靠，因為它允許我們的產(chǎn)品預(yù)測可能出現(xiàn)可靠性問題的地方，并預(yù)先將產(chǎn)品移動到其他地方。例如，Browser Isolation直接與Traffic Manager協(xié)同工作，以幫助確保產(chǎn)品的正常運行時間。當(dāng)您連接到一個Cloudflare數(shù)據(jù)中心以創(chuàng)建一個托管瀏覽器實例時，Browser Isolation首先會詢問Traffic Manager：該數(shù)據(jù)中心是否有足夠的容量在本地運行實例，如果有，就立即在那里創(chuàng)建實例。如果沒有足夠的可用容量，Traffic Manager會告訴Browser Isolation哪個最近的數(shù)據(jù)中心有足夠的可用容量，從而幫助Browser Isolation為用戶提供盡可能最佳的體驗。

網(wǎng)絡(luò)順暢，用戶滿意

Cloudflare運營這個龐大的網(wǎng)絡(luò)，服務(wù)我們所有不同的產(chǎn)品和客戶情景。我們創(chuàng)建了一個具有韌性的網(wǎng)絡(luò)：不但擁有MCP數(shù)據(jù)中心（設(shè)計為減少單一故障造成的影響），還不斷因應(yīng)內(nèi)部和外部問題在我們的網(wǎng)絡(luò)內(nèi)部轉(zhuǎn)移流量。

但那是我們的問題，您無需費心。

如果，把這些問題都交由人工進(jìn)行干預(yù)處理時，受影響的將是我們的客戶和最終用戶。因此，為了確保您始終在線，我們構(gòu)建了一個智能的系統(tǒng)，它可以檢測我們的硬件故障，并預(yù)先在我們的網(wǎng)絡(luò)上平衡流量，以確保它在線并盡可能快速運行。這個系統(tǒng)的工作速度比任何人都快——不僅讓我們的網(wǎng)絡(luò)工程師能夠安枕無憂——還為我們所有的客戶提供了更好、更快的體驗。