作者:JEAN HE

編輯:大愚若智

Uber的成長速度遠遠超出了IPv4的承載能力，為了更好地支援業務擴充套件，Uber的基礎架構需要跟上使用者增速的步伐，必須使用IPv6。2016年，Uber開始推行IPv6資料中心架構，通過對現有基礎架構進行調整來促進業務的擴充套件。本文介紹了為適應Uber工程任務的成長，設計這一全新網路過程中所獲得的最佳實踐，以及通過對基礎架構進行更新以支援IPv6過程中，Uber工程部門學到的經驗。

2014年初，Uber宣佈落地100個城市。而在2016年初，Uber已經遍及全球超過400個城市，不僅提供駕乘，還提供了其他型別的交通運輸服務。與此同時，2015年新年前夜，我們達成了10億次行程的里程碑，並很快於2016年6月達成20億次行程。隨著我們將服務擴充套件至更多城市，這個數字還會繼續飛速攀升，我們也會繼續以可靠的交通服務服務於全球使用者。然而為了繼續提高Uber服務的覆蓋面，我們需要確保工作能夠順利應對IP協議方面遇到的一些挑戰。

Uber目前的基礎架構建於Internet協議版本4（IPv4）地址標準的基礎之上，包含多個數據中心，使用了少量網路入網點（POP）和雲服務。然而Uber的成長速度遠遠超出了IPv4的承載能力，為了更好地支援業務擴充套件，我們的基礎架構需要跟上使用者增速的步伐，必須使用下一代IP：Internet協議版本6（IPv6）。

2016年，Uber開始推行IPv6資料中心架構，通過對現有基礎架構進行調整來促進業務的擴充套件。本文中，我們將介紹為適應Uber工程任務的成長，我們在設計這一全新網路的過程中獲得的最佳實踐，以及通過對基礎架構進行更新以支援IPv6過程中，我們學到的經驗。

從IPv4到IPv6的奮力一躍

根據網際網路協會（ISOC）的介紹，IPv4總共43億個地址已於2011年2月全部耗盡。IPv4地址總數超過40億個，遠遠比不上全球移動裝置總數。再考慮到物聯網（IoT）裝置的飛速增長等因素，我們很快將發現自己開始面臨IP地址“饑荒”。

2011年，全球五大區域性網際網路管理機構（RIR）中的三家，包括亞太網路資訊中心（APNIC）、Réseaux IP Européens（RIPE），以及拉丁美洲和加勒比網路資訊中心（LACNIC）已徹底分配完了自己所有可用IPv4地址。2015年9月24日，美國網際網路號碼註冊機構（ARIN）也宣佈自己的全部IPv4地址已耗盡。

早在1996年就已制定的Internet協議版本6（IPv6）是目前最新版的Internet Protocol（IP）地址標準，提供了大量可解決IPv4所面臨諸多弊端的功能，如更大的地址空間、一種多播基礎規範，以及無狀態地址自動配置（SLAAC）。IPv6可容納超過340澗（Undecillion，10的36次方）個地址，這一數量已經遠遠超過目前全球所有使用者，當然也包括Uber自己對IP地址的需求。

APNIC製作的一個地圖（見上圖）顯示了全球不同國家目前的IPv6部署，很多國家目前的部署依然為零，而比利時已經超過了56%。網際網路協會在2011年進行的全球IPv6使用情況調查發現，自從2012年起，全球主要ISP運營商，尤其是美國的運營商在部署IPv6方面開始加快步伐。北美運營商目前的IPv6部署範圍從27.93%（Cox Communications）到84.36%（Verizon Wireless）各異。

調查還發現，整個網際網路上的IPv6流量正在穩步增加，然而依然遠低於IPv4流量。更重要的是，2017年4月，Google稱其使用者中使用IPv6的比例已達16%，依然使用IPv4的比例為84%；類似的，Web資訊公司Alexa稱截止2017年3月8日，全球排名前1000位的網站中，只有不到20%的使用者在使用IPv6。

專為2014年美國計算機協會大會撰寫的Measuring IPv6 Adoption一文預測說：“到2019年，已分配的IPv6字首數量將約為IPv4的.25-.50，而屆時IPv6與IPv4流量的比例約介於.03到5.0之間。換句話說，IPv6流量依然只在總流量中佔據很小的零頭。”這些結論建議，按照目前的增速，全球對IPv6的接受速度過慢，已無法適應整個世界對網路連線快速增長的需求。

Uber的IPv6部署

目前Uber運維著數萬臺伺服器，整個網路共承載了超過8百萬個IPv4地址。

2014年之前，Uber的資料中心託管在第三方。為滿足我們對容量的需求併為使用者提供更可靠的服務，我們在2014年建立了自己的首個北美資料中心。2015年，Uber對北美資料中心進行了擴充套件，在美國東西海岸建立了更多資料中心；2016年，Uber建立了幾個網路POP點，並將其擴充套件至雲中。隨著2017年來使用者數量持續激增，IPv6部署已開始成為我們後續擴充套件過程中的關鍵一環。

對我們來說，為了維持大規模架構的可靠性，在整個網路中部署IPv6主要有三個原因：

• 更“慷慨”的IP分配：過去幾年來，我們的網路規模增速飛快，資料中心內伺服器機架數已達數千個。我們會從自己的Request for Comment (RFC) 1918 IP空間內為每個機架分配一個/24 IP子網，而目前機架中僅剩48臺伺服器。
• 資源侷限：增長到目前這樣的規模後，我們現有的10.0.0.0/8 IPv4子網中已經有超過50%的地址被用於內部用途。如果不過渡至IPv6，我們的RFC1918（網際網路工程任務組（IETF）有關私有IP地址分配方式的備忘錄）地址空間很快就會耗盡。
• IP地址重疊：按照傳統，Uber的網路中為自己的資源定義了自己的IP地址。當Uber開始與其他公司合併時，不同機構的兩個內部網路中會出現一些重疊的IPv4地址。

經過全面研究、測量以及其他分析後，我們意識到為了支援IPv6部署，我們的基礎架構還有三大領域需要進行更新：

• 網路架構
• 軟體支援
• 供應商支援

首先，我們將介紹Uber資料中心網路中上述三方面內容的構成，隨後將介紹如何面向IPv6的部署做準備。

網路架構

Uber的網路架構包含三個主要部分，接下來分別介紹下。

硬體

Uber使用了統一且一致的硬體，這樣可以更容易地實現模組化、可伸縮的資料中心設計。每個裝置通常會使用相同型號的硬體，因此可以很容易地根據需求進行伸縮。我們的網路裝置可支援通過100G/50G/25G乙太網下行鏈路連線至伺服器。

自動化

以Uber的系統規模來說，網路的構建、管理和運維必須使用自動化工具。我們的網路資料中心可使用零接觸供應工具自動構建，日常網路管理工作中可通過內部開發的自動化工具管理網路配置和IP地址，此外如果哪裡出現問題，智慧監視工具可以向我們發出通知。

網路設計

我們資料中心的設計符合IETF RFC 7938所定義的Clos設計，“在大規模資料中心內部使用BGP進行路由”，該設計方式決定了我們需要使用邊界閘道器協議（BGP）作為動態路由協議。按照網路架構，我們使用了對分（Bisectional）頻寬，可快速收斂（Convergence）並且故障域很少。此外我們還通過構建網路過程中使用的功能集實現了不同供應商產品的互操作性，如下所示：

在Clos設計的基礎上，我們將整個資料中心劃分為模組化的Pod和叢集。每個Pod包含相同數量的伺服器機架，每個叢集包含多個伺服器Pod。因此整個網路可拆分為多個小規模但完全一致的單元，所有Pod之間統一使用高效能網路進行互聯。Uber的資料中心包含多個叢集，所有叢集連線至我們的邊緣骨幹網路，進而連線至網際網路。

為了向Uber的網路提供足夠的頻寬，包括向Hadoop等主要的內部“東西”流量提供支援，我們的叢集架構使用了一種1:1無閉鎖（Unblocking）網路模型，例如下圖展示了我們設施內部的IPv4網路架構：

為了在維持冗餘的同時儘可能讓每個網路層實現最大化的頻寬共享，隨後我們還在網路設計中引入了一種Fabric plane的概念。另外，1:1的無閉鎖超額開通（Oversubscription）率意味著任何伺服器主機均可在維持自己端到端上行頻寬的同時與這個IP設施網路內的其他任何主機通訊。

為了在這種網路架構中部署IPv6，我們為每個伺服器機架和叢集指定了要分配的IPv6地址，其中伺服器機架會被分配一個/64 IPv6子網，叢集會分配並匯聚至子網/n，其中n<64。這些子網會通過一個/32全域性唯一IPv6地址塊獲得地址，這個地址塊是由區域性網際網路管理機構（RIR）分配給我們的，僅限內部網路使用。IPv6的分配和管理工作使用了上文提到的自動化過程。

由於我們的資料中心網路是模組化的，使用了模板化的配置，並且我們的Clos設計自上至下只使用了一種協議：外部邊界閘道器協議（eBGP），相比在從IPv4遷移至IPv6過程中需要重新配置協議的網路設計，我們可以快速簡單地為所有機架分配原生IPv6地址。我們資料中心叢集的每個元件，例如機架子網、Pod子網、環回、帶外（Out-of-band）子網，以及點對點子網均使用了相同的IPv6分配過程。這些自動化的IPv6地址生成工具使用了與我們的IPv4地址分配架構類似的邏輯。

最後，我們的骨幹網路所用的諸如BGP和IS-IS等路由協議可以很輕鬆地通過更新支援IPv6，在運維方面不會產生太多額外的工作量。

軟體支援

為了順利部署IPv6，還需要對整個網路對軟體的支援情況進行更新，尤其是可提升IPv6流量的軟體更是需要重點處理。為軟體實現IPv6的支援需要不同團隊通力協作，涉及到Uber的多個團隊，包括安全工程團隊和站點可靠性工程團隊。

一些工程師所接受的培訓只介紹過如何編寫僅支援IPv4的程式碼，因此他們針對IPv6相容性開發的應用程式和工具也能支援IPv4。IPv4和IPv6地址無論地址長度、字首，以及表現形式等方面都有很大差異，例如在從純IPv4程式碼遷移至可支援IPv6程式碼的過程中，我們遇到了一些常見的應用程式問題，包括：

• 程式碼將字首長度設定為常見的IPv4字首，例如/24，無法適應IPv6字首的長度。
• 會將“a.b.c.d”拆分為”（“a”、“b”、“c”、“d”）元組（Tuple）的程式碼將無法識別IPv6地址，因為拆分是以分號“:”而非句號“.”為依據的。
• 需要將“主機：埠號”，例如“a.b.c.d:8080”拆分為“a.b.c.d”，“80”的程式碼遇到“[2002:a:b:c::ff]:8080”之後會出錯。同理，需要將“a.b.c.d”，“80”組合為“a.b.c.d:8080”的程式碼遇到“2002:a:b:c::ff:8080”會創建出無效的IPv6地址。
• 使用regex匹配IPv4地址的程式碼在收到IPv6地址後會給出無效的結果。
• 通過硬編碼方式指定尺寸的列將IPv4地址儲存為“varchar(16)”的資料庫，會由於“a.b.c.d\0”問題而無法儲存IPv6地址。

Uber的基礎架構使用haproxy在不同地區進行路由。我們廣泛使用諸如haproxy.cfg yaml等配置（config）檔案將不同IPv4地址與對應的主機名儲存在一起。所有服務的配置檔案也需要仔細檢查，並根據不同用途進行更新，以便在為所有主機啟用IPv6後支援IPv6地址。

我們並未使用硬編碼的方式指定IPv4地址，而是在程式碼中使用主機名，隨後通過DNS解決過渡期遇到的問題。目前我們正在對開發者進行培訓，告訴他們如何使用諸如getaddrinfo(3)等IPv6相關支援工具促進整個過渡程序。

供應商支援

大型網路裝置和伺服器硬體供應商多年來一直在積極地為IPv6提供著支援，並且已經順利實現了大量IPv6特性。然而考慮到生產環境中使用IPv6的歷史並不長，並且大家普遍缺乏相關運維經驗，隨著越來越多的組織開始在生產環境中部署IPv6，大家陸續發現了很多bug。IPv6的質量保證（QA）需要努力與IPv4看齊。

隨著越來越多的組織將服務部署在雲端，Amazon AWS、Google GCP，以及Microsoft Azure等雲供應商也加快了對IPv6的支援步伐。

Uber的IPv6部署：現在和未來

Uber目前正在以設計文件，包括IPv6定址機制和特性RFC為指導，對IPv6部署進行實驗室測試。在全面將IPv6部署到生產環境之前，為了發現任何可能存在的問題，還需要在準備環境中進行深入的負載測試。

我們預計可以通過全面部署IPv6立刻獲得下列收益（包括但不限於）：

• 前端：前端將可以直接為原生IPv6流量提供服務。
• 組織合併：面對相互重疊的IPv4地址，IPv6為我們提供了更具伸縮性的解決方案。
• 車輛上下客：目前，Uber為自有車輛提供的車載裝置底座會被解析至一個/24 IPv4子網。當前的這種設計是為了預留IPv4資源同時確保不同工程專案一致的配置。然而IPv6可以通過裝置底座為車輛上下客網路架構提供一種更具伸縮性的解決方案。然而需要注意，僅在使用者的iOS或Android軟體能夠支援的情況下才可以在上下客網路中使用IPv6。行動呼籲：迎接IPv6

企業內部的IPv6部署需要大量規劃，絕不是一種“要麼全有，要麼全無”的實現。為了對網路連線以及技術創新的飛速增長提供更廣泛的支援，我們鼓勵開發者在應用程式層面編寫能同時支援IPv4和IPv6的程式碼。同時我們也希望您能與我們一起在自己的技術圈裡推動IPv6的更廣泛部署。

隨著多方的不斷努力，早期“嚐鮮者”所組成的社群所產生的統計結果和指標也將幫助我們進一步優化IPv6的相關設計和效能，等到IPv4徹底耗盡那天再著手進行就來不及了。通過攜手努力，我們將能共同打造一個更好的網際網路世界。

文章來自微信公眾號 ：聊聊架構