鵝廠如何構建大型基礎網路平臺
鵝廠是一個業務型別非常豐富的網際網路公司,涵蓋了大型社交流量平臺(微信/QQ)、線上遊戲、公有云、媒體(新聞/影片)、移動應用、開放平臺、網際網路金融等,不同型別的業務都有著自己的技術應用特點、業績目標、成本考量體系,從而產生了對後臺技術支撐能力的不同訴求。網路作為基礎架構中的重要一環,也面臨著這些海量業務運營帶來的種種挑戰。好在鵝廠是一個專業技術能力較強、內部合作順暢的生態系統,將“不斷提升使用者體驗”作為統一的技術目標,很多事情就可以分散式合作去完成,基於這一特點,作為鵝廠基礎網路平臺的架構師也深感幸福,因為可以更收斂、更聚焦的去解決一些有共性的重點問題——標準化的基礎網路平臺。
怎麼搭建這個龐大的基礎網路平臺本身是一個非常複雜的議題,網路技術本身在這其中可能只佔據不到20%的分量,為了讓網路規劃、建設、運營形成一個健康的體系,並不斷提升業務系統面向使用者的體驗,需要考慮非常多的問題:包括網路技術選型、公司資源發放趨勢、端到端的運營體系、網路技術發展趨勢、硬體供應鏈管理、綜合成本把控、迭代與穩定運營之間的Trade-off、風火水電、國內/國際通訊環境等等因素,而這其中每一項幾乎都可以寫幾本書來講了。本文則聚焦於網路本身,筆者爭取用通俗易懂的描述,簡單的分享一下鵝廠構建基礎網路平臺的思路。
先看一張鵝廠基礎網路平臺的整體架構圖(如下),網路之所以會演進到今天這個樣子,主要是因為鵝廠網路的價值主體是不斷構建和最佳化的兩個能力—— “連線服務與服務的能力” 與 “連線服務與使用者的能力” ,網路架構的發展必須圍繞著兩個能力來演進。同時,再根據上層業務特點(離線/線上)、地理資源豐富程度(地/電)、ISP網路佈局、災備要求、綜合成本構成等因素,將整體基礎網路平臺分為三大塊:
-
Data Center :資料中心網路,給同一個園區內部所有的伺服器提供高速交換的能力。
-
Edge :邊緣網路,用於對接使用者(ISP)的邊界網路。
-
DCI :資料中心互聯廣域網路,負責將散落在全球的這些Data Center與Edge連線起來。
每一塊網路架構都會遵循整體基礎網路的價值目標,並且結合自身獨有的特點進行演進與最佳化,下面就針對這三大網路架構的構建思路展開進行探討。
資料中心網路
資料中心網路聚焦於“連線服務與服務的能力”,在整個網路投資板塊佔據很高分量,透過多年的積累,資料中心網路已經形成幾萬網元的體量。面對如此體量的網路,一定是需要有一套嚴密的構建體系來支撐的,包括設計、建設、運營、供應鏈管理等環節,因為隨便一個錯誤意味著不可想象的影響範圍和返工量。按照常理來看,資料中心網路是離業務最近的網路,而如此大的體量應該是運營壓力最大的部分,其實這個問題在鵝廠並沒有想象的那麼嚴重,前文提到過,鵝廠是一個專業能力較強、內部合作順暢的生態系統,經過了多年的磨合,上層業務和基礎網路形成了很好的合作默契,業務系統架構(尤其是平臺級業務)的健壯性、容災設計、排程能力達到了非常高的水平,使得基礎網路平臺的架構師可以用標準化、健壯性好的技術來滿足幾乎絕大部分業務對資料中心網路的要求,從而可以有更多精力集中在資料中心網路相關更底層、更專業領域內深耕細作。
關於鵝廠資料中心網路的玩法,或者說要運轉資料中心網路需要具備什麼能力,將這些年的經驗和思路可以稍作總結如下:
-
資料中心網路與基建環境(Campus/Building)深度結合進行整體設計和交付,採用多級CLOS方案進行Campus-level/Building-level的整體端到端設計,包括裝置功耗規劃、裝置上架佈局、佈線規劃、物理故障域規劃等方面,以達到綜合架構、建設、成本、維護上的最優解。要從方法論高度對資料中心組網的CLOS結構有深入研究(上圖是Sigcomm論文中G家的資料中心網路的邏輯圖),這個議題其實沒有想象的那麼簡單,是一整套綜合考慮交換機成本、光成本、風火水電環境、網路技術等一些列問題的方法論體系,關於CLOS網路怎麼搭建,鵝廠架構師甚至總結出了一整套公式演算法,後續會開設專題進行探討。
-
要對交換網路體系架構有較深入的理解,這是網路架構設計最基礎的技術儲備部分,無論是自研交換機還是商用交換機,都對技術開發、測試能力、基礎技術的掌握能力有較高的要求,這裡面涉及的點包括交換晶片、光部件、系統協議棧、對SDK使用的積累等部分。
-
對行業現狀和趨勢的整體分析能力,對行業供應鏈的整體把控能力,並且可以針對行業環境的變化具備敏捷的適應能力。比如隨著伺服器接入速率的不斷提高,在資料中心網路總成本中,光的比重越來越高,要能提前洞察到這些趨勢和變化,並結合自身的情況調整戰略和架構。
-
海量標準化的資料中心網路生產已經成為貫穿全年的常規工作,需要有一整套貫穿架構設計、建設、運營、擴容、資產、變更、退役等生命週期線上自動化管理工具系統,才能保證IDC生產業務的健康運轉,鵝廠在2014年重構了一整套這樣的工具系統,並不斷最佳化迭代,從架構設計到機房退役,都可以線上上完成。
-
運營工具平臺需要從多維度對資料中心網路進行立體監控,包含了白盒監控方法,比如針對網元本身的告警管理與收斂;黑盒監控方案,比如Full-Mesh的Probe反映網路健康狀況;還包括與上層業務之間的對映和互相聯動,比如鵝廠最大的流量平臺微信有大量的伺服器和一整套網路質量監控系統,與網路平臺合作一同快速發現故障並聯動操作隔離。
-
對SDN方法論的正確使用,是需要根據場景來構建SDN體系的工作內容和效用,SDN在資料中心網路更多的是針對大規模網路的Routing適應性問題、集中鏈路狀態維護、擁塞管理、故障遮蔽等方面發力,非常有針對性的解決問題,而不是SDN for ALL。
邊緣網路(海外)
邊緣網路(Edge)聚焦於“連線服務與使用者的能力”,其主要任務就是能將鵝廠的服務以最短的路徑、最好的質量送到全球各地使用者的手上。國內的邊緣網路普遍以靜態對接ISP的形式存在,海外則以BGP對接為主,本章節主要對鵝廠海外的邊緣網路架構進行介紹。
海外ISP數量眾多,導致全球Internet是一個非常複雜的網路環境,如果鵝廠所有的服務都是從海外的Data Center直接送給當地的幾個大ISP從而觸達全球每一位使用者的話,是非常難做到給各地使用者都提供非常好的網路體驗的。鵝廠花了大力氣來解決這個問題:
-
鵝厂部署了很多資源來獲取全球使用者觸達鵝廠各地服務的探測和質量資料,作為業務開展和網路加速的依據,從而可以制定出有針對性的架構方案和建設計劃。
-
邊緣網路用於連線各個ISP,這個連線我們稱之為 “出口” ,出口的型別我們從架構上分為兩種:基於Region的主出口 Edge ,和用於區域網路加速的 Edge-POP 。
-
Edge作為基於Region的主出口往往靠近Data Center,連線了大量的ISP,作為該Region的預設出口。
-
Edge-POP作為區域加速的覆蓋點,其規劃和建設的節奏是綜合眾多依據來考慮的,包括當地網民數量、上層業務規劃、覆蓋質量、當地通訊環境、綜合成本等因素。
-
所有的Edge和Edge-POP可以看成一整個資源池,承載於DCI網路上面。
邊緣網路在技術上也會遇到很多挑戰,即多出口管理能力、流量排程能力、故障恢復能力等。在很早的時候,管理多出口和排程流量還使用的是傳統的網路手段,經常會因為某一個出口的質量惡化,鵝廠網路工程師需要手工登入到網路裝置上用指令碼去調整路由策略,以牽引流量去往質量更好的出口,隨著出口數量的不斷增加,不管是在網路規劃方面還是手工最佳化流量方面,都變的越來越複雜和力不從心。舉一個簡單的例子,當只有兩個出口的時候,規劃和最佳化都非常簡單,要麼雙活要麼主備,誰出問題就關掉誰,動態路由協議會自動收斂,看起來非常簡單,但試想當出口的數量有幾百個甚至上千個的時候,如何規劃這些出口的使用規則?正常情況下每個出口走哪些服務或者使用者的流量?故障或者質量惡化情況下這些出口之間的備份關係如何?還要結合頻寬、成本、互聯ISP網路內部負載情況等因素來進行綜合考慮和設計,這個就變成了非常複雜的議題了,曾幾何時,鵝廠的出口網路裝置上有著幾千行的路由策略命令,有的跟規劃有關,有的跟最佳化有關,有的跟處理故障有關,網路運營變的越來越複雜,而且出口的數量還在迅猛增長。
幾年前,我們就意識到如果不重構這一塊的設計,遲早有一天會玩不下去,正當SDN的浪潮席捲而來,我們借鑑了SDN的思路,並花了不短的時間來構建這一塊的能力,形成鵝廠網路的一個非常重要的競爭力,這個能力的核心就是多出口的集中控制,我們內部稱之為 “用上帝視角來選擇出口和排程流量” 。簡單的來說,我們將所有出口的頻寬、路由、流量、質量、成本、IP與AS對應關係等資訊採集或輸入至中央控制系統中,再開發出一套符合我們業務要求的演算法,實現集中計算,保證各ISP、各地的使用者都能以當下的基礎設施條件下,以最好的網路質量訪來問鵝廠的服務,計算完成後再將執行策略下發到轉發裝置從而牽引流量落地。目前,這一整套體系已經在現網落地,同時,我們還在這個平臺上構建了一套服務層,讓上層業務可以自行開發APP使用這套集中控制系統來實現自己的需求,比如在DDOS就近清洗與一鍵封堵方面、公有云客戶流量自動切換出口方面、平臺級業務區域質量最佳化方面等。
DCI廣域網路
DCI廣域網路同時負責構建“連線服務與服務的能力”及“連線服務與使用者的能力”,即是將鵝廠全球所有Data Center連線起來的網路,是整個基礎網路平臺的重中之重,前文講的多出口流量排程(海外DC與海外使用者之間的流量)也承載在這張廣域網上面。
上圖即為DCI網路架構的示意圖,可以留意到在中間的位置有兩張廣域網,這個設計跟鵝廠的上層業務特點是密不可分的。最初只有一張DCI網路,即DCI for Elastic Services,這張網路承載了所有的廣域流量,是一張過載的網路,我們幾年前開始使用TE技術來提高這張網路的利用率和流量排程能力,使得這張網路的技術迭代和建設擴容成為頻繁的日常工作,而鵝廠平臺級業務的容錯性和架構設計都非常強大,與基礎網路配合也較為默契,使得這張網路得以高速的發展。近些年,金融業務和公有云業務逐漸成為網路保障的重點,這兩種業務和之前鵝廠的大流量平臺級業務的差異較大,對網路質量和可用率都提出了極高的要求,我們為了應對公司業務這方面的變化,開始著手構建了第二張網路(圖中的DCI for Interactive Services),來重點服務這部分業務。關於這兩張網路特點,分別描述如下:
-
DCI for Elastic Services :大流量廣域網,承載了鵝廠90%以上的廣域流量,為大多數鵝廠成熟平臺級業務服務,是一張新技術快速迭代與擴容頻率較高的網路,部分鏈路利用率有時會到達80%以上。
-
DCI for Interactive Services :精品廣域網,服務網際網路金融等對網路質量依賴很強的業務,使用通用、成熟、穩定的技術構建,鏈路利用率控制在40%以下,無新技術迭代,擴容變更頻率也非常低。
前文多次提到,網路架構設計是一個龐大的系統工程,需要考慮非常多的因素,而這些因素中最基礎,以及與網路本身最貼近的部分就是組網與技術選型了。廣域網拓撲按需建設,隨著業務的發展和流量增長,最終形成一張非常複雜的無序拓撲,對比資料中心組網有著顯著的區別,這其中的核心原因大概有以下幾點:
-
網際網路公司分散式架構盛行,即Network as a Computer,網路已經成為業務系統的一部分,需要高頻寬支撐業務系統的靈活構建,而資料中心內頻寬便宜,廣域網頻寬貴且時延高,故高頻寬需求和強耦合業務模組都集中在資料中心內,跨廣域網的業務模組間呼叫和頻寬使用量會謹慎很多。這就形成了資料中心內點到點每伺服器頻寬高,跨廣域網點到點每伺服器頻寬低這一通用現象。
-
對於網路來講,頻寬就意為著成本,成本主要由網元硬體成本和鏈路成本構成。資料中心網元硬體成本佔大頭,鏈路成本低;而廣域網硬體成本佔小頭,鏈路成本極高。
-
綜合以上兩點,資料中心網路通常會使用低成本、高頻寬、特性簡單的網路裝置進行構建,即“Fast and Stupid Fabric”,以最低的成本去儘可去獲取更高的頻寬。而廣域網的頻寬建設擴容會非常謹慎,基本上會按照容量使用情況來進行按需擴容,最終形成無序拓撲。
-
關於流量排程,資料中心內部點到點頻寬管理較為粗放,因為頻寬容易獲取,且網元特性簡單,用CLOS架構堆高頻寬,每個訪問目的地都只有一個方向(ECMP視為一個方向),完全不需要排程。而廣域網拓撲無序,去往一個目的地有很多條非等價的路徑可選,當訪問關係非常龐大,且這些流量在一個無序拓撲中承載的時候,流量排程就不可避免了。
上述四點基本描述了廣域網的特點,這些都是在做架構設計的時候要考慮的最基本的要素,那麼下面就著重介紹一下鵝廠“DCI for Elastic Services”這張廣域網的構建思路。
廣域鏈路極貴,網元硬體成本佔比很低,那麼問題的關鍵就變成在獲得最佳的網路質量的前提下,如何提高鏈路利用率了。拋開網路,任何想提高資源利用率的領域,技術都是最關鍵的因素之一,所以我們在廣域網的技術應用上下足了功夫。試想一下,如果用傳統的路由方法去驅動這張廣域網,只會得到一個結果,就是網路整體利用率不高,但是經常發生區域性擁塞,最佳化團隊每天都在火燒眉毛的擴容,這個結果就比較諷刺了。而這個問題的原因就是傳統的路由方法不夠智慧和感性,感知不到哪裡有資源可以利用,而我們為了解決這個問題而選擇的技術方法是 “集中控制的流量工程系統” ,主體思路描述如下:
-
將“路由控制系統”和“路徑控制系統”解耦,路由跟業務有關,只能決定目的地在哪裡,路徑跟流量走向有關,可以決定源和目的之間可以走哪條鏈路。路由系統算出目的地之後,就交給路徑系統去找到最佳路徑,並準確送到目的地。這個思路,跟我們平時用的網際網路實時導航如出一轍。
-
路由控制系統由於只需要知道目的地,不關心怎麼去往目的地,整體邏輯非常簡單,所以我們使用傳統的BGP來傳遞路由,這一塊不是SDN的,穩定且高效。
-
路徑控制系統則相對複雜很多,好比我們使用導航的時候,目的地只需要輸入一下,而具體路徑則需要根據最短距離、每條路的堵車情況、紅綠燈多少、是否有限行限號等諸多因素進行判斷並計算出最佳路徑。所以路徑控制系統也需要 “上帝視角” ,需要對全域性的拓撲、鏈路負載、時延、甚至鏈路成本進行統一考慮,並經過合理的計算得出最終的結果,所以這一塊就要藉助SDN的思路來解決問題了。鵝廠的做法是路徑集中控制,控制器將全網需要的資訊全部上收,並進行集中計算,最終得出一定數量的點到點Tunnel供路由控制系統使用,並且控制器要實時感知網路故障和流量變化的情況來進行全網最佳路徑最佳化,保證所有的訪問流量都可以實時獲得最好的網路質量。
-
傳統的RSVP-TE也是類似的解決方案,不過稍顯過載和複雜,包括跨硬體平臺互通性問題、網元裝置複雜度高成本高、Tunnel數量太多導致RSVP訊息量的壓力與風險,這些都給大規模的TE部署帶來了一些挑戰,但最大的問題是,所有路徑都是頭端節點計算,不同需求互相搶佔資源,達不到全網整體最優,即沒有“上帝視角”。
-
除此之外,在這張廣域網上還部署了差異化服務,即流量分級,不同等級的流量享受不同級別的服務,在嚴重故障發生時,高階別流量優先保障最好的網路質量,低階別流量可能會被搶佔頻寬而進行繞行甚至丟包。這也是廣域網的核心技術之一,保障重點流量的同時,可以將整體資源利用率提升至很高的水平,形成可靠性和利用率之間的較好平衡。
總結
構建大型基礎網路平臺是一個非常需要團隊耐心和意志力的複雜系統工程,需要非常強的規劃設計能力,但更為重要的是在運營過程中,結合業務規劃的變化、產業鏈的變化、通訊環境的變化、主要矛盾的變化、綜合成本構成的變化等因素,能夠敏捷的跟進和調整。本文涵蓋的內容較廣,筆者用較小的篇幅來講實現細節,而較多的內容聚焦在鵝廠在做這些工作時候的一些思路和經驗,希望能給大家帶來一點點參考價值。
來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/31558022/viewspace-2219757/,如需轉載,請註明出處,否則將追究法律責任。
相關文章
- 工業網際網路平臺架構方案架構
- 如何構建簡單、智慧又可靠的分支工廠 IT 基礎設施?
- 如何構建Vue大型應用Vue
- 如何構建大型的前端專案前端
- 銀保監會:大型網際網路平臺向金融機構收取導客引流費 需加大監管力度
- 建設大型綜合運維平臺,對接整合多廠商網管系統運維
- https構建(基礎)HTTP
- 智慧城市基礎設施建設的PPP模式如何構建模式
- AI基礎軟體:如何自主構建大+小模型?AI模型
- 如何構建一個分散式爬蟲:基礎篇分散式爬蟲
- javascript基礎(this,工廠方法來建立物件,建構函式建立物件)(十六)JavaScript物件函式
- 從智慧城市建設,看如何構建智慧安全基礎設施?
- 如何使用bloomfilter構建大型Java快取系統OOMFilterJava快取
- 朱曄的網際網路架構實踐心得S2E7:漫談平臺架構的工作(基礎架構、基礎服務、基礎平臺、基礎中介軟體等等)架構
- 【工業網際網路】工業網際網路平臺是什麼、幹什麼用、誰來建、瓶頸有哪些、跨行業跨領域工業網際網路平臺怎麼建?...行業
- 構建安全可靠的電子政務網路平臺(轉)
- 人們如何在網路平臺中:探尋和建立社交
- 工廠方法、建構函式、原型物件——JS基礎學習筆記(四)函式原型物件JS筆記
- 如何構建「大型 Node.js 專案」的專案結構?Node.js
- 鵝廠網事:網際網路時代需要怎樣的網管?
- 大型網際網路公司網站架構背後的基礎技術2019網站架構
- 鵝廠網事:基於R.M.B的下一代網管系統
- 如何用Flask中的Blueprints構建大型Web應用FlaskWeb
- 【工業網際網路】工業網際網路平臺建設的四個基本問題
- 【轉載】一步步構建大型網站架構網站架構
- 鵝廠優文|主播pk,如何實現無縫切換?
- python網路爬蟲(9)構建基礎爬蟲思路Python爬蟲
- 如何構建一臺網路引導伺服器(二)伺服器
- LJA網際網路平臺間“拆牆”進展如何?平臺需承擔更多責任
- 大型網站技術架構(二)--大型網站架構演化網站架構
- 大型網站技術架構(一)--大型網站架構演化網站架構
- gf網際網路平臺“拆牆”能否“快進”?
- webgl值得重視的基礎構建Web
- Vue2.0構建——基礎總結Vue
- moell/mojito - 基於 Laravel、Vue、ELement 構建的基礎後臺系統擴充套件LaravelVue套件
- 大型網站架構網站架構
- 雲端計算基礎設施構建:平臺雲化-資料庫雲化建議資料庫
- 如何理解VMware內建於IT基礎架構的原生安全能力?架構