如何借助Anycast技術拯救運維工程師的睡眠？
突然一陣清脆的手機鈴聲響起，把小王從睡夢中拉扯回現實。
“餵，誰啊？”
“王工，我是監控中心的，公司的xxx服務器掛了，你趕緊看一下吧。”
小王揉了揉眼睛，起身打開筆記本電腦，開始了一宿的不眠夜。
作為一名運維工程師，以上橋段經常發生在大家身邊。白天繁重的工作已經讓人筋疲力盡，而夜間作為電話值班工程師，仍不得不面對時刻突發的網絡或系統故障。生活黑白顛倒，日夜不分。
試問，拿什麽來保證運維工程上的睡眠？
再給大家說一個故事。
我有一個朋友，他是Cloudflare的網絡工程師，咱姑且叫他“錢哥”。
我和錢哥閑聊之余，問了問他們的夜間電話值班任務是否繁重辛苦。他淡淡的回答如下：
“我們全世界範圍內如果有某個站點（
我十分不解，你要知道Cloudflare是一家全球CDN服務提供商，據說全世界10%的互聯網流量都運行在他們家網絡上。
常識性來說，擁有如此體量的公司，其中某一個區域性站點down掉是一件極其嚴重的事情。而錢哥的回答卻讓我百思不得其解，完全顛覆了我的認知。
都是工程師，差距如此之大，別人夜晚睡覺，我們機房幹耗！
在我的一番追問之後，總算明白他們其中的奧秘，原來一切都歸功於他們使用了Anycast這技術。
那我們是否也能像錢哥一樣，借助於Anycast技術，還工程師們一個寧靜的睡眠之夜？
科普科普，什麽是Anycast技術？
在IP地址的世界裏，大家熟知的IP地址類型大致有如下幾種：
Unicast IP
單播IP，IP地址和主機是一一對應關系。
如下圖，紅色為數據包發送端，而綠色節點為數據包接收端。
當數據包發送給某一個特定IP地址時，全局下僅有一個數據包接收主機。此為Unicast。
Multicast IP
組播IP，組播IP擁有特定的IP地址段，當數據包發送給此組播IP地址後，組內成員都能收到此數據包的一份拷貝。
如下圖，紅色為數據包發送端，而綠色節點為數據包接收端。
當數據包發送給某一個特定組播IP地址時，同時存在多個數據包接收端。
Broadcast IP
廣播IP，任意Unicast單播網段中最後一個IP地址。數據包發送給此地址會擴散給全廣播域的成員。
如下圖，紅色為數據包發送端，而綠色節點為數據包接收端。
當數據包發送給廣播IP地址時，所有成員均為數據包接收端。
而Anycast IP，則是集Multicast和Unicast特性於一身的特殊IP地址類型
Anycast中文稱為多播IP。
從宏觀上來說，Anycast類似於Multicast，同一種類型的數據流同時存在多個接收者。
而從微觀上來說，Anycast又有著Unicast的唯一性。每一個單獨的IP會話都能夠找到唯一的源主機和目標主機。
咋看之下很矛盾，其實不然.
以DNS請求為例，假設全國人民同一時間發送1百萬個DNS請求，他們都是發送給1.1.1.1的Anycast DNS服務器地址。
宏觀上來說，所有數據包都送達給了分布在全國各地的DNS服務器。處於各地的DNS服務器分別接收到了一定數量的DNS請求，並作出回復。這體現了Multicast的特性。
微觀上，某一個特定的DNS請求數據包，一定是發送給了某一臺DNS主機，而不是同時又多臺DNS主機接收到了此數據包。此為Unicast特性。
如下圖，紅色為數據包發送端，而綠色節點為數據包接收端。
在Anycast 環境下，總的來說，同時存在多個有效的數據包接收端，但是就某一個特定IP數據包而言，僅有一個接收主機。
接收端主機收到了此數據包。
Anycast 到底牛掰在哪裏？
在企業網絡環境中，Anycast不太常見，其主要應用於大範圍的DNS部署，CDN數據緩存，數據中心等。
自然而然，很多做企業網絡維護的朋友會有疑問。怎麽能讓互聯網的多個主機用同一個IP，這豈不是IP地址沖突了？
回答：
首先，每一個服務器主機處在不同的地理位置，他們之間不在同一個廣播域內。所以把所有主機配置成相同的IP地址並不會引起我們日常所見的IP地址沖突。
其次，光靠配置相同的IP地址時不夠的，我們還需要借助強大的BGP幫忙。
通過BGP，各個站點向Internet宣告相同的Anycast IP地址。
自然而然，Internet 就會接收到不同目標路徑，但是具有相同IP地址段的prefix。那數據包是如何在這種環境下路由的呢？
別急，往下看。
為了讓大家有更深刻的理解和認識，下面將詳細描述Anycast的主要優勢和用途
：
用途一：Load-balancing 負載均衡以及系統冗余性
不講理論了，直接上例子，方便理解。
為了闡明使用Anycast和負載均衡，以及冗余性的關系，特舉例如下：
假設我們現在有三個DNS服務器站點，地點分別在北京，上海，廣州。他們服務了全國的DNS解析服務。
按照一般的解決方案，為了實現三個DNS服務器負載均衡，可能有人會考慮到使用硬件負載均衡設備，例如常見的F5負載均衡設備等。
但若使用硬件負載均衡，隨之帶來的問題有：
1. 網絡流量瓶頸，所有有流量都需要先通過負載均衡設備，而硬件設備本身的吞吐量決定了整個網絡環境的吞吐量。
2. 高昂的硬件成本，為了實現全國的流量負載均衡，試想需要多大吞吐量的硬件設備。硬件吞吐量越大，購買成本就越高。
而通過Anycast技術，無需要借助任何第三方負載均衡器，就可以輕松達到負載均衡的效果，同時還提供了冗余和高可靠性。
實施方案如下：
通過配置三個DNS站點的服務器IP為相同IP，例如1.1.1.1/32。然後通過各個站點的BGP對互聯網宣告1.1.1.0/24的網段。
（註：為什麽要宣告/24，而不是/32? 。因為在Internet裏面，為了減小全球Internet路由表尺寸，默認情況下運營商只接受小於等於/8，而大於等於/24的網段宣告進入互聯網。）
以上步驟完成以後，互聯網路由表針對1.1.1.1/24會有三個不同的出口路由器，分別是北京，上海，廣州。
重點來了，因為所有用戶都使用1.1.1.1作為他們的DNS服務器。
以東北的用戶來說，哪一臺DNS服務器會給東北的用戶提供解析呢？
答案就是：就近原則！
讓我們來看看數據包在網絡中的路由細節：
當用戶的DNS請求到達運營商的寬帶路由器以後，運營商的路由器會根據BGP的選路原則選擇到達1.1.1.1的最優路徑。
例如，在用戶寬帶運營商和DNS服務器Internet運營商相同的情況下，最終會以IGP metric為關鍵因素來決定哪個DNS服務器給用戶提供服務。
而IGP的 Metric某種程度上就是物理距離的代表。
如上圖，四川的寬帶路由器通過查看BGP路由，發現1.1.1.1出口最優路由是在廣州。那麽四川用戶的DNS數據包將被發送給廣州的DNS服務器。
同理，東北的用戶DNS解析將會被發往北京的DNS服務器，而江南一帶的則是上海DNS服務器負責。
萬一出現故障怎麽辦？
如果三臺DNS服務器中某一臺出現故障，例如廣東DNS服務宕機。BGP協議會立即停止通告此1.1.1.0/24的網段。Internet 路由表將會只有北京和上海的DNS可供選擇。
此時原廣東DNS服務的用戶將再次根據“就近原則”選擇其他DNS服務器，例如上海DNS。
從而達到業務的平滑遷移和服務的高可用性。
基於以上的分析，我們很容易就得出如下結論：
全國用戶最終會根據距離DNS服務器的遠近來判斷使用哪個DNS服務器做域名解析。
從DNS角度來說，正因為不同的地理位置用戶會根據就近路由判斷，從而選擇不同的DNS服務器，最終會使三臺DNS服務器達到負載均衡的效果。
若其中某一個節點出現故障以後，業務會立即遷移到其他可用的節點上，從而避免網路服務故障。完全不需要人工幹預。
以上就是Anycast在負載均衡中的用途說明。
用途二：防範DDOS攻擊
相信很多在運營商工作的朋友都非常討厭DDOS攻擊。
當DDOS發生時，10G或100Gbps的流量突然蜂擁而來，占用運營商核心MPLS網路帶寬不說，這種洪泛攻擊會給客戶網絡造成短時間的癱瘓。造成的損失極大。
在闡述Anycast防範DDOS攻擊細節之前，讓我們先來看看DDOS是如何產生的。
以NTP協議為例，NTP協議是client-server模式，客戶發起NTP時間查詢申請，服務器響應NTP查詢。看似正常的NTP數據流量有時候及其容易被玩壞。
假設某個黑客控制了成千上萬的僵屍主機，這些僵屍主機紛紛偽造如下數據包並發送給全球NTP服務器：
源地址：1.2.3.4 （偽造源地址為 被攻擊者的IP地址）
目標地址：全球各個NTP服務器地址。（越多越好）
當全世界各地的NTP服務器收到此查詢以後，它會把查詢結果發送回給真正的受害者1.2.3.4。
這時IP地址為1.2.3.4 的受害者收到全世界的NTP服務器發過來的數據包時，其有限的帶寬鏈路就很容易產生擁塞並造成服務中斷。
假設這些僵屍不只是發送一次虛假數據包，而是上萬次。
那麽受害者接收到的NTP回復數據包量將如下：
虛假數據包發送數量 x 全世界NTP服務器的數量= 最終DDOS攻擊的流量。
Anycast如何防範DDOS攻擊？
好了，鋪墊完成以後，回到正題。Anycast如何防範DDOS攻擊？
DDOS攻擊最關鍵一點，是需要把所有地理位置分散的小流量最終匯集到一個點。從而形成濤濤洪水。
正所謂以彼之道，還施彼身。
在Anycast環境下，由於多個地理位置不同的主機同時使用同一個IP地址。正因為如此，DDOS流量在穿越運營商路由器時，路由器會根據地理位置遠近把數據包路由到距離源地址最近的受害者主機站點。從而分散掉整個DDOS流量。
還是以上述NTP協議DDOS為例。
假設IP為1.2.3.4的受害者恰巧布局了Anycast協議。其服務器分布在全國各地。
當DDOS來臨時，不同的NTP服務器根據路由選擇，把流量發送到距離NTP服務器最近的受害者服務器上。
最終，原本10Gbps-100Gbps的匯總流量被各個目標服務器以1Gbps不足的DDOS攻擊消化掉。
如上圖所示，DDOS流量最終被每一個Anycast 主機分散掉了。
大型企業使用案例
既然Anycast好處多多，有多少企業部署了呢？
據我了解，包括Microsoft，Cloudflare，LinkedIn以及其他企業都在全球範圍內使用了Anycast技術。
下面我就以Cloudflare和LinkedIn為例給大家簡單介紹下，他們是如何部署的。
Cloudflare
Cloudflare作為CDN網絡佼佼者，其主要采用了Anycast技術為用戶提供距離用戶最近的Cache服務器。從而大大提高了用戶的服務體驗滿意度。
Cloudflare全球建設了118個數據中心，憑借於Anycast的高冗余性，正如本文開頭提到的，任何一個數據中心出現網絡、系統故障。均不會影響客戶體驗度，所有當地的客戶流量會自動路由到其他就近的數據中心。
上圖為Cloudflare的全球數據中心分布圖
借助於Anycast的優勢，相比傳統企業網絡面對網絡節點故障的脆弱性，Cloudflare這方便就顯得非常遊刃有余了。
下面這張圖為Cloudflare的部分數據中心Pop節點，請重點關註紅框部分。
紅框部分是美國-費城的一個數據中心節點，尾隨其後有一個關鍵字“Re-routed”。
其含義為，此數據中心因為故障或者其他原因不能正常工作，所有費城的Cloudflare用戶流量將會被自動路由到離費城最近的數據中心，無需人工幹預。
看到這裏，有些老鳥就禁不住想問。
Anycast是挺不錯，但是看起來都是例如DNS，或者CDN在使用。
而且，無論是DNS服務提供商還是CDN服務提供商，他們最大的特點在於：每個Pop站點的服務器內容完全一樣，所以客戶無論訪問站點A或者站點B，均能獲取到相同的內容。
那讓我們來看一個不一樣的例子，如下。
LinkedIn大家最熟悉不過了，找工作攀人脈LinkedIn是經常去的地方。
但是你可知道LinkedIn同樣使用了Anycast技術。可是LinkedIn是純粹的網頁內容服務提供商。他與CDN，DNS提供商等性質不太相同。
而且大家需要註意的是，LinkedIn的流量可全是HTTPS，TCP流量。並非一般大家部署的DNS UDP流量。
那為什麽LinkedIn也對Anycast如此感興趣呢？
故事要從幾年前說起。
話說當LinkedIn業務急速擴展以後，出現了用戶體驗度差的問題，原因在於“時延”兩個字。
因為數據中心地理位置固定，而用戶位置可能是全世界各地。很自然，地理位置遙遠的用戶訪問LinkedIn時會產生高時延問題。加上HTTP，HTTPS協議采用了話癆型的TCP協議。
這TCP幾次握手來回以後，加上後續HTTP數據流。本來時延就高的鏈接加上TCP信令數據包一來二去。用戶體驗度非常糟糕。
為了解決以上問題，LinkedIn引入小型數據中心站點(Pops)。在全世界有業務的地方構架小型DC。同時小型DC與美國總部的數據中心之間長期維持著穩定的TCP會話鏈接。
當遠端用戶訪問LinkedIn後，TCP鏈接其實是發送給了當地的小型DC，小型DC再通過已有的TCP鏈接訪問總部DC。從而大大減少了中間TCP信令會話的數量，變相降低了訪問延時，提高了用戶體驗度。
上圖為，在沒有小型數據中心的情況下，人機交互的流程以及時延。
下圖為在用戶所在地部署小型數據中心以後，時延的變化。
哎哎哎，別扯遠了，這和Anycast有半點關系麽？
當LinkedIn在全世界範圍內大批量部署小型DC以後，擺在他們面前的問題是，如何讓用戶能夠就近訪問當地的小型DC，而不是選擇遠端的數據中心總部？
這不就是Anycast擅長的麽？
對，LinkedIn也是這麽想的，於是乎他們把整個美國的小型DC的IP地址修改為相同的IP，並通過BGP發布到Internet。
當用戶訪問LinkedIn時，DNS解析會返回此小型DC 的IP，然後用戶運營商會根據就近原則路由用戶數據到最近的小型DC。從而達到了上面所述的優化延遲的目的。
如下圖所示，通過使用Anycast技術以後，LinkedIn小型DC訪問命中率大大提高。
總結
正如開頭所說，Anycast並不是一個新技術，可謂是舊瓶裝新酒。
但是通過結合BGP協議，變相提高了Anycast的使用廣度和深度。
優點：
Anycast可以零成本實現負載均衡，無視流量大小。
部署Anycast可以獲得設備的高冗余性和可用性。
Anycast適用於UDP和TCP連接。
缺點：
Anycast嚴重依賴於BGP的選路原則，在整個Internet網絡拓撲復雜的情況下，會導致次優路由選擇。
當然，就篇幅有限，不可能把所有內容一一介紹，大家有興趣的話，可以繼續深入研究Anycast的其他妙用。
謝謝大家。
如何借助Anycast技術拯救運維工程師的睡眠？