摘要：在實踐中，我們開發(fā)并上線了網(wǎng)關(guān)和負(fù)載均衡網(wǎng)關(guān)。而負(fù)載均衡網(wǎng)關(guān)則支持無縫替換傳統(tǒng)交換機(jī)實現(xiàn)網(wǎng)關(guān)集群，支持一致性，并支持根據(jù)任意字段，內(nèi)存和端口來計算哈希，支持協(xié)議。

網(wǎng)絡(luò)作為信息時代的重要載體，在云服務(wù)的快速發(fā)展下形成了獨具特色的“虛擬網(wǎng)絡(luò)”服務(wù)架構(gòu)和模式。12月19日，2020中國云網(wǎng)絡(luò)峰會于北京順利召開，會上UCloud虛擬網(wǎng)絡(luò)VPC負(fù)責(zé)人陳煌棟給大家?guī)砹搜葜v《UCloud VPC技術(shù)演進(jìn)之路》，著重介紹了UCloud在虛擬網(wǎng)絡(luò)更新迭代過程中遇到的問題以及如何根據(jù)軟硬件等方面進(jìn)行改進(jìn)的網(wǎng)絡(luò)實踐。

UCloud的VPC網(wǎng)絡(luò)從2012年上線至今經(jīng)歷了三次大的技術(shù)演進(jìn)，從最早的經(jīng)典網(wǎng)絡(luò)過渡到VPC網(wǎng)絡(luò)，并形成了目前軟硬件一體化的VPC 3.0架構(gòu)。

早期的經(jīng)典網(wǎng)絡(luò)

和業(yè)界的發(fā)展歷程類似，在早期，UCloud的數(shù)據(jù)中心網(wǎng)絡(luò)實際以經(jīng)典網(wǎng)絡(luò)為主。云主機(jī)和宿主機(jī)都位于一個大二層網(wǎng)絡(luò)中，網(wǎng)絡(luò)轉(zhuǎn)發(fā)依賴linux bridge，而隔離依賴控制面維護(hù)的iptables、ebtables規(guī)則。

隨著網(wǎng)絡(luò)規(guī)模不斷擴(kuò)大，經(jīng)典網(wǎng)絡(luò)也暴露了諸多問題：

• 規(guī)模問題：依賴大二層的經(jīng)典網(wǎng)絡(luò)規(guī)模受限于廣播域，隨著廣播域擴(kuò)大，廣播風(fēng)暴和交換機(jī)MAC地址表表項不足都會引起網(wǎng)絡(luò)故障，從而限制網(wǎng)絡(luò)規(guī)模；
• 性能問題：由于轉(zhuǎn)發(fā)依賴linux bridge導(dǎo)致轉(zhuǎn)發(fā)性能不高，且隨著iptables隔離規(guī)則的增加導(dǎo)致匹配效率變差，引起性能問題；
• 組網(wǎng)問題：由于經(jīng)典網(wǎng)絡(luò)統(tǒng)一分配IP地址，導(dǎo)致客戶無法決定自己的網(wǎng)絡(luò)結(jié)構(gòu)和網(wǎng)絡(luò)地址空間；同時由于IP不能復(fù)用，導(dǎo)致地址空間不足。

VPC 2.0架構(gòu)：基于SDN技術(shù)實現(xiàn)的VPC網(wǎng)絡(luò)

正是存在以上問題，UCloud在2016年底開發(fā)并上線了基于VPC 2.0架構(gòu)的VPC網(wǎng)絡(luò)，并最終幫助客戶無縫遷移到了VPC網(wǎng)絡(luò)。

在VPC 2.0架構(gòu)中，我們基于SDN技術(shù)實現(xiàn)了網(wǎng)絡(luò)的虛擬化，通過在轉(zhuǎn)發(fā)平面引入OpenVSwitch和OpenFlow完成Overlay流量的轉(zhuǎn)發(fā)與隔離，在控制平面開發(fā)了SDN 控制器來完成Flow的管理。

在VPC 2.0中，我們通過Packet-In和Push相結(jié)合的方式來下發(fā)Flow規(guī)則。主動推送路由表、ACL相關(guān)的Flow，而點到點轉(zhuǎn)發(fā)的Flow則依賴Packet-In機(jī)制上送到控制器完成Flow的下發(fā)。

此外，我們基于DPDK技術(shù)開發(fā)了諸多東西向和南北向網(wǎng)關(guān)，比如負(fù)載均衡網(wǎng)關(guān)、混合云網(wǎng)關(guān)、裸金屬物理云網(wǎng)關(guān)等，這些網(wǎng)關(guān)會和VPC進(jìn)行直接交互來完成流量的轉(zhuǎn)發(fā)，實現(xiàn)VPC到異構(gòu)網(wǎng)絡(luò)訪問。

在VPC 2.0的長期運(yùn)營中，我們也發(fā)現(xiàn)了諸多問題：

• Packet-In機(jī)制導(dǎo)致首包時延：新建通信必須經(jīng)過控制器計算才能完成Flow下發(fā)，導(dǎo)致首包存在轉(zhuǎn)發(fā)時延，影響客戶體驗。而隨著K8S、Serverless類的容器應(yīng)用興起，這部分時延對業(yè)務(wù)的影響會更大；
• 轉(zhuǎn)發(fā)面和控制面流量耦合：正是因為Packet-In機(jī)制導(dǎo)致轉(zhuǎn)發(fā)面的流量和控制面流量互相耦合，從而導(dǎo)致網(wǎng)絡(luò)中的諸多DDoS攻擊、內(nèi)網(wǎng)掃描流量會穿透到控制面，從而對控制面造成巨大壓力，影響服務(wù)穩(wěn)定性；
• 異構(gòu)網(wǎng)絡(luò)耦合：在VPC 2.0架構(gòu)中VPC需要和各個異構(gòu)網(wǎng)絡(luò)直接通信，因此各網(wǎng)關(guān)都需要感知VPC的路由細(xì)節(jié)，從而導(dǎo)致VPC控制面邏輯分散，網(wǎng)絡(luò)邊界變大，上線新特性往往牽一發(fā)而動全身，導(dǎo)致迭代周期變長；
• OVS轉(zhuǎn)發(fā)性能不足：ovs轉(zhuǎn)發(fā)依賴linux內(nèi)核，而linux內(nèi)核并非為網(wǎng)絡(luò)轉(zhuǎn)發(fā)所設(shè)計，存在較多的鎖和隊列，導(dǎo)致轉(zhuǎn)發(fā)性能不足。

VPC 3.0架構(gòu)：軟硬件一體化的新一代VPC網(wǎng)絡(luò)

為了解決VPC 2.0下的這些問題，我們做了很多虛擬網(wǎng)絡(luò)技術(shù)方面的探索和改進(jìn)，最終形成了軟硬件一體化的VPC 3.0架構(gòu)。

在VPC 3.0架構(gòu)中，最大的特點就是軟硬件協(xié)同，轉(zhuǎn)發(fā)面引入了非常多的轉(zhuǎn)發(fā)網(wǎng)元，包括內(nèi)核版ovs、硬件卸載版ovs、智能網(wǎng)卡、P4和DPDK等，因此如何適配諸多轉(zhuǎn)發(fā)面網(wǎng)元并保持良好的擴(kuò)展性是控制面需要考慮的重要問題。

網(wǎng)元適配

在VPC 3.0控制平面中，我們引入了模型層(Model Layer)、中臺層(Middle Layer)、映射層(Mapping Layer)和推送層(DataPath Layer)等概念和服務(wù)。在適配網(wǎng)元時，統(tǒng)一的業(yè)務(wù)對象（如Subnet）會在模型層生成，并在中臺層被路由給映射層，在映射層完成業(yè)務(wù)對象到不同網(wǎng)元對象的映射，如OpenFlow對象、P4對象、TC對象。

而后網(wǎng)元對象會再次經(jīng)過中臺層路由給推送層。推送層則關(guān)心具體的轉(zhuǎn)發(fā)網(wǎng)元，實現(xiàn)高效、高性能的轉(zhuǎn)發(fā)對象推送。

動態(tài)學(xué)習(xí)

為了解決VPC 2.0架構(gòu)中的Packet-In問題，我們引入了主動推送和動態(tài)學(xué)習(xí)相結(jié)合的Flow下發(fā)方式，以完成Flow的高效下發(fā)。我們基于P4和可編程芯片開發(fā)了VPC網(wǎng)關(guān)BGW，BGW會和位于計算節(jié)點的Datapath Controller運(yùn)行DCP(Datapath Control Protocol)協(xié)議來完成流表的學(xué)習(xí)和流量的offload。

具體實現(xiàn)原理是：當(dāng)ovs既有規(guī)則無法滿足轉(zhuǎn)發(fā)時，通過默認(rèn)Flow轉(zhuǎn)發(fā)給BGW，而BGW除了正確將流量轉(zhuǎn)發(fā)至目的地之外，也會按照DCP協(xié)議構(gòu)造一個UDP報文發(fā)送給源端Datapath Controller，而Controller也會根據(jù)該報文學(xué)習(xí)到下發(fā)Flow所需的關(guān)鍵信息，因此實現(xiàn)Flow的動態(tài)學(xué)習(xí)和流量從BGW向ovs的offload。

相比于VPC 2.0的Packet-In機(jī)制，動態(tài)學(xué)習(xí)帶來了以下好處：

• 流表學(xué)習(xí)發(fā)生在轉(zhuǎn)發(fā)面，性能遠(yuǎn)高于控制面下發(fā)；
• 流表學(xué)習(xí)期間流量仍可由BGW正常轉(zhuǎn)發(fā)，不影響業(yè)務(wù)，無首包時延；
• 相比于全量推送，流表按需學(xué)習(xí)可以極大降低推送Flow的數(shù)量，提升推送的性能。

控制面中臺

此外我們構(gòu)建了控制平面的中臺能力，通過中臺層實現(xiàn)了諸多通用能力，包括對象路由、一致性緩存、對象分片、對象灰度等，使得在開發(fā)不同產(chǎn)品、適配不同轉(zhuǎn)發(fā)面時都可以快速復(fù)用這些已經(jīng)定義良好、實現(xiàn)良好的通用能力，以此提高控制面的可靠性和性能。

硬件卸載

在轉(zhuǎn)發(fā)面演進(jìn)中，我們也從軟件逐步過渡到硬件。從早期的kernel bridge和kernel ovs轉(zhuǎn)發(fā)，逐步切換到目前的硬件卸載ovs、智能網(wǎng)卡等硬件網(wǎng)元來加速轉(zhuǎn)發(fā)性能。在快杰云主機(jī)中，通過卸載ovs，將網(wǎng)絡(luò)轉(zhuǎn)發(fā)能力提升到25G帶寬、1000w pps和10G外網(wǎng)帶寬。

同時，網(wǎng)關(guān)也逐漸從DPDK技術(shù)演進(jìn)到目前基于P4的可編程芯片。在P4實踐中，我們開發(fā)并上線了VPC網(wǎng)關(guān)BGW和負(fù)載均衡網(wǎng)關(guān)CGW。VPC網(wǎng)關(guān)主要支持VPC內(nèi)的二三層流量轉(zhuǎn)發(fā)和ARP代答，并支持Flow Offload。而負(fù)載均衡網(wǎng)關(guān)則支持無縫替換傳統(tǒng)交換機(jī)ECMP實現(xiàn)網(wǎng)關(guān)集群，支持一致性hash（Maglev Hashing），并支持根據(jù)任意字段（vni，內(nèi)存ip和端口）來計算哈希，支持ipv4/ipv6 overlay協(xié)議。對于CGW的使用場景之一就是實現(xiàn)網(wǎng)關(guān)集群的sharding和灰度。

異構(gòu)網(wǎng)絡(luò)

在VPC 3.0架構(gòu)中，我們通過引入UXR這樣的中心化網(wǎng)關(guān)來完成異構(gòu)網(wǎng)絡(luò)的解耦，使得異構(gòu)網(wǎng)絡(luò)在和VPC通信時可以彼此解耦，無需關(guān)心VPC的網(wǎng)絡(luò)細(xì)節(jié)，從而縮小網(wǎng)絡(luò)邊界，使得網(wǎng)絡(luò)更內(nèi)聚。

此外，我們也引入了VPC網(wǎng)關(guān)來實現(xiàn)VPC內(nèi)的流量轉(zhuǎn)發(fā)和流表的動態(tài)學(xué)習(xí)。

同時，裸金屬物理云產(chǎn)品也向智能網(wǎng)卡演進(jìn)，我們基于智能網(wǎng)卡實現(xiàn)了kernel ovs的卸載和NVGRE隧道的卸載，并通過bonding技術(shù)提升網(wǎng)絡(luò)帶寬至40G。

服務(wù)架構(gòu)：微服務(wù)化

在服務(wù)架構(gòu)中，我們也從單體架構(gòu)逐步演進(jìn)到微服務(wù)架構(gòu)。

在單體架構(gòu)中，我們是基于自有框架和TCP、ProtoBuf實現(xiàn)的分布式系統(tǒng)，在長期維護(hù)過程中也出現(xiàn)諸多問題：

• 邏輯復(fù)雜：隨著產(chǎn)品規(guī)模的增加和迭代，導(dǎo)致應(yīng)用邏輯變得越來越復(fù)雜，單體應(yīng)用變得“大而全”，迭代周期變長，靈活性變差；
• 擴(kuò)縮容能力差：同時服務(wù)的部署和管理較為傳統(tǒng)，擴(kuò)縮容能力較差；
• 流程管理復(fù)雜：由于RPC調(diào)用是基于TCP和Protobuf，因此流量管理成本較高。為了實現(xiàn)灰度我們開發(fā)了內(nèi)部灰度網(wǎng)關(guān)，為了支持業(yè)務(wù)重試、限流等邏輯也需要在代碼內(nèi)部實現(xiàn)。

因此，我們按照服務(wù)邊界進(jìn)行了拆分，將單體應(yīng)用拆分成微服務(wù)，并引入了Istio、Kubernetes、gRPC等框架和組件。

在微服務(wù)架構(gòu)中，我們?nèi)〉昧巳缦聝?yōu)點：

• 服務(wù)內(nèi)聚，迭代速度快：在拆分的過程中，單個微服務(wù)邏輯足夠內(nèi)聚，足夠簡單，從而使得服務(wù)迭代速度更快，更易于灰度；
• 彈性伸縮能力強(qiáng)：通過借助kubernetes可以實現(xiàn)良好的彈性伸縮和部署能力；
• 精細(xì)化灰度能力：通過借助Istio，我們可以實現(xiàn)精細(xì)化的灰度能力，包括基于流量比例、客戶、客戶級別、VPC、甚至是VM級別的請求灰度；
• 基于Isito的流量管理：通過Istio我們在sidecar節(jié)點實現(xiàn)了對流量的管理，包括重試、限流、熔斷等等。

在微服務(wù)化的過程中我們也遇到了很多挑戰(zhàn)，維護(hù)一個大型微服務(wù)系統(tǒng)會給整體服務(wù)帶來更多的復(fù)雜性和不確定性，也更考驗我們的服務(wù)治理能力，因此微服務(wù)化的背后我們也做了很多努力。

Telemetry和故障定位

隨著云計算的發(fā)展，云網(wǎng)絡(luò)的規(guī)模也在不斷擴(kuò)大，為了在日益復(fù)雜的云網(wǎng)絡(luò)環(huán)境中定位網(wǎng)絡(luò)問題，我們往往要回答內(nèi)網(wǎng)流量追蹤的三大痛點：

• 通信是否正常：端到端的通信狀態(tài)是否正常，是否有故障，故障發(fā)生在哪？
• 時延是否正常：端到端的通信時延是否正常？
• 流量走了哪條路徑：如何在諸多ECMP和Hash中確定流量的實際路徑？

為了解決以上問題，我們設(shè)計和開發(fā)了UCloud的全鏈路的高性能探測系統(tǒng)。

該系統(tǒng)的最大的特點是對網(wǎng)元的要求非常小，只需要overlay/underlay網(wǎng)元支持流量鏡像、ERSPAN即可，而無需可編程能力。通過將INT Packet（特殊染色的TCP報文）在各網(wǎng)元的出入向鏡像給Telemetry Cluster，我們可以構(gòu)建出端到端的報文bitmap，并據(jù)此分析出通信結(jié)果（通信是否正常、是否丟包、丟在了哪里）、端到端的近似時延、以及端到端的實際通信鏈路。

此外，配合我們的活躍流分析系統(tǒng)，可以實現(xiàn)VPC內(nèi)的活躍流快速探測。在變更時我們可以通過這樣的機(jī)制快速驗證變更前后的活躍流通信狀態(tài)、通信鏈路是否發(fā)生異常，從而快速、可靠的發(fā)現(xiàn)潛在問題。

總結(jié)

在最新的VPC3.0架構(gòu)下，UCloud VPC支持高性能網(wǎng)絡(luò)轉(zhuǎn)發(fā)（內(nèi)網(wǎng)包量最高可達(dá)1000萬PPS，單個EIP支持最大10Gb外網(wǎng)帶寬），除IPv4外，UCloud VPC也提供了對IPv6的原生支持，幫助客戶快速構(gòu)建IPv6 VPC網(wǎng)絡(luò)。同時，通過ACL和安全組的支持，用戶可以實現(xiàn)對VPC內(nèi)資源細(xì)粒度的安全訪問控制。

未來，UCloud VPC團(tuán)隊將密切關(guān)注網(wǎng)絡(luò)相關(guān)的軟硬件發(fā)展，并消化吸收符合自身需求的新技術(shù)，持續(xù)為用戶打造安全、穩(wěn)定、高性能的VPC云服務(wù)。