阿里云公開了其SIGCOMM2020入選論文《VTrace: Automatic Diagnostic System for Persistent Packet Loss in Cloud-Scale Overlay Network》的內(nèi)容，發(fā)布在微信公眾號“洛神云計算網(wǎng)絡技術(shù)”。
論文繼承了SIGCOMM一貫的務實作風，大部分篇幅集中于對問題本身的剖析以及對技術(shù)路線的介紹，而解決方案本身并不涉及太過復雜的技術(shù)，因此可讀性很強。
論文雖然面向云網(wǎng)環(huán)境，阿里云也在其介紹中特意強調(diào)這是國內(nèi)歷年來唯一一篇云網(wǎng)絡方向的入選論文，但其中討論的核心問題和互聯(lián)網(wǎng)的歷史一樣悠久——網(wǎng)絡狀態(tài)管理，更準確地說，是網(wǎng)絡軟狀態(tài)管理。通常情況下，網(wǎng)絡中的網(wǎng)管系統(tǒng)能夠?qū)W(wǎng)元狀態(tài)（硬狀態(tài)）進行有效的管理，但是這些網(wǎng)元狀態(tài)是以離散個體的形式出現(xiàn)，相互之間的關(guān)聯(lián)性主要取決于網(wǎng)絡拓撲，因此網(wǎng)管系統(tǒng)中的告警也主要是網(wǎng)元級別的告警。
但網(wǎng)元的狀態(tài)和網(wǎng)絡的狀態(tài)并不屬于同一個層面。網(wǎng)絡的狀態(tài)雖然包含網(wǎng)元狀態(tài)，但其側(cè)重點應該是網(wǎng)絡資源組織調(diào)度的狀態(tài)（軟狀態(tài)）。在網(wǎng)絡層，這些狀態(tài)至少應該包括IP路徑的狀態(tài)、端到端連接的質(zhì)量等，但在大多數(shù)網(wǎng)管系統(tǒng)中，這些狀態(tài)是被忽視的。盡管有些第三方供應商專門提供這類產(chǎn)品，但是從實際部署和運用的效果來看，并不理想。其中的原因，我認為在于四個方面：
第一，第三方系統(tǒng)無法直接從網(wǎng)絡設備或網(wǎng)管系統(tǒng)中獲取所需全量信息，因而還原的顆粒度、時效性和準確性都面臨難以克服的障礙。比如很多IP路由狀態(tài)監(jiān)控系統(tǒng)是通過偽裝成路由器加入網(wǎng)絡，獲取路由協(xié)議中的網(wǎng)絡狀態(tài)信息的方式來還原網(wǎng)絡中的路由結(jié)構(gòu)，這些信息對于路由器獨立計算路徑完全夠用，但要推導出其他路由器計算路由的結(jié)果則暴露出很多不足，因為路由協(xié)議的分布式設計模式使每個路由器的計算邏輯或多或少地存在某些細微的隨機性，而這些隨機性并不會通告給其他鄰居。
第二，網(wǎng)絡中的ECMP和NAT等干擾端到端透明性和唯一性的因素進一步增加了精確還原IP路徑信息的難度，對于第三方管理工具來說，這些問題是不可解的。
第三，由于運營商網(wǎng)絡中廣泛存在ECMP，因此即使能夠還原出端到端的IP路徑，其信息量也極為龐雜，以至于會對網(wǎng)管人員造成信息過載，反而無法發(fā)揮出提升排障效率的作用。當然另一個原因是運營商對網(wǎng)絡資源的管理往往在大顆粒度上展開，過于細節(jié)的信息未必真正有用。
第四，運營商供給和管理的網(wǎng)絡資源偏底層且顆粒度很大，更傾向于以資源的冗余供給來對沖管理復雜性帶來的不可控風險，因此更愿意關(guān)心網(wǎng)元狀態(tài)、資源池狀態(tài)而不是每一個連接的狀態(tài)。
這四個方面的原因，植根于基礎(chǔ)設施網(wǎng)絡以網(wǎng)絡為核心的運營模式，但在阿里這樣的互聯(lián)網(wǎng)公司眼里，服務、內(nèi)容、用戶體驗才是一切網(wǎng)絡資源組織調(diào)度行為的核心。這種截然相反的視角，決定了阿里云的網(wǎng)絡狀態(tài)管理無論是需求還是挑戰(zhàn)都完全不同于電信運營商：首先，故障排查的顆粒度要精細到連接級別，更極端一點來說，要能夠解釋每一個用戶體驗問題背后的原因是什么。因為互聯(lián)網(wǎng)公司的選路模式從一開始就不限于IP層，更多是應用層主導，甚至面向每一個具體用戶和應用，因此選路的復雜性也遠遠高于傳統(tǒng)意義上的路由協(xié)議，說每個用戶的轉(zhuǎn)發(fā)路徑都是被單獨計算出來的也不為過。要對如此數(shù)量龐大的路徑信息進行有效的管理，這是前所未有的挑戰(zhàn)。
第二，互聯(lián)網(wǎng)公司眼中的端到端路徑是真正意義上的端到端，這和運營商只能在IP及以下各層對本網(wǎng)內(nèi)的部分負責截然不同。其中除了傳統(tǒng)意義上的路由轉(zhuǎn)發(fā)節(jié)點，還包括大量的應用層網(wǎng)關(guān)和處理系統(tǒng)。對于運營商來說，這些都不屬于網(wǎng)元，但在互聯(lián)網(wǎng)公司眼里，用戶的數(shù)據(jù)包經(jīng)過的每一個單元或功能，都和連接的質(zhì)量息息相關(guān)，因此對連接的狀態(tài)管理也就自然而然地延伸到了IP層之上。
第三，在這樣一個跨域TCP/IP協(xié)議棧各層的復雜巨系統(tǒng)中，OAM卻并沒有系統(tǒng)化和標準化的定義與框架，網(wǎng)絡層與應用層的狀態(tài)信息仍然很難做到按需自由流動，因此端到端連接狀態(tài)管理中的信息透明性問題仍然困擾著大多數(shù)互聯(lián)網(wǎng)公司。在一個系統(tǒng)化的解決方案出現(xiàn)之前，仍然必須依賴定制化工具來以CASE BY CASE的方式來解決問題。
第四，盡管大型互聯(lián)網(wǎng)公司越來越傾向于通過自研的方式解決網(wǎng)絡問題，但很難在自研之初就形成一個清晰可擴展的系統(tǒng)架構(gòu)，很多情況下是根據(jù)需求和規(guī)模的自然演進，逐步完善和迭代，對網(wǎng)絡和連接狀態(tài)的管理也必然要經(jīng)歷這樣一個摸著石頭過河的過程。因此到目前為止，除了谷歌的SRE可以算作是系統(tǒng)化的方法論以外，大部分同行還處在DEVOPS的階段，而很多DEVOPS面臨的問題并不是缺乏自動化運維的算法或功能開發(fā)困難，而是整個網(wǎng)絡以及業(yè)務系統(tǒng)本來就是野蠻生長出來的，設計之初并沒有充分考慮過要為日后運維自動化預留哪些功能和接口，等網(wǎng)絡規(guī)模完美超出人力極限，只能回過頭來以打補丁的方式解決問題。打的補丁足夠多了，補丁自己也經(jīng)過迭代和演化融合為一個獨立的物種之后，才有可能反過來影響網(wǎng)絡和應用的研發(fā)，有目的地向SRE的方向轉(zhuǎn)變。這是一種確定的趨勢，但完成轉(zhuǎn)變需要時間。
阿里云的這篇文章，從一個具體的運維問題入手，以具體問題具體分析的務實態(tài)度，首次給局外人提供了窺視阿里云網(wǎng)系統(tǒng)運行和運維模式的窗口，也從一個細分的側(cè)面反映出中國互聯(lián)網(wǎng)演進的速度以及方向。這篇文章表明，云網(wǎng)狀態(tài)管理絕不是傳統(tǒng)意義上的網(wǎng)絡管理。在阿里云的云網(wǎng)系統(tǒng)中，端到端連接的狀態(tài)無論是在空間、時間還是協(xié)議棧的不同層次都會面臨高度的動態(tài)性，而這些動態(tài)性又往往具有不可預測性，很難依靠一套確定性的邏輯進行推演，只能通過記錄微觀行為日志的方式來還原真相。但要維護全量的連接狀態(tài)數(shù)據(jù)又會對整個云網(wǎng)系統(tǒng)以及運維系統(tǒng)造成難以忍受的負擔，因此采用按需啟動任務、著色抽樣的方式來有目的地對特定連接狀態(tài)進行管理。論文中沒有介紹應用服務生成VTrace任務的規(guī)則以及抽樣的原則，這一方面是由于這些內(nèi)容與VTrace本身的邏輯相關(guān)性不強，說了反而可能喧賓奪主，另一方面，這些規(guī)則和原則的背后，是一套復雜的運維體系，即使要說清楚，也不是那么容易的事情。但我認為這些規(guī)則和原則，要比工具本身更加值得關(guān)注。
以下是轉(zhuǎn)載自阿里云公眾號的正文，技術(shù)細節(jié)內(nèi)容詳實，不需要我再做冗余的解讀。通信和網(wǎng)絡行業(yè)的老兵們，很容易從中看到一些古老技術(shù)的影子，這很正常。互聯(lián)網(wǎng)技術(shù)盡管迭代速度越來越快，但是很多基礎(chǔ)設計理念仍然頑強地存在于互聯(lián)網(wǎng)的基因當中，并在不同的歷史階段顯現(xiàn)出令人驚訝的長期主義價值。
這也是互聯(lián)網(wǎng)的魅力之一。技術(shù)很容易逝去，但技術(shù)背后的理念并不會隨風飄散。
希望國內(nèi)的互聯(lián)網(wǎng)企業(yè)，能夠更加積極地參與到國際交流當中，美美與共，和而不同，獲得更加強大的生命力