博主這個關于SDN&NFV的博客已經寫了有一年了，竟然一直在寫SDN，從來沒有寫過NFV。今天博主終于打算開始寫第一篇關于NFV的文章，主要是因為博主覺著NFV已經箭在弦上，離落地不遠了。關于NFV的文章有很多，但國內外都是軟文居多，看了也不知道在說什么，主要是因為實在沒有什么干貨可寫，于是就只能堆砌概念了。在博主看來，讓NFV落地的種種條件直到最近這半年才基本成熟。估計再過半年或者一年市場上就會出現(xiàn)比較靠譜的NFV解決方案，等明年這個時候可能就會有比較有說服力的案例出現(xiàn)了。

博主就不花筆墨科普NFV了，目前為止博主見到的最好的解釋NFV以及NFV和SDN關系的文章是sigcomm 2014的OpenNF，特別是它的前兩章，博主建議做SDN和NFV的兄弟們都讀一下。 這篇文章的結論之一是沒有SDN，NFV是玩兒不轉的。但這僅僅是故事的一部分，博主今天會把我眼中那些決定NFV落地的關鍵因素搭個框架出來，細節(jié)會在之后的文章陸續(xù)展開。

需求：

NFV (Network Function Virtualization，網絡功能虛擬化)，如果非要用一句話解釋就是：把在傳統(tǒng)網絡中只在專門硬件上跑著的功能放到虛擬機里跑，比較典型的例子是把防火墻跑在虛擬機上。這樣做有很多好處：省錢；升級虛擬機比升級硬件方便；根據業(yè)務需求彈性部署；易于管理等等?？傊切┲鳈C虛擬化的好處對于NFV同樣適用。對NFV最大的需求來自兩類大金主：運營商和云。

運營商會在網絡中部署各種各樣的middlebox (Network Function的又一種說法，真不明白人們?yōu)槭裁椿ň幵觳煌拿~來描述同一個東西...)，middlebox種類之繁雜讓博主一度目瞪口呆，sigcomm 2012的APLOMB說運營商管理的middlebox的數量比他們管理的路由器加交換機的總和還多。面對如此龐雜的middlebox，運營商對于NFV的需求也最為旺盛。

對于NFV的另外一個需求大戶是云，特別是在多租戶大行其道的今天。每一個租戶都要在自己的網絡入口部署防火墻和負載均衡。云服務提供商不可能為每一個租戶購買專門的硬件設備來完成這些功能。把這些功能跑在虛擬機里幾乎是唯一的選擇。

對NFV的需求如此強烈，為什么遲遲沒有落地呢？因為一些關鍵的技術問題直到最近才有比較靠譜的解決方案。

技術：

NFV最大的技術難題是性能。還是拿防火墻來舉例：防火墻是有狀態(tài)的，它要追蹤每一個TCP鏈接并且根據規(guī)則做出判斷。人們?yōu)榉阑饓υO計專門的芯片就是為了能夠線速處理網絡流量。于是從2000左右開始，硬件防火墻就一直統(tǒng)治著市場。如果把所有這些功能都放到虛擬機，放到軟件上來做，就意味著中斷，數據拷貝，要達到線速非常困難。伴隨著基于DPDK，SR-IOV的一系列方案的不斷完善，這個問題得到了比較好的解決。解決思路就是用最少的中斷，尋址和數據拷貝將數據包搬運于網卡和防火墻虛擬機之間。博主會寫專門的文章比較這兩個技術流派，目前更傾向于認為DPDK會得到更廣泛的應用(事實上在大型互聯(lián)網企業(yè)里，基于的DPDK的應用已經走得很遠了)。以SR-IOV為代表的網卡技術有兩個硬傷博主還沒想清楚怎么破：1) 沒有HA，一個網卡掛了，它所有的virtual function全掛。SR-IOV沒有bond的概念。2) 產品升級困難，唯一的方法就是換網卡，重新部署，重新配置。

NFV面臨的第二個難題是根據middlebox的功能和在網絡中的位置，高度動態(tài)的計算路徑，將流量正確的轉發(fā)入/出middlebox。這個問題伴隨著SDN的落地開花，不少SDN廠家都有了比較靠譜的解決方案。

部署：

直到上面的兩個技術問題得到解決，談NFV的部署才有意義。NFV的部署其實和虛擬機的編排沒有太本質的區(qū)別。最大的不同是需要為middlebox分配專屬的硬件資源，比如一個防火墻的CPU都應該處于一個NUMA上。這些接口在過去半年里也終于被openstack支持了。

講到這里，大家也就明白為什么博主會認為NFV離落地不遠了：需求旺盛，技術難題已經得到了比較好的解決，部署方式和現(xiàn)有的編排系統(tǒng)高度相似。NFV真的要來了。