編者按：UCloud 最新發(fā)布了名為“Sixshot”的可用區(qū)特性，用UCloud VP陳曉建的話說，“可用區(qū)就好比云計算的太祖長拳，看似平平淡淡，但要打得好著實不易?！碧骈L拳屬于南拳流派，共有四套拳路，講求一膽、二力、三功、四氣、五巧、六變、七奸、八狠。有鑒于此，解密「云計算的太祖長拳」系列將在接下來的三篇內(nèi)容里，詳細(xì)介紹UCloud可用區(qū)項目的“一膽、二力、三功”。
本文是解密「云計算的太祖長拳」系列的第三篇（關(guān)注“細(xì)說云計算（CloudNote）”并回復(fù)“太祖長拳”可查閱該系列全部內(nèi)容），我們會和大家一起探討一下我們對網(wǎng)絡(luò)業(yè)務(wù)的后臺服務(wù)（包括管理面程序management plane和控制面程序control plane）所做的重構(gòu)工作。這里最重要的是如何對后端各個模塊做正確的解耦從而使得我們可以做用戶級別的灰度來可控地發(fā)布可用區(qū)這樣一個涉及全局各個業(yè)務(wù)的特性，并且將億萬條用戶數(shù)據(jù)從老的非可用區(qū)架構(gòu)平滑遷移到新的可用區(qū)架構(gòu)上。云計算十年，架構(gòu)師的地位越來越重要說明了什么？架構(gòu)設(shè)計和數(shù)據(jù)遷移方見真功夫，因此本篇選太祖長拳之“三功”為題。
這是一個看似平淡沉悶但實則步步驚心的指尖之舞——如何盡最大可能保證用戶的現(xiàn)網(wǎng)業(yè)務(wù)在切換過程中不受影響是我們最高優(yōu)先級的任務(wù)。誠然，在整個可用區(qū)灰度上線的過程中，我們還是遭遇了很多事先沒有預(yù)料到的故障和挑戰(zhàn)，這一程也遠(yuǎn)不是一馬平川過來的。因此我們也在不斷地總結(jié)和打磨我們的支撐系統(tǒng)和方法論，但長期以來，以下的一些基本思想一直是整個研發(fā)和運維團隊所秉承的底線：
持續(xù)改進(jìn)的能力高于一步到位的完美；
早于客戶探知和快速回滾的能力高于萬無一失的程序邏輯；
主動重構(gòu)的團隊意識高于一勞永逸的個人英雄主義。
UCloud的SDN網(wǎng)絡(luò)服務(wù)的整個后臺邏輯事實上是一個由20多個服務(wù)組成的大型的分布式系統(tǒng)。這些服務(wù)負(fù)責(zé)了SDN業(yè)務(wù)邏輯的方方面面，其中包括（只列舉了主要的）：
我們在可用區(qū)項目進(jìn)行的過程中，遇到的第一個大型的全局性問題就是我們發(fā)現(xiàn)由于之前廣泛遵循的模式（design pattern），所有的manager的前端（Frontend）和后端（Backend）的邏輯都是在一個模塊里實現(xiàn)的（當(dāng)然部署的時候也是這一個模塊同時覆蓋了Frontend和Backend的功能），如下圖：
這個架構(gòu)的主要問題在于服務(wù)的前后端功能是耦合的。在服務(wù)程序邏輯相對簡單，升級變更還相對輕量級的情況下，這里的矛盾還不是特別突出，我們通過嚴(yán)密的監(jiān)控、主動的運營（擴容或重啟服務(wù)等）、及快速的回滾（升級驗證失敗的時候）等手段基本還是能控制整個系統(tǒng)的運行狀態(tài)。但其實之前我們已經(jīng)逐漸發(fā)現(xiàn)這個不同關(guān)鍵路徑程序邏輯間的耦合帶來的問題了：一個十分典型的事例就是曾經(jīng)發(fā)生過的一個現(xiàn)網(wǎng)事故——當(dāng)時有用戶反饋說從某個時間開始，控制臺上的一些網(wǎng)絡(luò)服務(wù)的頁面經(jīng)常有間歇性超時從而無法顯示數(shù)據(jù)的情況。
如上圖所示，我們的官網(wǎng)控制臺是通過API Gateway來調(diào)用Manager上的接口的，因此我們的研發(fā)工程師自然而然地去排查了所有Frontend的運行日志，卻發(fā)現(xiàn)在出現(xiàn)CPU飆高的時間點，F(xiàn)rontend的日志里沒有顯示任何異常的行為。然后我們逐個排查了整條控制臺到Manager調(diào)用路徑上所有服務(wù)（API Gateway，Access層，包括控制臺本身），都沒有發(fā)現(xiàn)任何的問題。正當(dāng)我們一籌莫展的時候，一個偶然的機會，另一位負(fù)責(zé)Manager中Backend功能的同學(xué)提到，由于Backend每秒收到的請求（query per second）較高，所產(chǎn)生的日志也通常比較大，容易占用過多的磁盤空間。因此他提交了一個優(yōu)化的邏輯，會隨機地將一些舊的日志打包并送到遠(yuǎn)端的一個存儲空間里保存起來。而進(jìn)一步分析Backend的運行日志后，我們發(fā)現(xiàn)所有控制臺發(fā)生超時情況的時間點都是和Backend上這個日志打包邏輯的運行時間是吻合的。這個變更對Backend的影響姑且不論，這里最大的問題在于：一個看似旁路的后端邏輯卻直接影響了直接有損用戶體驗的前端服務(wù)，這是十分不應(yīng)該的。
筆者之前在Amazon工作的時候，曾經(jīng)聽過一次內(nèi)訓(xùn)的講座，是當(dāng)時Amazon的Global Payments部門的高級研發(fā)經(jīng)理Thomas Vaughan所做的”Greatest Disaster in Amazon’s History”的演講（這個是Amazon內(nèi)訓(xùn)講座中排名前三的一個演講，可惜由于是內(nèi)部資料，非Amazon的員工無法聽講）。Thomas在講座中總結(jié)了Amazon歷史上最有教育意義的6次重大現(xiàn)網(wǎng)事故并從中總結(jié)了一系列大型分布式系統(tǒng)開發(fā)的原則和規(guī)范，其中第二條就是：
Partition your critical use cases.
也就是說：要注意解耦關(guān)鍵路徑上程序邏輯。很難想象這樣一個簡單的原則卻一直在不斷地被違反（我們可以指出很多的原因，客觀的，主觀的），但事實就是如此。
在可用區(qū)項目中，我們面臨著一個相關(guān)的但更大的挑戰(zhàn)，即：由于整個業(yè)務(wù)邏輯的復(fù)雜性，將一個用戶從非可用區(qū)切換至可用區(qū)，整個操作流程需要經(jīng)過許多個業(yè)務(wù)組的配合聯(lián)動，若強行要求前后端的業(yè)務(wù)同時操作不發(fā)生同步上的問題，那是代價巨大且不現(xiàn)實的，因此我們最終的灰度方案是后端控制面和管理面的邏輯先進(jìn)行切換，然后前端再將用戶切換至新的可用區(qū)界面上（這樣前后端的業(yè)務(wù)組不必一定要同時操作）。但如此我們必定要對Manager中耦合在一起的Frontend和Backend的邏輯進(jìn)行拆分才行：
我們對大部分的后臺Manager做了這樣的重構(gòu)。這樣做也為我們今后打算進(jìn)行的持續(xù)優(yōu)化做了必要的鋪墊。比如，之前整個Manager是用C++編寫的，但拆分后，我們就可以為Frontend和Backend各自選擇更適合它們特性的編程語言和框架 - 當(dāng)前我們正在將整個Frontend用Go語言進(jìn)行重構(gòu)，對于編寫一個基于REST風(fēng)格的HTTP web service來說，用Go語言做開發(fā)，所能獲得的工作效率上的提升是十分顯著的（Go對RESTful風(fēng)格的支持，對異步請求的處理等等，都要明顯優(yōu)于C++）。
做完了Manager的Frontend和Backend的拆分后，我們分別對Frontend和Backend的代碼做了大量的修改以支持可用區(qū)相關(guān)的特性。其中，F(xiàn)rontend部分主要負(fù)責(zé)的是和前端控制臺以及API交互的邏輯，也就是所謂管理面management plane的邏輯，這部分邏輯一般是用戶直接可見或可操作的。Frontend模塊的灰度能力是由上圖中的API Gateway來提供，可以支持按用戶/按API/按控制臺版本等各個維度的轉(zhuǎn)發(fā)調(diào)度。
另一方面，Backend模塊主要負(fù)責(zé)的是與controller交互下發(fā)規(guī)則的邏輯，也就是所謂控制面control plane的邏輯（或者說Backend模塊 + controller共同組成了control plane，直接決定了整個底層SDN網(wǎng)絡(luò)在數(shù)據(jù)轉(zhuǎn)發(fā)面的行為邏輯）。此時對于Backend模塊，我們還是缺乏一個靈活的灰度能力。在此之前，Manager的發(fā)布流程是這樣灰度的：
也就是說，對于后端控制面，我們是按照宿主機的維度來灰度的：通過修改一臺宿主機上controller的指向來決定它所運行的控制面邏輯。這個方式也許在之前的場景下都還可以接受，但在面對可用區(qū)這樣深入徹底的全局特性變更的時候，一臺宿主機粒度的灰度能力還是不夠精細(xì)。這是因為對于基于虛擬化的云計算平臺而言，一臺宿主機上一般都是多租戶（multi-tenant）的（除非是像主機私有專區(qū)之類的特殊主機產(chǎn)品），我們要求的灰度能力是可以按用戶的維度，一個用戶一個用戶地將他們切換到可用區(qū)的服務(wù)上。
正如David Wheeler所言：
All problems in computer science can be solved by another level of indirection.
我們也為controller和各個Manager的Backend之間添加了一層轉(zhuǎn)發(fā)代理（這里以Route Manager為例）：
在Controller Proxy里我們實現(xiàn)了如下能力：
SDN層面的ID到用戶賬戶ID之間的映射（因為數(shù)據(jù)轉(zhuǎn)發(fā)面上的overlay協(xié)議是不關(guān)心用戶的賬戶信息的，因此也不可見）；
高并發(fā)的處理能力（因為數(shù)據(jù)轉(zhuǎn)發(fā)面和控制面之間的交互通信是海量的）；
快速水平擴容的能力（其實就是通過ZooKeeper來添加節(jié)點）。
如此，我們對整個后臺服務(wù)灰度能力的改造就基本完成了。最后，我們還是想提一句，對于模塊間耦合的重構(gòu)一定要持續(xù)主動地進(jìn)行。這次在可用區(qū)項目的過程中對如此大量的服務(wù)程序做一次性的重構(gòu)（可以說是“被迫的”），代價是很大的，整個研發(fā)團隊頂著巨大的壓力加班加點；從項目管理的角度來看，這不是一個很理想的狀態(tài)。而且在時間期限的壓力下，很可能還會做出妥協(xié)而非最合理的架構(gòu)決定，要知道，對于David Wheeler上面那句著名的引語，Kevlin Henney還給出了一句著名的推論：
All problems in computer science can be solved by another level of indirection, except for the problem of too many layers of indirection.
在下一節(jié)中，我們就來討論一下，既然我們做了如此之多的變更和重構(gòu)，我們又是如何保證這些新的邏輯既能實現(xiàn)新的功能，又不會破壞向前兼容性的？靠巨細(xì)靡遺的測試來保障嗎？
移山之術(shù)：管理面程序的灰度和億萬用戶數(shù)據(jù)遷移
UCloud的整個后臺服務(wù)程序在升級到可用區(qū)邏輯的過程中經(jīng)歷了大量的改造，尤其是在SDN網(wǎng)絡(luò)服務(wù)的部分，大量的overlay互聯(lián)互通（內(nèi)網(wǎng)虛擬IP之間的，外網(wǎng)EIP和內(nèi)網(wǎng)UHost之間的）的邏輯都發(fā)生了改變。更為重要的是，為了支持可用區(qū)的邏輯，后臺業(yè)務(wù)信息數(shù)據(jù)庫表的Schema都要經(jīng)過改造，我們面臨的挑戰(zhàn)是將海量的用戶數(shù)據(jù)平行遷移到新的Schema下與新的后臺程序的讀寫邏輯兼容并在這期間不中斷客戶的現(xiàn)網(wǎng)業(yè)務(wù)。
首先，我們清醒地認(rèn)識到：即使我們設(shè)計再復(fù)雜的測試用例，也無法真正覆蓋到生產(chǎn)環(huán)境中錯綜復(fù)雜的用戶場景；并且，如果我們單純地依賴自身的測試，整個項目的實施時間也會變得無法忍受之長。在飛速奔馳的生產(chǎn)環(huán)境的跑車上換引擎的問題我們已經(jīng)在前面討論過了，但在換之前，如何保證這個引擎和車的其他部分是兼容的而不會一換上就將整輛車crash掉，這個是我們要解決的問題。
我們必須在行進(jìn)中的跑車上加一組輪胎讓新的引擎去驅(qū)動，然后看看那組輪胎是不是運行正常，新的引擎和輪胎會接受同樣的駕駛指令——方向盤、油門、排擋等等——并做出它們的響應(yīng)，但不會直接影響原車的行駛，我們只需觀察它們響應(yīng)駕駛指令時的行為是否與平行的原車的行為是一致的，如果有問題，我們可以做停機修正然后再啟動。
這個思路的靈感是來自于一篇Twitch.tv工程師分享的技術(shù)文章《How we migrated over half a billion records without downtime》（注：Twitch.tv是北美第一大的游戲直播門戶，2014年Amazon耗資10億美元收購了它），我們首先來看一下總體的遷移思路：
對當(dāng)前的數(shù)據(jù)庫做一次全量的dump；
開啟“雙讀雙寫”模式將全量的用戶讀寫操作導(dǎo)到新的可用區(qū)程序邏輯上執(zhí)行一遍；
將原數(shù)據(jù)庫的全量dump導(dǎo)入新的數(shù)據(jù)庫內(nèi)；
將第1步和第2步之間“遺漏”的所有操作重新寫入（replay）新的數(shù)據(jù)庫中；
開始驗證新的邏輯和新數(shù)據(jù)庫里的信息適合和原數(shù)據(jù)庫保持一致；
對于任何產(chǎn)生不一致的情況排查并修復(fù)根因；
當(dāng)數(shù)據(jù)一致性達(dá)到100%并保持一定時間的時候，確信新的pipeline可以投入使用了；
按用戶維度將流量切換到新的pipeline上。
下圖完整地呈現(xiàn)了我們整體思路的架構(gòu)：
當(dāng)非可用區(qū)的API接到一個請求時，它會首先執(zhí)行該請求，然后將一個message添加到我們后臺的消息隊列（AMQP協(xié)議）中去，這個message會包含下列信息：
Message: [TimeStamp] [API Operation] [Input Parameter] [Result of the API Operation]
其中“時間戳”的信息是必要的，因為我們在新的邏輯中執(zhí)行這些操作的時候必須保證其時序是不變的。另外對于“讀”操作，我們會在message中帶入原操作的結(jié)果，這樣在新的邏輯上執(zhí)行了同一操作后，我們可以實時地在線校驗兩個操作的返回結(jié)果是否一致。如果不一致的話，DCVE會立刻拋出一個異常告警，然后研發(fā)團隊就會介入排查原因了。對于“寫”操作，由于一般不會直接返回操作后的新數(shù)據(jù)內(nèi)容（有些API可能會），所以我們更多的是依賴離線對賬，但原理也是一樣的。
圖中的DCVE是Data Consistency Validation Engine的縮寫，它主要的任務(wù)就是從消息隊列中讀取包含API操作信息的消息，然后通過一張API映射表將同樣的操作在新的可用區(qū)邏輯上執(zhí)行一遍并比對執(zhí)行的結(jié)果。新的操作在執(zhí)行后，我們通過在線校驗或者離線對賬的手段來驗證兩邊的數(shù)據(jù)是否在語義上保持一致的，如果不是就會拋出異常告警。這樣的機制使我們能實時利用現(xiàn)網(wǎng)真實的用戶操作來驗證我們新編寫的程序代碼，不但省去了我們自己窮舉測試用例的時間，也利用了“眾包”的手段更好地復(fù)現(xiàn)了用戶真實的操作行為，幫助我們更快地定位到那些真正會對用戶使用造成影響的程序bug：
這樣截圖中顯示了我們對其中一個Manager上兩邊的讀寫操作所做的校驗結(jié)果。綠色的是不一致的結(jié)果，紅色的是一致的結(jié)果?？梢钥吹?，前期還是有一定量不一致的結(jié)果的，一般都會對應(yīng)一個或數(shù)個程序邏輯里的bug。在經(jīng)過一段時間的修復(fù)后，我們基本能達(dá)到一個穩(wěn)定的狀態(tài)了。我們發(fā)現(xiàn)的bug里比較有代表性的包括：
異步操作執(zhí)行順序不一致導(dǎo)致數(shù)據(jù)不一致；
批量返回數(shù)據(jù)的時候由于數(shù)據(jù)是不排序的導(dǎo)致不一致；
操作失敗后的重試邏輯在新的服務(wù)里沒有正確實現(xiàn)導(dǎo)致的不一致。
下圖是我們對每一個用戶灰度過程中會遵循的一個標(biāo)準(zhǔn)化流程：
簡單解釋一下每一個階段我們后臺邏輯工作的模式：
大家可能注意到，在Stage 3中，我們還是將切換后的用戶在新可用區(qū)下所做的操作同樣“雙寫”回了老的非可用區(qū)的數(shù)據(jù)庫里（通過調(diào)用非可用區(qū)對應(yīng)的API）。這樣做的原因在于如果我們一旦發(fā)現(xiàn)可用區(qū)的邏輯有重大缺陷的時候，老的數(shù)據(jù)庫中的信息還是和新的數(shù)據(jù)庫保持了一致的，如此我們?nèi)绻枰鼍o急回退的話，也能夠有條件完成。
在本篇技術(shù)分享中，我們詳細(xì)介紹了我們是如何驗證并灰度發(fā)布可用區(qū)這個全局性的產(chǎn)品的。實現(xiàn)一個生產(chǎn)環(huán)境下的大型分布式系統(tǒng)，如果面對的問題數(shù)量級很小，通常很多矛盾都不會暴露出來。
如果所有的新功能都能重起爐灶，也只是在規(guī)模達(dá)到一定量級前一個美好的理想狀態(tài)。真正的困難往往就是在運營海量數(shù)據(jù)和保證現(xiàn)網(wǎng)服務(wù)不回歸這兩個前提下才會集中爆發(fā)出來，而在這兩個前提條件下穩(wěn)定地迭代新的特性和功能，就猶如是給高速飛馳中的跑車更換引擎，是對一個系統(tǒng)和它背后的研發(fā)運營團隊的真正挑戰(zhàn)。僅僅有用戶至上的情懷恐怕還是不夠的，要能拿出切實可行的技術(shù)方案和運營手段來。而這里的方法論、支撐系統(tǒng)、團隊協(xié)同都需要經(jīng)過大量的實戰(zhàn)考驗才能形成。
UCloud的團隊在運營一個超大型的IaaS公有云平臺上已經(jīng)探索了4年時間，我們還是在不斷地發(fā)現(xiàn)可以改進(jìn)的地方，也在不斷地總結(jié)和推廣經(jīng)驗和方法論，同時希望在這方面有實踐的朋友們一起來討論和切磋。感謝大家對這個“可用去特性技術(shù)內(nèi)幕全面解析”系列的關(guān)注，期待聽到您的批評和指正。
問：可用區(qū)對物理范圍的限制有多大？AWS的劃分比較大，比如亞太是一個區(qū)。但是大陸互聯(lián)網(wǎng)鏈路復(fù)雜，互聯(lián)互通一直是個問題，可用區(qū)的架構(gòu)能多大程度上消弭這個障礙。
俞圓圓：一個可用區(qū)理論上一般是一個物理的機房，當(dāng)然也可以由多個物理數(shù)據(jù)中心組成，然后一個區(qū)域（Region）是由多個可用區(qū)組成的，因此這位先生可能問的是一個Region內(nèi)的不同可用區(qū)之間的物理范圍有何限制。
一般來說，可用區(qū)之間除了要保障帶寬，供電，防火，防水，防震等等方面的完全獨立之外，其他最重要的限制就是可用區(qū)之間的網(wǎng)絡(luò)延遲。因為客戶很可能是要基于可用區(qū)來搭建同城異地容災(zāi)的應(yīng)用架構(gòu)，所以網(wǎng)絡(luò)延遲太高是無法接受的。因此也決定了可用區(qū)之間的物理距離一般不會太遠(yuǎn)，而且和連接可用區(qū)的網(wǎng)絡(luò)鏈路的建設(shè)和質(zhì)量有關(guān)，在50-80公里左右是一個正常范圍。
大陸地區(qū)的互聯(lián)網(wǎng)鏈路情況確實很復(fù)雜，UCloud的可用區(qū)之間是通過由雙星型POP點來連接的。這個在我們這個系列的第一篇技術(shù)文章里有詳細(xì)的介紹，大家可以在InfoQ官網(wǎng)找到。POP點是運營商中立的屬性，這樣就較好地規(guī)避了不同數(shù)據(jù)中心間由于歸屬不同運營商造成網(wǎng)絡(luò)鏈路建設(shè)很困難的情況，這里的困難不是說技術(shù)上的，而是說商務(wù)或政策上的，具體我就不展開說了，相信大家如果使用過電信/移動/聯(lián)通/世紀(jì)互聯(lián)/首都在線等等IDC運營商的服務(wù)，應(yīng)該都會有些體會。不同運營商的情況不同，無法一概而論，要慢慢積累經(jīng)驗和商務(wù)關(guān)系。
問：想請教一下可用區(qū)對CDN的依賴如何？現(xiàn)在很多視頻直播應(yīng)用其實幾乎全靠CDN在扛。
俞圓圓：CDN是不依賴于可用區(qū)的，CDN的節(jié)點一般來說都會比云服務(wù)商的數(shù)據(jù)中心要多的多。UCloud現(xiàn)在有10+個數(shù)據(jù)中心（海內(nèi)外），但CDN節(jié)點已經(jīng)有500多個了（還在不斷建設(shè)中）。
問：很多私有云/混合云用戶選擇用OpenStack部署，想問下UCloud可用區(qū)技術(shù)研發(fā)過程中開源項目的占比有多大，自研占比有多大？以及為什么是這樣的占比？
俞圓圓：這個其實不同的業(yè)務(wù)的情況不同，就我所負(fù)責(zé)的業(yè)務(wù)來說，開源與自研大致是 3:7 的比例。我們不想重新發(fā)明輪子，但有很多定制化的需求（比如像ovs內(nèi)核模塊的調(diào)優(yōu)，SDN業(yè)務(wù)邏輯的實現(xiàn)），還有許多相對前沿的項目（比如NFV的實現(xiàn)），還是沒有太多成熟的現(xiàn)成開源方案的。我們研發(fā)團隊的心態(tài)比較開放，也很樂意參加各類社區(qū)的討論和活動，并和很多企業(yè)和團體有合作。
問：實際線上實施的時候，有過切換到非可用區(qū)接口的情況嗎？切換的時候用戶數(shù)據(jù)平面的網(wǎng)絡(luò)會受影響嗎？
俞圓圓：確實發(fā)生過切換后測試外網(wǎng)IP ping不通的情況，或者服務(wù)告警的情況，遇到這些我們檢驗或者監(jiān)控到的異常情況，我們都會盡可能選擇第一時間先回退變更。
問：多可用區(qū)方案中廣播域是覆蓋所有AZ嗎？AWS和阿里云都是把子網(wǎng)限制在一個AZ里。
俞圓圓：廣播域的定義follow經(jīng)典網(wǎng)絡(luò)的行為（這是SDN的一般原則吧，在虛擬網(wǎng)絡(luò)中盡量不改變經(jīng)典網(wǎng)絡(luò)的協(xié)議行為）也就是說廣播域就是主機所處的子網(wǎng)，當(dāng)前子網(wǎng)是不能跨AZ的，因此廣播域也不跨AZ。后續(xù)，我們會支持子網(wǎng)跨AZ，也就是子網(wǎng)變成Region級別的屬性。
問：我想問一個問題，就是剛才有幾張圖都反復(fù)提到了API網(wǎng)關(guān)，這個和SDN里常講到的虛擬路由下的虛擬網(wǎng)關(guān)有什么關(guān)聯(lián)度？還是二者是同一個？
俞圓圓：哦，API網(wǎng)關(guān)是為跨region API做轉(zhuǎn)發(fā)調(diào)度的，也提供了比較完整的灰度能力，和SDN的虛擬網(wǎng)關(guān)沒什么關(guān)系。SDN網(wǎng)絡(luò)中的虛擬網(wǎng)關(guān)是一個邏輯概念，它可能對應(yīng)了一個服務(wù)集群或?qū)嵗?，也可能對?yīng)是一組路由調(diào)度規(guī)則。我覺得后者更符合”虛擬網(wǎng)關(guān)“的實現(xiàn)，就是說，和”物理網(wǎng)關(guān)“不同，”虛擬網(wǎng)關(guān)“主要是SDN網(wǎng)絡(luò)中的一個調(diào)度邏輯。
Y3（俞圓圓），UCloud基礎(chǔ)云計算研發(fā)中心總監(jiān)，負(fù)責(zé)超大規(guī)模的虛擬網(wǎng)絡(luò)及下一代NFV產(chǎn)品的架構(gòu)設(shè)計和研發(fā)。在大規(guī)模、企業(yè)級分布式系統(tǒng)、面向服務(wù)架構(gòu)、TCP/IP協(xié)議棧、數(shù)據(jù)中心網(wǎng)絡(luò)、云計算平臺的研發(fā)方面積累了大量的實戰(zhàn)經(jīng)驗。曾經(jīng)分別供職于Microsoft Windows Azure和Amazon AWS EC2，歷任研發(fā)工程師，高級研發(fā)主管，首席軟件開發(fā)經(jīng)理，組建和帶領(lǐng)過實戰(zhàn)能力極強的研發(fā)團隊。
本文轉(zhuǎn)載自infoQ
