雙十一絲般順滑體驗背後：阿里雲洛神網路虛擬化系統揭秘

摘要：2017年12月20日在北京雲棲大會上，阿里雲高級技術專家梵葉在計算與網路分論壇上做了主題分享《雙十一絲般順滑體驗背後：阿里雲洛神網路虛擬化系統揭秘》。為大家介紹了洛神系統的發展過程，系統架構，高可用性設計和虛擬交換機等重要組件。首次向外界全面揭開洛神網路虛擬化系統的神秘面紗。本文是這次講演的文字整理。

作者：偉耘，阿里雲產品專家

原文地址：http://click.aliyun.com/m/39900/

客觀的說，今年雙11的體驗還是不錯的。我自己作為例子，之前幾年的雙11的0點時候，我自己的購物車的一波提交，一般瞬間進入了排隊狀態，但今年我的體驗明顯不同，一波就成功了。雙11的底層技術，實際上是建立在網路產品的基礎之上的，接下來，我要給大家分享的主題就是，雙11的這一切，我們是如何做到的。我會把阿里巴巴雙11上雲叫做大象在雲上跳舞。為啥說是大象呢，因為雙11的量是在是太大了，想要完美支持雙11真的不是容易的事情，尤其是雙11零點的峰值。大家都知道AWS的ELB的預熱，面對這樣的峰值挑戰一定是無力的。

這裡有幾個數字分享給大家。首先是關於兩個結果的，一個是100%的流量比例都是在雲上的，一個是32.5萬筆每秒的交易峰值。這個交易峰值是什麼概念呢，大家知道么，2009年的時候第一次雙11，交易峰值是200筆每秒，在這個大量的交易下，雲網路穩如泰山。另外三個關於極限性能的值，一個是單一網路的ECS數量，這個是10w台。之前我剛好到深圳拜訪一個客戶，這個客戶是自己在家裡用Openstack搭雲網路玩的，這個客戶剛好給我吐槽，說自己搞了100個計算結點，結果控制器就跪了。另外一個是160G的負載均衡實例的帶寬，我相信這個值已經超過了絕大多數的硬體負載均衡器。最後一個是10分鐘擴容上千台ECS。這個舉個例子，這個彈性的擴容能力在鹿晗曝光戀情的當天發揮了重要的作用。

不是所有的雲計算公司都有機會承受雙11的洗禮，可能除了阿里雲以外的任何一個雲計算廠商都沒有經歷過這樣的體驗。但儘管阿里巴巴是一個非常極致和奇葩的客戶，但除了阿里巴巴之外，阿里雲上面還有數以百萬計的客戶，滿足一個客戶的需求，服務一個客戶也許總是容易的，可以為這個客戶完全定製系統，但同時服務百萬級的客戶，則絕對不是一件容易的事情。

首先，雲上客戶最關心的一定是可用性，誰也不想上了雲以後，服務一天到晚的宕機，所以可用性是雲上客戶的命根子。

除了可用性之外，易用性也是一個非常重要的特點。之前用戶想要拉根專線，組件一張網路，要考慮機房，供電，機位，交換機路由器，網路架構，機房實施等等各種事項，但在雲上組建網路，用戶需要的是只需要點擊一下，網路就會按照用戶需要的樣子創建起來；但是如果要用戶點擊無數下，那也許用戶就要爆粗口了。

搞定了可用性，易用性，用戶這個時候關心的就是彈性和性能，這兩個和用戶體驗息息相關，也是也是用戶降低成本的大殺器。這裡雙11就是一個很好的例子，當用戶需要資源的時候，資源準備的時間，用戶希望是0，當用戶不需要資源的時候，資源銷毀的時候，用戶也希望是0。至於性能，關係到用戶希望用最少的錢，達到最高的效果，這個也是非常關鍵的。

最後一個就是智能，這個怎麼理解呢，舉個例子，剛才我們提到的用戶需要資源和銷毀資源的過程，用戶本質上是這些動作希望自動完成的，當用戶線上出現問題的時候，用戶希望系統本身自動處理掉。

阿里雲網路產品是如何滿足用戶的呢，從表面來看，我們實際上就是靠一套基於API的SDN調度系統，來創建和刪除資源來保證的。而這些產品的背後，就是洛神系統。洛神系統來源於中國的古典神話，我們希望我們的網路產品，和河運的槽道一樣，能夠通暢的連接資源。

洛神也不是一天建成的。

第一代洛神的網路是出現在2011年，這個時候，用戶感知到網路的方式是通過給定的公網和私網，用戶無法自己定義網路，在這個架構下面，網路實際上是不存在虛擬化的，都是物理網路的地址直通到VM裡面搞定的，網路和網路之間也不存在物理的隔離，所有的地址都是一個地址平面裡面，因此這個時候，網路的隔離的ACL等功能，都是在物理交換機上上線的，這個階段，我們稱為洛神的經典網路時期，這個階段，網路基本上沒有彈性。

第二代洛神的網路出現在2014年，這個時候，用戶可以自定義自己的網路了，用戶的拓撲，地址都完全可以自己定義，這個階段我們叫做洛神的vpc階段，在這個階段裡面，由於用戶有了一張網路，那麼一定出現了這張網路如何聯通internet，聯通線下IDC和聯通其他網路的問題。這樣這個階段裡面，洛神的產品設計得到了極大的豐富，各種不同的產品都出現了。

第三代洛神出現在2016年，其實第三代洛神是關於智能調度和用戶體驗的演進。當用戶的網路越來越龐大的時候，用戶一定需要一個更好的方式，讓他雲上的資源和雲下的資源能夠直接聯通。當用戶的資源原來越多的時候，用戶也一定需要一個更好的方式，來管理這些資源，比如帶寬，流量等等。當用戶在全球部署服務的時候，用戶一定希望來自全球的訪問具備智能的調度和就近的接入。

當用戶越來越依賴於雲上，那麼用戶一定希望，雲上的感受不是僅僅是業務的使用，而是不斷提升的可視化，可運維性和不斷的附加值的產生。

這個就是第三代洛神，智能洛神。

好的，接下來，我們來看下，現在的洛神架構是如何支撐這些豐富的特性的。和傳統的SDN的架構一樣，洛神的系統架構也做了控制和轉發的分離。數據面位於左下角，在洛神的數據面裡面包含了常見的計算節點上面的虛擬交換機，這個是數據包在計算結點上面的第一道關卡。除此之外的數據面的重要的角色是網關，網關在洛神中有兩個主要功能，一個是承載常見的網路功能虛擬化單元，也就是我們常說的NFV。另外一個連接兩張不同平面的網路，例如連接公網和線下的IDC。

數據面相當於是洛神系統裡面數據包流動的載體，那麼控制數據包流動的，就是控制平台。洛神的控制平台同樣包含幾個部分，一個是對於設備的管理，這裡包含了對主要的數據面組件虛擬交換機和網關的管理，負責了配置從控制器到設備的下發。另外一個重要的組件是虛擬網路管理，負責了vpc本身的地址分配，vpc內的路由配置等等功能。除此之外了，另外兩個關鍵的組件是本地路由控制器和全局路由控制器。當洛神不再是一個數據中心內部的網路，而是變成了一張跨機房甚至跨地域的全球網路的時候，這兩個控制器就起到了關鍵的作用，一個負責數據中心範圍內的網路互連和路由計算一個負責全球範圍內的網路互連和路由計算。

洛神除了數據面和控制面之外，還有一個主要的組成部分，就是運營平面。虛擬網路的數據面和控制面在源源不斷的產生數據，包括各種運行時的狀態，異常的報警，日誌，有效的處理和消費這些數據，是整體系統穩定的基礎。因此運營平面的一個非常重要的功能。另外一個點，是網路產品的運營數據的處理，這一部分功能也是在運營平台支撐的。

整體來看，數據平台，控制平台和運營平台組成了洛神系統。當然，洛神系統也不僅僅只是支撐了阿里雲的網路產品，阿里云云產品的底層網路，都是由洛神系統來提供支撐。大家可能比較清楚的是阿里雲整體的虛擬化協議棧飛天系統

洛神就是其中的虛擬網路組件。

接下來我來詳細給大家分享下洛神系統的主要的關鍵設計。我們認為，對於公共雲服務的底層技術，穩定性和可用性是優先順序最高的，因此我先來介紹下洛神系統在可用性方面的設計。

當阿里雲的某一個數據中心雲機房開始部署的時候，洛神系統作為最底層的系統，在物理設施部署完成之後會第一個進行部署。這個時候，大家看到，這個機房裡面有計算集群，網關和控制平台。計算集群上面有我們的虛擬交換機組件。

在只有一個雲機房的情況下，我們是沒有辦法做到跨機房的容災的。但是對於數據面和控制面的關鍵結點都是集群部署的，單台服務結點的問題不會對用戶產生任何的影響，同時vm的宿主機當出現宕機等嚴重問題的時候，可以在機房範圍內進行遷移，遷移本身也不會對vm的網路屬性和連通性產生任何的影響。

當第二個雲機房，第三個雲機房建設起來的時候，每個雲機房裡面都會部署集群的網關和控制器結點，而且隨著機房的增多，會自動在雲機房裡面形成環形的備份關係。當一個新的機房建設起來，洛神系統部署之後，會自動加入到這個備份鏈裡面。這樣，當某一個機房的關鍵結點由於異常出現問題的時候，都可以自動在秒級切換到備份機房，由備份機房的洛神系統來提供服務。這個就儘可能保證了首先單台設備的故障不會引發影響，而某個機房的所有結點發生問題，也可以在很快的時間內恢復用戶的業務。

洛神系統可用性的另外一個重要的設計是在於運營平面，而運營平面本身也是洛神系統智能和數據化的關鍵設計。大家如果把洛神系統看成一個整體的交換機，那麼從特性上來看，洛神系統是一個支持流跟蹤的交換機，具有各種豐富的策略。洛神系統的下面是物理網路的設備和交換機，通過洛神系統的流標記的能力和基於policy的策略，可以同時在物理網路和虛擬網路裡面具備流的染色，特定報文的鏡像，採樣，trace等的能力，流量採集的數據等等，這些動作產生的日誌，都會通過SLS採集到jstorm做實時計算，如果流量有異常，會產生報警和日誌給到管理員，部分報警可以觸發故障的自動處理和恢復。還有一部分數據也會離線同步到ODPS，進行更豐富的計算，進而產生數據報表和用戶畫像給到用戶，也可以給到用戶一張炫酷的大屏。這個本質上就是數據化的能力。

介紹完了可用性的關鍵設計，接下來我們看下數據面的虛擬交換機。做過虛擬交換機的同學都知道，虛擬交換機在雲網路裡面是分布最為廣泛的，每台宿主機上面都有一個虛擬交換機，虛擬交換機是vm進出網路的第一道門。在洛神系統裡面，虛擬交換機因為其分散式的角色，承擔了大部分的複雜業務邏輯。網關作為多租戶的設備，複雜業務邏輯的風險一定是更大的，所以這個是虛擬交換機的第一個關鍵設計。

洛神的虛擬交換機也是和普通的交換機一樣，實現了快慢速的分離，這種設計會極大的提升性能。

另外一個設計是業務邏輯的抽象，在洛神虛擬交換機裡面，抽象了常見的網路的處理邏輯，通過簡單的使用policy的匹配-action的觸發，可以配置出各種複雜的邏輯。這個意味著很多複雜的功能實現，最終是不需要修改代碼的，基於policy修改配置即可。

在虛擬交換機的業務邏輯下面，是一個vswtich的baseOS層，有了這個層面，一個是可以適配不同的虛擬化技術，甚至物理機，所以大家看到，像KVM，XEN，容器，物理機等等，都是靠一套vswtich來支撐的。另外一個是適配不同的底層平台，X86,ARM,MIPS都可以運行。這個使得對於版本的管理是最為高效的，而對vswitch的規模來說，版本管理真的是要命的。

看完了vswitch我們來看下整體的數據面。洛神系統支撐的網路產品，今年發布了好幾個性能的值，包括ECS性能等，都還是滿高的，很多友商也緊跟著發布了類型的性能。現在來看洛神系統的數據面，其實最簡單的比喻，就是洛神系統的數據面，本身就是一台巨大的交換機。

大家都知道，交換機的轉發晶元對數據包的處理，都是pipeline的，硬體處理永遠不會停下來，那洛神的數據面也是如此。從一個數據包進入洛神系統開始，到出去洛神系統的整個過程，經歷了洛神系統裡面的各個組件，都是不會被打斷的，這樣只處理一件事情的數據面，一定是高效的。

還有，洛神系統的網路永遠不會因為維護而中斷，這意味著，洛神裡面的所有組件，都支持熱升級。熱升級對用戶只有100-500ms的流量中斷，基本不感知。

另外，洛神系統裡面的關鍵組件vswitch，大家都知道這個組件的變更，由於規模問題是非常棘手的。但洛神的vswtich已經建立了完整的自動發布機制，包括了CI在裡面，所以整體的效率提升是非常顯著的。

回到之前的管理10w台物理機的問題上，其實洛神解決這個問題的方案也不複雜。單個網路裡面放10W台虛擬機，最大的問題是虛擬機的位置表的規模的問題。很多的SDN解決方案都是將配置直接下發到vswitch的，這種解決方案當vm遷移或者新建，銷毀的時候，帶來的配置的變化的量是巨大的。

為了解決這個問題，我們先是設計了一個自學習的協議，用於流量產生的時候來觸發對vm位置表的自學習。同時維護一張帶超時的位置表。之後創建一個高速的cache，用於快速的響應學習的請求。做了這些事情之後，我們發現，現在達到10w的vm的數量的壓力其實也不是太大。

更多技術乾貨敬請關注云棲社區知乎機構號：阿里云云棲社區 - 知乎