摘要： 摘要：2017年12月20日在北京云棲大會上，阿里云高級技術專家梵葉在計算與網絡分論壇上做了主題分享《雙十一絲般順滑體驗背后：阿里云洛神網絡虛擬化系統揭秘》。為大家介紹了洛神系統的發展過程，系統架構，高可用性設計和虛擬交換機等重要組件。

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

客觀的說，今年雙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的數量的壓力其實也不是太大。

點擊查看原文

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的双十一丝般顺滑体验背后：阿里云洛神网络虚拟化系统揭秘的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。