雲時代，本地部署的企業級軟體在不擴容的情況下，能做到短期內十倍的效能提升的確是一件令人側目的成績。
眾所周知，x86 的效能已經被壓榨到了極致，帶著種種疑問 SegmentFault 思否社群採訪了雲杉網路研發總監向陽。訪談中，向陽詳細談了在企業資料中心網路場景下各種時序資料庫的表現，並解釋了雲杉網路如何從工程的角度實現 x86 軟體十倍效能的提升。
向陽：雲杉網路研發總監、網路架構師。負責雲杉研發團隊的管理和 DeepFlow 的架構設計和核心功能實現。
2013 年獲清華大學電腦科學與技術博士學位，師從吳建平教授並獨立實現了世界上第一個基於關聯分析的 BGP 劫持檢測系統，因此摘得 Internet Measurement Conference（ IMC，網路測量領域國際頂級會議）社群貢獻獎。2015年獲得清華大學博士後證照，主要研究方向為雲資料中心網路架構，獲得了多項網路安全、雲資料中心相關專利。
思否：能否請您先介紹一下主要工作經歷，專注的技術研究方向，以及目前所負責的工作。
向陽：我的工作經歷其實比較簡單，在加入雲杉之前，我在清華大學讀博。師從吳建平院士做一些包括域間路由的演算法和結構、域間路由的安全等等方面的工作。畢業後，我接觸到 SDN 的領域，也就順理成章地加入雲杉，然後一直做 SDN 的研發工作直到現在。現在我在公司是研發團隊的負責人和 DeepFlow 產品線的負責人。
思否：隨著業務需求的提升以及雲端計算等相關技術的發展，企業開始建立自己的雲資料中心，其中網路是雲資料中心的重要組成部分之一。您認為現代企業的雲資料中心在網路架構的搭建上通常有哪些痛點？企業應當如何應對這些挑戰？
向陽：我們能看到的企業在去做這一塊的時候，主要的一個挑戰其實可以分為兩個方面，一個方面就是說怎麼去建設，另外一個方面，其實還要去考慮到怎麼樣去維護它。
建設主要解決兩個痛點：一個是網路連通性的問題，一個是網路服務化的問題。
為了支撐業務，首先要把異構的資源、混合雲這些場景下做一個打通和互聯；然後在此之上提供豐富的網路服務，包括像應用交付服務、安全服務等等。
與上述問題平行展開的，是複雜網路的運營維護問題。因為現在網路會相當的複雜，一般來講 IT 基礎設施會同時在公有云、在私有云不同的資源池上，此外還有虛擬化的一個容器資源池。在這樣一套 IT 基礎設施上要打通一個統一的網路，才能支撐業務的靈活需求。
比如說一個業務要想在容器的資源池裡面去拿到幾個 POD，在虛擬機器資源池裡面拿到一些虛擬機器，在裸機資源池裡面拿到幾個物理機來實現一個業務需求，這個時候實際上這些資源池是互相獨立的，但是從網路的視角看（這個業務）是一個整體，要將上述資源池的這些網路打通、做統一的編排，這是一個挑戰。
在此基礎之上，如果說我們把網路做了打通，那麼這個網路維護的難度也是非常高的，不可能再由人工去做維護 —— 如果說這張網增加了 10 倍的複雜度，那就意味著至少要投入 10 倍的人力，這件事難以為繼。
思否：雲杉網路為了幫助企業解決網路運維管理上的挑戰，早在 2016 年的時候就推出了雲網分析產品 DeepFlow，能否請您先介紹一下 DeepFlow的核心元件、功能特點以及應用場景？
向陽：實際上我們把 DeepFlow 的一個解決方案劃分成兩個場景，一個是採集分發，另外一個是分析。那也就對應著DeepFlow的整個產品中的三個核心的元件：採集器、分析器和控制器。
從元件的角度來講，控制器負責中央的管控和大規模（採集器）的管理，因為我們的採集器會執行在很多異構的環境裡面 —— KVM 虛擬化、VMware 虛擬化、公有云的環境、私有云的環境、容器的環境、Linux 的環境以及 windows 的環境 —— 這時採集器的特點是執行的環境異構，另一個特點就是採集器的數量非常大。
控制器它需要做的就是一個集中的大規模的管控；而採集器需要做的就是剛才對於這些異構環境的一個全網覆蓋，包括物理的、虛擬的等等，做一個全網的覆蓋；以及我們需要有一個高效能的策略匹配的演算法。
因為如果對所有的流量資料全部做處理，這個時候的資源開銷將會非常大。有的流量我們可能只是希望看一看，有的流量我們希望把它的一些 counter 記錄下來，還有的流量會進入它的 pcap 檔案，進入它的一些詳細的資料包，以及把一些流量直接分發出去。
不同的流量需求，我們就需要通過一個策略的體系去對它做一個相當於編排。通過匹配，把符合某意圖的一些流量，給到後端對應的消費工具裡面。這樣的話我們在採集這一側是需要有一個較強的策略匹配引擎，再到後面我們的流量除了去分發給第三方的分析工具，傳統的 NMP、DPI 以外，我們還能自己做一些分析，這就是我們的分析器。
我們的分析器主要一個特點，就是通過一個分散式的時序資料庫，來將網路中的所有的狀態和統計資料儲存下來。這相當於對網路的全景檢視做一個刻畫。客戶再去做混合雲場景下的一個網路排障的時候，能把所有的這些關聯點，不同的網路、不同的層面，不同的 Overlay、不同的 Underlay —— 比如說在容器的場景下可能是雙層的 Overlay —— 把它們都聯絡起來。
再回到應用場景。第一個是混合雲上流量的採集和分發。這種應用場景一般是針對於客戶已經有了很多傳統的分析裝置，比如說 DPI 的裝置、NPM 裝置等等，但是他們苦於無法拿到虛擬網路、容器網路裡面的流量。
在虛擬網路的場景下，網路的規模非常大，現在一個伺服器可以虛擬出來 10 個虛擬機器，一個虛擬機器可能又有 10 個 POD，這個數量是非常龐大。因此在虛擬網路裡你不能像傳統物理網路那樣通過分光、映象直接拿流量。我們能做到全網覆蓋，按需的把流量拿出來給到後端的分析工具。
另一個場景就是混合雲的網路診斷，這實際上是網路分析的場景。因為我們看到現在的雲的網路是充分複雜的，這裡面有異構的資源池，有不同層級的 Overlay，我們怎樣在這樣一個複雜的網路環境下去做故障的診斷定位？這需要我們有一個全網流量資料的分析能力，即網路分析。
思否：DeepFlow 自 5.0 版本之後的每次更新都對效能進行了改善，尤其是 5.5.6 版本後核心元件的效能再次大幅提升，這是如何實現的？是否與程式語言和資料庫有關？雲杉為什麼如此看重效能上的提升？
向陽：首先來談一談這些效能的提升是如何實現的，其實總的來講包括幾個方面。採集這一側，我們是對於新技術有一些引入，像 DPDK 以及像 Linux 核心高版本的 XDP 的技術，XDP 對於客戶的環境的依賴是比 DPDK 要低，並且流量的採集效能比我們上一代的技術能有 10 倍的提升。
另外補充說明一下我們對新技術的引入，我們其實是走在了社群的前面，2019 年釋出的 CentOS 8 使用的核心版本對於 XDP 的支援其實並不好，我們也從核心的層面對 XDP 的支援做了一些提升，使得我們能在低版本的 Linux 環境裡面將我們的採集器的效能提升上來。
另外一個方面是分析側，主要我們是基於資料結構和演算法的一個優化。我們整個 DeepFlow 平臺，絕大部分的元件都是基於 Golang，稍後再講我們為什麼會去選擇 Go。我們對它原生的資料結構 —— 像 map 這樣一些資料結構 —— 做了一些非常關鍵的演算法和資料結構上的改變，使得其效能都提升了 10 倍。
這裡面我們有一些專利存在，比如說我們對於 Go 的物件資源池、記憶體池的一些改進，對於 map 的一些改進，這是在分析側的優化。
然後就是在儲存側的優化，我們是基於 InfluxDB 資料庫，對它的核心做了全新的開發，實現了 10 倍讀寫效能的提升，以及具有一個水平擴充套件的能力，更重要的是使它更適合網路的場景。
回過頭來說 Golang，其實和語言的關係還不是太大，如果說我們需要去追求一個極致的效能，我們可能會去選擇比如說像 C 這樣的語言。但這裡還有另外一個問題，就是我們的開發效率和適配性。如果我們用 C 的話，可能對於環境（比如說 glibc 的版本）的依賴會比較嚴重。
Go 其實是一個雲時代的語言，像 Docker 這樣的技術，就是構建在 Go 之上的，其依賴是非常小。我們選擇 Go 能夠在依賴性和開發效率上獲得優勢，此外我們也會去克服它的缺點，像它的 GC 帶來的缺點、它的資料結構帶來的效能問題，這些方面我們都做了提升。
最後說說我們為什麼如此關注於軟體的效率，因為我們是一家軟體公司。硬體公司比如說做盒子的企業會更多地專注於做專用機之類的產品。我們必須做一個雲原生的平臺軟體，這樣它才可以執行在任何的地方 —— 在公有云裡面、私有云裡面、容器裡面 —— 它不應該對於執行環境的作業系統以及物理的機器有任何的假設，而且它還需要在不要求硬體環境的前提下給客戶更大的效益。
也就是說硬體我們是沒有辦法改變的，因此我們需要對軟體的效能有一個極致的追求，這樣才能給客戶帶來價值。
思否：雲杉網路在產品研發過程中曾採用過開源時序資料庫 InfluxDB，那麼 DeepFlow 進行資料庫選型與開發的依據是什麼？在 DeepFlow 持續迭代的 3 年時間中，在資料庫選擇方面是否有經歷過變動？
向陽：回到三年前，我們最初在做這個產品的時候，發現時序資料庫的發展並不好。當時時序資料庫都是基於一些傳統的資料庫來做的，它不是一個直接面向時序資料場景的資料庫。比如說 Elasticsearch，它其實是一個搜尋引擎，但被當做時序資料庫在用。
當時 InfluxDB 的版本是在 0.x 的時代。我們最初同時在使用 Elasticsearch 和 InfluxDB。一方面依賴於 Elasticsearch 的穩定性，以及它的大規模的水平擴充套件能力；另外一個方面我們當時其實也看到了，時序資料是一種新的資料型別，它不能夠直接全部在現有的這些資料庫裡面去儲存，所以我們當時在小範圍內選用了 InfluxDB。
後來我們有一個重要的版本調整，因為 Elasticsearch 作為一個搜尋引擎消耗的資源量實在太大了，它不太適合於時序這個場景，更不太適合在一個大規模網路監控資料的場景下做儲存。因此我們又全部切換到了 InfluxDB，這相當於是我們資料庫選型的第二階段。再往後其實就是第三階段，InfluxDB 在開源的版本里曾經一度存在過叢集的解決方案，但是在某個版本之後被刪掉了 —— 這個功能變成了商用的解決方案。
這是我們切換資料庫的一部分原因，其實另外一部分原因、也是更重要的原因在於我們發現 InfluxDB 不太適合網路的場景。我們用普通的時序資料庫去監控1萬臺伺服器，這 1 萬臺伺服器每個時間點比如說每秒它都會有一個 CPU 的值，那麼其資料量就是每秒 1 萬的量級。
也就是說這些監控資料是和被監控伺服器的數量強相關，但是在虛擬網路場景下，機器（虛擬機器）的數量高出幾個量級。還是上面的場景，這時如果有任意兩個機器之間互訪，這個資料雖然到不了前面所說資料的平方量級，但是仍能高出幾個數量級以上，而且這種訪問的關係還能夠去和其他的維度，比如說協議型別（TCP/UDP）、埠號以及服務的數量直接相關。這裡面的資料是一個非常高維度的儲存，而且是一個相當於稀疏矩陣的儲存，它和經典的時序資料庫的應用場景還是不太一樣。
另外網路的場景下面也存在一些特定的一些需求，比如說查詢一個網段、做一個網段的權重匹配，尤其是網路流量基本都是通過負載均攤的方式給到不同的機器去處理。在這樣大的一個資料體量下，這個時候我們如何去把不同機器處理的結果聚合之後儲存下來，這些場景 InfluxDB 都是不支援的。所以我們基於 InfluxDB 核心的儲存和查詢引擎，在此基礎上做了效能的提升、做了水平擴充套件的支援、做了高可用的支援，以及做了更多的網路資料的查詢、聚合、過濾的支援。這樣最終形成我們現在使用的、自研的網路時序資料庫。
我們其實測過像 Prometheus 這樣的很多後端的長期儲存方案，因為 Prometheus 適合短期的資料儲存 —— 通常就存一到兩天。它有很多後端的儲存，像 S3DB (Simple Sloppy Semantic Database)、VictoriaMetricsDB 等有很多這樣的資料庫。從開源社群的時序資料庫排行來看，InfluxDB 是排在第一位的，但是其他的資料庫會比它的效能測試資料要好看。
這個效能測試其實也是各家測的，而且很重要的一點，其它的資料庫往往是侷限在某個特定的場景下的測試資料比較好看，或者它的使用量還沒有達到廣泛使用的程度。所以我們在考量的時候，也基於InfluxDB去做自己的時序資料儲存。
另外一個層面，現有的時序資料庫都是基於相同的場景，即對物理伺服器進行固定頻率的監控，而網路監控的場景不是這樣。網路監控的物件是海量的一維 IP、二維的 IP 對、三維的 IP 埠號等等，這顯然不是固定頻率的監控，而是一個稀疏矩陣的監控。這種差異性使得我們現在也在考慮，例如所有現存的時序資料庫都在使用 TSM 這種資料儲存結構，因此我們也在這種資料儲存結構上進行下一代產品的研發，使之支援稀疏矩陣的 TSM 特性，以便更好的去儲存和檢索網路資料。
簡單的說，因為 InfluxDB 的使用範圍更廣、更成熟、更穩定，而且其他的時序資料庫在最底層的演算法層面和 InfluxDB 實際上是一樣的。那麼也就是說這個測試效能的差異，可能是測試方法或者使用場景或者其他方面的差異，我們認為這個（測試效能）差異其實是可以忽略的。
思否：雲杉網路在產品研發過程中採用了開源的資料庫元件，目前對開源有什麼想法嗎？
向陽：我們目前還不是一家開源軟體驅動公司，未來我們可能會把一些元件反饋給社群。我們也看到在 InfluxDB 社群版本把叢集的能力拿掉了，我們認為我們的叢集功能做的還是相當好的，它非常方便運維，不依賴於像 zooKeeper 的 ZAB 或者 Raft 這樣的叢集協議，是一個非常適合時序資料場景的高可用的叢集方式。如果我們把自研的叢集實現以及水平擴充套件的查詢能力貢獻到社群，這對於社群的運作可能會有衝擊，因為社群已經把一部分能力放到了商業化的版本里面。
思否：DeepFlow 開放了開發與資料的介面，客戶可以在 DeepFlow 上開發個性化的應用與工具，那麼 DeepFlow 目前支援哪些程式語言？
向陽：對於客戶自定義開發，我們現在提供了兩種方式，一種方式是 API，這個 API 因為它是 Restfull 的，所有的語言都能夠去呼叫。
另一種方式是基於 Python 的 SDK，我們看到 Python 有很多方面的優勢，包括它的使用者基數大、使用門檻低以及擁有豐富的庫，它在資料處理和網路編排等方面有天然的優勢。
思否：未來還會在程式語言的支援上進行擴充套件嗎，比如 Java？這些客戶自行開發個性化的應用會影響 DeepFlow 的效能嗎？
向陽：目前我們在這一個方面的計劃主要是客戶驅動。客戶通過我們的 API 自行開發的應用對 DeepFlow 的效能不會產生什麼影響。在我們的產品模組裡， InfluxDB 儲存引擎之上還有一個分散式的查詢引擎，它主要做很多分散式的計算。實際上 API 呼叫是把計算的任務交給了我們的分析器叢集，大量的工作是在分析器的叢集裡完成的。因此 API 呼叫方的效率不會成為整個查詢鏈條的瓶頸，因為最終給到API呼叫方的資料是一個充分聚合後的資料結果，它的體量和我們在平臺裡面儲存的資料（例如一個月的網路資料）相比遠不是一個量級。不管客戶選擇什麼語言進行自定義開發，DeepFlow 的效能都不會受影響。
思否：當前環境下，網際網路公司在產品研發上大都會選擇敏捷開發、快速迭代的方式。而 DeepFlow 則在 5.0 版本之後實現了軟體架構的解耦，那麼是什麼因素促使你們決定這樣做的呢？您又是如何看待軟體架構穩定性與需求變化快速應對能力之間的平衡的？
向陽：我們在 DeepFlow 研發的過程中，版本迭代週期也在不斷變化。在三年前我們的迭代週期是 6 個月——這對於一家 to B的公司比較常見。但是我們的產品是執行在雲的環境下，快速迭代的能力非常重要。我們必須將產品快速交付給客戶，而客戶的環境對我們來說不是一個可運營的系統，也無法讓我們的產品一天更新多少次。我們需要在這種情況下做一個取捨，確保我們的迭代週期要儘量低、同時產品的穩定性要非常高。
在這樣的背景下，我們做了 DeepFlow 平臺的解耦，使得其迭代週期從三年前的 6 個月逐步降到 3 個月、再逐步降到現在的 6 周，滿足了我們對客戶需求的快速響應 —— 不是在專案中，而是在標準化的產品版本中就能滿足。
我們用產品化的思路應對不斷增長的客戶需求，解耦後的產品分上下兩層，上面是應用層、下面是平臺層。平臺層追求的是高效能和穩定，應用層追求的是靈活性和高效率。在產品迭代過程中，我們可以有選擇的去安排上層和下層的迭代週期。比如說在連續的幾個版本里面，底層的平臺是不需要迭代的，但與此同時，每一個版本我們都可以對上層的應用做更新，以滿足客戶的新需求。
思否：除了實現解耦之外， DeepFlow 在軟體架構上是否還進行了其他方面的調整？原因是什麼？
向陽：我們在 DeepFlow 研發過程中有一個非常明顯的變化，最初我們在做這個產品的時候使用了大量的開源元件，這其實也是很多同類產品的做法，但這對產品的穩定性是一個非常大的考驗。因為開源元件更多的是面向運營，需要有人去值守；因為程式碼不是完全由我們自己掌控的，一旦出了問題，解決的速度也會比較慢。
後來我們慢慢的去切換到了另一種模式，即自研大量的元件。現在我們產品裡完全屬於開源元件的是 MySQL，因為它實在太經典、太穩定，我們不需要對它做什麼改動；除此之外，其他元件都是我們自研的。我們從以前充分使用開源元件走到了自研加使用開源的庫的道路上來。因為開源元件比如 Elasticsearch 的核心其實很穩定，但它的很多周邊元件比如輸入輸出、啟停等操作往往容易發生問題。
我們現在會用一些非常成熟的庫，我們也會像替換 InfluxDB 一樣逐步替換其他元件，現在我們僅僅只是有 InfluxDB 核心的儲存和查詢引擎，但這一部分我們也在慢慢替換，因為 InfluxDB 基於經典的 TSM、不太適用於網路的場景。
思否：產品元件裡 MySQL 跟 InfluxDB 主要承擔的角色有什麼不同嗎？
向陽：MySQL 主要是儲存一些 metadata，我們叫做後設資料，就是一些業務層面的資料；而 InfluxDB 儲存的是時序資料，即有許多資源物件，它們每時每刻都在生成一些統計資料，我們將這部分時間維度上的統計資料存在了 InfluxDB 裡面。
思否：後設資料和時序資料存在不同的地方，查詢時的效能會不會有影響？
向陽：這兩種資料存在同一個地方並不太適合對資料進行維護。比如對於業務資料或者關係型的資料，例如對一個虛擬機器關聯的 Interface、關聯的 IP 怎麼去做增、刪、查、改？
如果每個時間點都去存對應的資訊，一旦虛擬機器本身產生了變化（這種情況經常發生），那麼就需要對它的歷史資料做相應的改變。而時序資料則不同，時序資料是面向特定的物件的固定時間點的統計資料，基本不存在對於歷史資料做修改的情況；唯一需要做修改的場景是在做故障恢復時，或者該物件有變動時。舉個容易理解的例子，數序資料的儲存場景有點就像對電商的產品頁面做儲存，一個 SKU 的商品名、圖片、介紹等屬性（特定物件）很少變動（除非下線），但價格和庫存的實時資料經常在變、甚至一直在變。
思否：DeepFlow 自身的應用在呼叫平臺層的時候跟客戶開發個性化應用時的呼叫有什麼不同？
向陽：區別就是我們給客戶加上一個許可權認證的機制，其他的沒有大的區別。系統原生的應用和客戶自己開發的應用是完全平等的。我們非常重視讓客戶加入整個產品鏈條中來，包括客戶開發一些應用，以及客戶在我們的產品裡生成的資料。
思否：雲杉的客戶主要都是集中在金融、電信、製造這些傳統行業的企業，我們對這些企業的印象一般都是慢。這些客戶的業務沒有那麼多的快速變化，為什麼雲杉要在效能上、在快速迭代上，去做這些極致的提升？
向陽：事實上現在客戶的整體技術環境已經發生了變化，尤其是IT的環境。比如在金融銀行的客戶已經在生產環境大規模使用包括虛擬化、容器、微服務等應用。實際上客戶對新技術的引入是比較快的。另外一個層面，這些客戶以前買的確實都是“盒子”，現在在雲的環境下要去買軟體。如果我們的軟體去消耗了客戶過多的硬體資源，這時軟體的價值其實很難體現出來。
思否：那麼下一階段 DeepFlow 準備將在哪些方面為客戶帶來新的提升？是否能透露 DeepFlow 接下來的研發重點？
向陽：在前面一個階段，我們主要將 DeepFlow 資料的採集能力和一些資料統計的能力進行了產品化。下一個階段主要是提升資料的智慧分析能力。智慧分析能力首先體現在諸如怎樣去對於一個網元裝置前後的流量做關聯等，例如一個防火牆、一個負載均衡器前後的流量，究竟哪些流量屬於同一個會話？一個客戶訪問負載均衡器、負載均衡器又訪問一個後端的主機，這個訪問鏈條該怎麼繪製？這些體現的都是智慧分析能力。
另一個層面是對於不同網路層的關聯，像容器網路的資料和下一層虛擬化網路的資料和再下一層物理網路的資料該怎麼做關聯？在混合雲場景下的這種關聯能給客戶帶來一個完整的、端到端的逐跳診斷能力，這是我們產品演進的一個重要方向。我們現在已經採集了非常多的網路資料，怎樣基於這些網路資料做智慧的基線告警、做故障的告警處理，以及做故障的預警，這都是我們下一步要做的事。
從客戶的使用層面，我們會更多的去關注客戶生成的資料。剛才也提到SDK的方式是一種客戶參與的手段，DeepFlow主要還是做一個資料的平臺，我們不會限定客戶怎麼使用這個平臺，客戶有自己解決問題的想法和思路。我們讓客戶在這個平臺之上去靈活地構建一些監控資料的檢視，能便捷地從這些檢視中DIY自己的監控大屏，這是我們對客戶定製化能力的提升。
思否：DeepFlow 有針對行業做一些調整嗎？
向陽：我們主要是從解決方案的層面做調整。我們會組合上下游的產品構建完整的解決方案去給到客戶，面向不同的場景、解決不同的問題。
思否：對於未來的雲網路工程師來說，您認為可能需要掌握哪些技能才會適應將來雲時代的發展？
向陽：以前對於一個網工來講，面向的是 CLI、有時需要做一些自動化的工作，比如寫 Expect 指令碼去抓一些 SNMP 資料，但這個時代正在慢慢的成為過去。現在的網工可能更多的是從兩個方面提高自己，說到這裡我打個招聘廣告，歡迎對 SDN 有興趣的同仁加入我們：https://www.liepin.com/compan...
首先是自動化。現在一個網工管理的裝置數量級是以前管理的十倍，自動化肯定是必須的。剛才提到的Python其實是比較適合自動化的程式語言，而且它的准入的門檻也不高。
其次是面向複雜系統的資料分析能力。不同崗位的人對一個系統監控資料的需求不盡相同，不能期待有一個產品級的東西點一下滑鼠就能解決所有問題。網路工程師需要具備，基於採集到的資料稍加處理，能夠得到一個自己想要的結果的能力。在網路資料之外可能還有一些系統的資料，例如日誌的資料，怎樣去做這些資料的關聯和分析，目前仍然需要人的創造力。