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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

為了解決VPC 2.0下的這些問題，我們做了很多虛擬網(wǎng)絡技術方面的探索和改進，最終形成了軟硬件一體化的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)元并保持良好的擴展性是控制面需要考慮的重要問題。

網(wǎng)元適配

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

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

動態(tài)學習

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

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

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

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

控制面中臺

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

硬件卸載

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

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

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

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

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

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

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

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

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

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

因此，我們按照服務邊界進行了拆分，將單體應用拆分成微服務，并引入了Istio、Kubernetes、gRPC等框架和組件。

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

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

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

Telemetry和故障定位

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

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

為了解決以上問題，我們設計和開發(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)的活躍流快速探測。在變更時我們可以通過這樣的機制快速驗證變更前后的活躍流通信狀態(tài)、通信鏈路是否發(fā)生異常，從而快速、可靠的發(fā)現(xiàn)潛在問題。

總結(jié)

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

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