【51CTO.com原創(chuàng)稿件】當(dāng)今，幾乎所有的IT基礎(chǔ)架構(gòu)都在朝云的方向發(fā)展。在基礎(chǔ)架構(gòu)中，服務(wù)器和存儲(chǔ)虛擬化已經(jīng)發(fā)展的比較成熟，作為基礎(chǔ)架構(gòu)中的虛擬網(wǎng)絡(luò)，為了迎合云計(jì)算和互聯(lián)網(wǎng)發(fā)展的需求，迎來了新的挑戰(zhàn)，UCloud虛擬網(wǎng)絡(luò)平臺(tái)負(fù)責(zé)人徐亮對此進(jìn)行了梳理。

徐亮，UCloud虛擬網(wǎng)絡(luò)平臺(tái)負(fù)責(zé)人，公司首位5級(jí)技術(shù)專家。先后任職于上海貝爾、騰訊，有超過18年電信與互聯(lián)網(wǎng)行業(yè)研發(fā)管理經(jīng)驗(yàn)。加入U(xiǎn)Cloud后主要負(fù)責(zé)云平臺(tái)網(wǎng)絡(luò)架構(gòu)，包括UXR網(wǎng)絡(luò)解耦、網(wǎng)絡(luò)產(chǎn)品架構(gòu)升級(jí)、虛擬網(wǎng)絡(luò)架構(gòu)升級(jí)等。

[[245837]]

網(wǎng)絡(luò)虛擬化與SDN

網(wǎng)絡(luò)虛擬化是一個(gè)歷史比較悠久的概念，普遍認(rèn)為最初的網(wǎng)絡(luò)虛擬化是起源于VLAN。網(wǎng)絡(luò)虛擬化讓一個(gè)物理網(wǎng)絡(luò)能夠支持多個(gè)邏輯網(wǎng)絡(luò)。虛擬化保留了網(wǎng)絡(luò)

設(shè)計(jì)中原有的層次結(jié)構(gòu)、數(shù)據(jù)通道和所能提供的服務(wù)，使得最終用戶的體驗(yàn)和獨(dú)享物理網(wǎng)絡(luò)一樣。因此帶來了三大優(yōu)勢：幫助更好的利用網(wǎng)絡(luò)資源，平攤被過度使用的資源上的通信量;無需部署專用物理架構(gòu)就可以實(shí)現(xiàn)一些隔離操作， 提高網(wǎng)絡(luò)安全性;合并端口，以提高網(wǎng)絡(luò)的利用率和性能。

SDN(Software-defined Networking)是將網(wǎng)絡(luò)設(shè)備的控制平面(control plane)從數(shù)據(jù)平面(data plane)中分離，改用軟件的方式實(shí)現(xiàn)，即軟件定義網(wǎng)絡(luò)。SDN可使網(wǎng)絡(luò)管理員在不變更硬件設(shè)備的前提下，以中央控制的方式用程序重新規(guī)劃網(wǎng)絡(luò)，為控制網(wǎng)絡(luò)流量提供了新方案，也為核心網(wǎng)絡(luò)和應(yīng)用創(chuàng)新提供了良好平臺(tái)，成為網(wǎng)絡(luò)虛擬化發(fā)展的有力推動(dòng)者。

云計(jì)算給網(wǎng)絡(luò)虛擬化帶來新挑戰(zhàn)

首先，云計(jì)算，特別是公有云，需要網(wǎng)絡(luò)虛擬化提供多租戶和VPC的能力。VPC(Virtual Private Cloud)允許不同租戶甚至同一租戶的網(wǎng)絡(luò)地址重疊，廣播域獨(dú)立，必然導(dǎo)致對網(wǎng)絡(luò)虛擬化的需求。最早的網(wǎng)絡(luò)虛擬化是VLAN協(xié)議，但VLAN協(xié)議中的VID只有12個(gè)bit，僅支持4094個(gè)虛擬網(wǎng)絡(luò)，在公有云的環(huán)境下是遠(yuǎn)遠(yuǎn)不夠的。這就促使公有云廠商紛紛引入Overlay技術(shù)解決這一問題。從早期的NVGRE到現(xiàn)在比較主流的VxLAN，和比較新的GENEVE，都支持24 bits(16M)的租戶ID，滿足了公有云的需求。

其次，云計(jì)算需要SDN幫助提供靈活、彈性的控制面。傳統(tǒng)網(wǎng)絡(luò)中大多使用硬件設(shè)備，如果新增了一個(gè)租戶，去配置硬件設(shè)備是一件比較困難的事情，因?yàn)槊考遗渲枚际遣煌?。但是如果用?jì)算的方式，通過軟件可以在不觸及物理網(wǎng)絡(luò)設(shè)備的情況下，動(dòng)態(tài)的去修改網(wǎng)絡(luò)配置，從而使網(wǎng)絡(luò)虛擬化能夠像計(jì)算一樣輕松、快速、動(dòng)態(tài)。

舉個(gè)例子來說明：當(dāng)租戶VPC-100下的一臺(tái)VM10.10.12.34要訪問同子網(wǎng)下的另一個(gè)IP 10.10.56.78時(shí)，首先需要通過ARP協(xié)議去獲得10.10.56.78的MAC地址。當(dāng)這個(gè)ARP請求報(bào)文到達(dá)宿主機(jī)的vSwitch上時(shí)，由于VPC的存在IP地址可能被不同租戶復(fù)用，所以首先必須要識(shí)別出該ARP請求來自VPC-100，才能識(shí)別出這個(gè)ARP報(bào)文請求的是VPC-100下的IP 10.10.56.78. 由于Overlay網(wǎng)絡(luò)不支持廣播，所以需要知道該子網(wǎng)下所有VM所在的宿主機(jī)在哪里，才能夠把這個(gè)ARP請求加上Overlay封裝送到目的宿主機(jī)上。當(dāng)然如果vSwitch了解VPC-100的10.10.56.78的MAC是52:54:12:34:56:78，也可以采用ARP代答技術(shù)，直接返回ARP響應(yīng)。所有的這一切都不是依賴網(wǎng)絡(luò)設(shè)備自動(dòng)完成，而是通過SDN用軟件控制實(shí)現(xiàn)的。

除此之外，Overlay給物理網(wǎng)絡(luò)也帶來了非常大的復(fù)雜度，硬件的支持非常慢。徐亮在此舉例為據(jù)：最流行的萬兆網(wǎng)卡芯片Intel 82599不支持任何Overlay協(xié)議的卸載，直到今年Mellanox的網(wǎng)卡才開始逐步支持VxLAN的TSO卸載。而交換機(jī)芯片用了5年的時(shí)間才支持VxLAN協(xié)議，其他Overlay協(xié)議仍然沒有交換機(jī)芯片支持，導(dǎo)致Overlay網(wǎng)絡(luò)的性能長期低于物理網(wǎng)絡(luò)。

UCloud虛擬網(wǎng)絡(luò)發(fā)展歷程

在2012年UCloud成立之初，虛擬網(wǎng)絡(luò)就是IaaS的一個(gè)核心組件，當(dāng)時(shí)采用EBTables和IPTables的組合來實(shí)現(xiàn)租戶隔離。但是UCloud的團(tuán)隊(duì)很快發(fā)現(xiàn)這個(gè)技術(shù)方案不足以向客戶提供安全、穩(wěn)定的服務(wù)。

于是從2013年開始，UCloud的虛擬網(wǎng)絡(luò)開始采用SDN技術(shù)實(shí)現(xiàn)租戶隔離，也就是VPC(Virtual Private Cloud)。同年年底，UCloud意識(shí)到客戶在使用云主機(jī)的同時(shí)也有使用物理機(jī)(bare metal)的需求，所以率先采用盛科的SDN交換機(jī)，推出了和公有云網(wǎng)絡(luò)互通物理云主機(jī)產(chǎn)品。

2015年，隨著客戶業(yè)務(wù)的快速發(fā)展，硬件SDN交換機(jī)OpenFlow流表有限的條目已經(jīng)不足以支撐物理云主機(jī)的需求。UCloud迅速開發(fā)了采用DPDK技術(shù)的服務(wù)器集群來替代硬件SDN交換機(jī)。隨后更多的DPDK網(wǎng)關(guān)作為OVS的補(bǔ)充出現(xiàn)在UCloud的虛擬網(wǎng)絡(luò)中，為客戶提供更快速的虛擬網(wǎng)絡(luò)。

從2017年開始，隨著25G網(wǎng)絡(luò)的發(fā)展，UCloud開始研發(fā)基于硬件卸載的虛擬網(wǎng)絡(luò)方案。最后確認(rèn)下來的方向是可編程交換機(jī)和智能網(wǎng)卡兩者同時(shí)推進(jìn)。

在控制面流表管理方面主要有兩種方案，被動(dòng)觸發(fā)方式和主動(dòng)推送方式。被動(dòng)觸發(fā)方式是傳統(tǒng)的OpenFlow流表管理方式，在收到報(bào)文時(shí)首先檢查是否本地有流表命中，如果沒有，則通過OpenFlow Packet-in消息發(fā)送給Controller處理，Controller下發(fā)新的流表處理此類型報(bào)文。主動(dòng)推送方式則是在網(wǎng)絡(luò)拓?fù)浒l(fā)生變化的時(shí)候主動(dòng)將變化的流表推送到轉(zhuǎn)發(fā)面。

早期，UCloud以被動(dòng)觸發(fā)方式為主。其優(yōu)勢在于實(shí)現(xiàn)簡單，但缺點(diǎn)是首包會(huì)有延遲，且控制面受用戶行為影響大，可能會(huì)有很多突發(fā)情況。針對首包延遲問題，UCloud采用主動(dòng)模擬用戶對外發(fā)送報(bào)文的方式觸發(fā)流表下發(fā)，達(dá)到類似主動(dòng)推送的效果。針對控制面突發(fā)較多的問題，采用本地Controller先對Packet-in消息進(jìn)行去重、限流后再發(fā)給遠(yuǎn)程Controller的方式進(jìn)行規(guī)避。

在大量引入DPDK網(wǎng)關(guān)后，UCloud也在使用主動(dòng)推送方式。其優(yōu)勢在于有效消除首包延遲，且控制面壓力更可控，不影響轉(zhuǎn)發(fā)面。但主動(dòng)推送方式存在的問題是，如果虛擬網(wǎng)絡(luò)規(guī)模很大的時(shí)候，推送的范圍就會(huì)很大，可能會(huì)造成推送時(shí)間過長而導(dǎo)致網(wǎng)絡(luò)變化無法實(shí)時(shí)生效。

針對以上問題，目前UCloud也在探索兩者結(jié)合的一些新方法。

UCloud虛擬網(wǎng)絡(luò)的挑戰(zhàn)及解決方案

虛擬網(wǎng)絡(luò)領(lǐng)域經(jīng)過近10年的演進(jìn)仍然處于一個(gè)快速發(fā)展變化、百家爭鳴的階段，同時(shí)也給UCloud虛擬網(wǎng)絡(luò)團(tuán)隊(duì)帶來了很多挑戰(zhàn)。

轉(zhuǎn)發(fā)面的挑戰(zhàn)與解決方案

一、網(wǎng)卡性能大幅從1G提升到10G、25G、100G帶來的性能挑戰(zhàn)

網(wǎng)絡(luò)性能的提升速度，已經(jīng)超過了CPU性能提升的速度，這是一大挑戰(zhàn)。UCloud目前主要采用硬件卸載的方式來解決，包括可編程交換機(jī)和智能網(wǎng)卡。

可編程P4交換機(jī)方案

2017年第四季度，UCloud開始預(yù)研Barefoot的支持P4的可編程交換機(jī)(Tofino芯片)，發(fā)現(xiàn)P4 and Barefoot Tofino能夠很好地滿足需求。P4 and Barefoot Tofino的優(yōu)點(diǎn)主要有：

1、 與DPDK相比，有更高的轉(zhuǎn)發(fā)性能。DPDK基本上用網(wǎng)卡的方式，單機(jī)10G或者25G的性能。對于可編程交換機(jī)來說，起步就是1.8T到6.5T的性能，相對于DPDK在性能上是幾十倍甚至接近一百倍的提升。而且交換機(jī)的時(shí)延更低，它的單根網(wǎng)線支持100G，基本上可以避免單線被擁塞的效果。

2、 交換機(jī)的轉(zhuǎn)發(fā)性能是很穩(wěn)定的，并且是可以預(yù)期的，而DPDK的轉(zhuǎn)發(fā)性能隨業(yè)務(wù)模型可能會(huì)發(fā)生變化。

3、 與其他硬件交換機(jī)相比，可編程P4交換機(jī)更開放。可編程能力強(qiáng)，可以定制轉(zhuǎn)發(fā)面整個(gè)處理包的p4lang。可編程P4交換機(jī)可以完美解決Ethernet Over GRE和Flow Based Tunneling的問題。用P4語言寫程序，比用DPDK的C語言寫程序更簡單，開發(fā)效率更高?？删幊蘌4交換機(jī)基本上采用gRPC的接口進(jìn)行遠(yuǎn)程的管理，操作系統(tǒng)采用 Open Network Linux(基于Debian)，這使交換機(jī)更像一個(gè)傳統(tǒng)的服務(wù)器。另外相對于其他交換機(jī)，可編程P4交換機(jī)有一個(gè)生態(tài)圈，有P4 Runtime、Stratum這樣的開源社區(qū)，更好的促進(jìn)交換機(jī)的發(fā)展。

目前UCloud采用P4可編程交換機(jī)完成了一個(gè)新增的核心Gateway的開發(fā)和測試工作，已經(jīng)開始部署和灰度上線。

智能網(wǎng)卡方案

同期，在計(jì)算節(jié)點(diǎn)上，UCloud也在探索如何解決25G網(wǎng)絡(luò)帶來的性能挑戰(zhàn)。

在VMware主宰虛擬化的早期階段，通過VLAN實(shí)現(xiàn)租戶隔離，通過SRIOV的方式將硬件網(wǎng)卡虛擬化成多張?zhí)摂M網(wǎng)卡供虛擬機(jī)使用，是非常成熟而高效的解決方案。采用SRIOV的方式，虛擬機(jī)可以獲得物理網(wǎng)卡95%以上的PPS性能。但12位的VLAN只能支持最大4094個(gè)租戶，并不能滿足公有云的需求，而二層的組網(wǎng)方式也不適合公有云的大規(guī)模數(shù)據(jù)中心。幾乎所有的公有云都是采用的Overlay的解決方案。而Overlay的方案相對VLAN要復(fù)雜很多，大多數(shù)新一代非智能網(wǎng)卡的ASIC芯片目前僅可以完成VXLAN的封裝和解封裝工作，但虛擬機(jī)所在的宿主機(jī)地址信息需要控制面提供，使得SRIOV技術(shù)在Overlay的網(wǎng)絡(luò)里完全無用武之地。

基于DPDK的vSwitch方案對比基于Linux Kernel的vSwitch，在報(bào)文轉(zhuǎn)發(fā)性能上提升了幾倍。通過DPDK的Vhost Library，VM的網(wǎng)絡(luò)報(bào)文可以通過Virtio虛擬網(wǎng)卡，以Zero Copy的方式到達(dá)宿主機(jī)上的vSwitch進(jìn)行處理。宿主機(jī)上的vSwitch根據(jù)控制面信息了解目的MAC或者IP所在的宿主機(jī)信息，然后加上Overlay封裝高速轉(zhuǎn)發(fā)。但代價(jià)是絕大多數(shù)網(wǎng)卡只能支持Busy Poll的DPDK工作方式，無論虛擬機(jī)當(dāng)前的PPS是多少，DPDK都會(huì)占用固定的CPU Cores，而這部分計(jì)算資源原本在閑時(shí)是可以出售的。

而智能網(wǎng)卡(SmartNIC)的目標(biāo)就是將網(wǎng)絡(luò)轉(zhuǎn)發(fā)所占用的宿主機(jī)計(jì)算資源釋放出來，從而達(dá)到降低TCO的目標(biāo)。目前智能網(wǎng)卡的實(shí)現(xiàn)百花齊放，例如：AWS采用基于通用ARM的眾核方案、AZure采用基于FPGA的方案、華為云采用基于專用網(wǎng)絡(luò)處理器(NP)的方案、阿里云采用基于可編程ASIC芯片的方案。就目前來看各個(gè)方案各有優(yōu)勢，并沒有特別突出一統(tǒng)天下的方案。

基于通用ARM、MIPS的眾核方案，簡單將原來跑在宿主機(jī)上的vSwitch移植到網(wǎng)卡上，既可以支持Linux Kernel也可以支持DPDK，從而達(dá)到釋放宿主機(jī)計(jì)算資源的目的。其他基于FPGA、NP和可編程ASIC的方案，大多在網(wǎng)卡上維護(hù)一個(gè)快速轉(zhuǎn)發(fā)路徑(FastPath)，當(dāng)收到報(bào)文后，首先檢查是否在FastPath已經(jīng)緩存了該類報(bào)文的處理規(guī)則，如果找到，則直接按照規(guī)則執(zhí)行動(dòng)作，否則就轉(zhuǎn)發(fā)到SlowPath去處理。而這個(gè)SlowPath可以是DPDK，也可以是Linux Kernel。因此，F(xiàn)astPath最重要的是看是否支持足夠多的Action，以及自定義Action的可擴(kuò)展性。SlowPath和FastPath通信除了各廠商的私有接口外，也有標(biāo)準(zhǔn)的TC Offload接口和DPDK提供的RTE Flows接口。

智能網(wǎng)卡幾乎都可以采用SRIOV的方式接入虛擬機(jī)。VF支持的隊(duì)列個(gè)數(shù)也非常重要，只有支持多隊(duì)列的VF，才能夠通過RSS充分發(fā)揮出虛擬機(jī)的多核優(yōu)勢，從而達(dá)到較高的網(wǎng)絡(luò)處理性能。整合FastPath和SRIOV，智能網(wǎng)卡也能夠使虛擬機(jī)的網(wǎng)絡(luò)性能接近物理網(wǎng)卡。

但阻礙SmartNIC采用SRIOV方式的一大原因就是虛擬機(jī)熱遷移(Live-Migration)，SRIOV方式虛擬機(jī)直接管理VF，這導(dǎo)致無法Live-Migration。Live-Migration的問題較傳統(tǒng)的解決方案是通過VF和Virtio Bind的方式來規(guī)避，在正常工作的時(shí)候，使用VF進(jìn)行高性能轉(zhuǎn)發(fā)，在Live-Migration前熱拔出VF網(wǎng)卡無縫切換到Virtio網(wǎng)卡工作，在Live-Migration完成后再熱插入VF網(wǎng)卡。

顯而易見，在Live-Migration過程中使用Virtio網(wǎng)卡會(huì)造成網(wǎng)絡(luò)性能下降，使得Live-Migration需要選擇閑時(shí)進(jìn)行。Intel提出vhost data path acceleration(vDPA)技術(shù)，在VF上兼容Virtio，從而更好地支持Live-Migration。同時(shí)Virtio 1.1規(guī)范的推出使得網(wǎng)卡硬件兼容Virtio更加容易。

目前UCloud基于SRIOV支持熱遷移的高性能25G智能網(wǎng)卡正在內(nèi)測階段，即將上線。

二、有狀態(tài)服務(wù)(如：安全組)引入帶來的性能挑戰(zhàn)

UCloud希望能夠通過智能網(wǎng)卡來卸載有狀態(tài)業(yè)務(wù)，例如：防火墻、NAT和安全組。有狀態(tài)業(yè)務(wù)要求實(shí)現(xiàn)連接追蹤(Connection Track)。新建連接需要在

FastPath插入新規(guī)則，這要求非常高的規(guī)則更新速度。每個(gè)連接都需要在FastPath維護(hù)一條規(guī)則，這對內(nèi)存提出了非常高的要求。連接的狀態(tài)變化需要在FastPath和SlowPath間同步，TCP的狀態(tài)變化時(shí)還需要檢查SEQ。

目前UCloud在測試一些商用的SmartNIC，智能網(wǎng)卡對有狀態(tài)業(yè)務(wù)的支持正在越來越好，有望在不久的將來，能夠提供足夠成熟的有狀態(tài)業(yè)務(wù)解決方案。

控制面的挑戰(zhàn)與輕量級(jí)ServiceMesh方案

虛擬化的優(yōu)勢很明顯：可以提高服務(wù)器、計(jì)算及網(wǎng)絡(luò)容量的使用效率，減少資金投入。但同時(shí)，虛擬化也給負(fù)責(zé)管理虛擬網(wǎng)絡(luò)的數(shù)據(jù)中心人員帶來了新的挑戰(zhàn)。

SDN的控制面需要在每臺(tái)計(jì)算節(jié)點(diǎn)上部署，本質(zhì)上就是一個(gè)超大規(guī)模(x萬節(jié)點(diǎn))的分布式系統(tǒng)。它面臨的問題也和常規(guī)分布式系統(tǒng)一樣，需要解決CAP問題、可擴(kuò)展性問題等等。為了降低變更的影響范圍，UCloud也逐步開始進(jìn)行微服務(wù)改造。同時(shí)更好地實(shí)現(xiàn)按用戶灰度發(fā)布，因此引入了輕量級(jí)ServiceMesh架構(gòu)。

輕量級(jí)ServiceMesh是基于Envoy和Istio Pilot的Istio變種方案。Istio是一個(gè)非常優(yōu)秀ServiceMesh方案， UCloud團(tuán)隊(duì)對Istio的流量管理功能非常滿意，同時(shí)通過評測也能夠接受Envoy的性能開銷。

但是UCloud目前并沒有采用K8S，事實(shí)上，UCloud所開發(fā)的IaaS控制面程序，本身就和K8S的功能類似。并且，UCloud有大量的既有服務(wù)。K8S的網(wǎng)絡(luò)方案比較復(fù)雜，且性能堪憂，再通過IPTables來透明引流確實(shí)是雪上加霜，給未來的運(yùn)維、Trouble-Shooting帶來了很高的復(fù)雜度。目前UCloud主要使用gRPC和HTTP，但仍有數(shù)據(jù)庫服務(wù)等業(yè)務(wù)不適合跑在K8S中，而K8S的網(wǎng)絡(luò)方案需要能夠兼容現(xiàn)有的數(shù)據(jù)庫等業(yè)務(wù)。

經(jīng)過對Istio代碼的預(yù)研之后，UCloud最終選擇了將Pilot從Istio中剝離出來，脫離K8S運(yùn)行的輕量級(jí)ServiceMesh方案。在Istio中Pilot是作為Envoy的控制面提供集中式流量管理功能的模塊，這是實(shí)現(xiàn)灰度發(fā)布必不可少的功能，事實(shí)上也是ServiceMesh的核心功能。Mixer提供的訪問策略和控制，Istio-Auth提供安全認(rèn)證功能，相對來說在UCloud的內(nèi)網(wǎng)環(huán)境下，都可以裁剪掉。

而得益于Pilot的良好設(shè)計(jì)，很容易實(shí)現(xiàn)ETCD Platform，從ETCD獲取Service和Service Instance信息。UCloud重寫了Pilott的main.go，保留了Pilot的model、proxy和proxy/envoy模塊，刪除其他的Platform僅保留新增的ETCD Platform。

最后在保留完整的Istio DSL支持的同時(shí)，得到了完全脫離K8S運(yùn)行和編譯的Pilot。同時(shí)將Pilot和ETCD gRPC naming and discovery做了深度整合，自動(dòng)剔除沒有在線的ServiceEntry。

在脫離K8S后，仍然需要采用Sidecar的部署方式。UCloud采用container的方式打包和部署微服務(wù)，但采用Host的網(wǎng)絡(luò)方式，簡化了和現(xiàn)存服務(wù)的網(wǎng)絡(luò)通信方式。同時(shí)利用docker-compose模擬K8S的POD，管理服務(wù)間的依賴。通過實(shí)現(xiàn)一個(gè)簡單的服務(wù)管理、版本管理、集群管理、路由策略管理層，為集群中的每臺(tái)Node(VM或物理服務(wù)器)生成docker-compose配置文件，實(shí)現(xiàn)每臺(tái)Node的服務(wù)部署和管理。

最后針對HTTP 1.0、HTTP 2.0和gRPC的RPC方式，采用顯式代理而不是IPTables透明引流和Envoy集成。如果服務(wù)中配置了Envoy的Proxy Port，則通過Envoy接入ServiceMesh;如果配置是IP地址和端口，則直連這個(gè)地址;如果配置的是域名且沒有配置Envoy的Proxy則自動(dòng)采用ETCD gRPC naming and discovery的方式去發(fā)現(xiàn)遠(yuǎn)端服務(wù)。

最終，UCloud輕松利用Pilot和Envoy實(shí)現(xiàn)了按用戶灰度發(fā)布，目前該ServiceMesh框架已經(jīng)在UCloud多個(gè)項(xiàng)目中使用。

后記

加入U(xiǎn)Cloud虛擬網(wǎng)絡(luò)團(tuán)隊(duì)三年多，徐亮深刻地認(rèn)識(shí)到這個(gè)領(lǐng)域百家爭鳴，仍然在快速變化中。但 “Software is eating the network” 這個(gè)趨勢始終清晰可見。從最早的SDN、軟件vSwitch到智能網(wǎng)卡、可編程交換機(jī)，軟件在網(wǎng)絡(luò)中的作用越來越重要。

“同時(shí)密切關(guān)注網(wǎng)絡(luò)和軟件兩個(gè)領(lǐng)域的發(fā)展，消化吸收符合自身需求的新技術(shù)，才能夠跟上UCloud用戶的發(fā)展，為客戶提供穩(wěn)定的服務(wù)，提供符合客戶需求的、易用和低成本的產(chǎn)品。”徐亮總結(jié)道。

【51CTO原創(chuàng)稿件，合作站點(diǎn)轉(zhuǎn)載請注明原文作者和出處為51CTO.com】