在OpenStack世界中，網絡組件最初叫nova-network，它混跡於計算節點nova的代碼庫中。nova-network可以單獨部署在一臺機器上，爲了高性能HA也可以和nova-compute一樣部署在計算節點上（這也就是所謂的multi-host功能）。nova-network實現簡單，bug少，但性能可不弱哦，直接採用基於Linux內核的Linux網橋少了很多層抽象應該算強大的。不足之處是支持的插件少（只支持Linux網橋），支持的網絡拓撲少（只支持flat, vlan)。
爲了支持更多的插件，支持更多的網絡拓撲，更靈活的與nova交互，於是有了quantum工程。quantum插件不僅支持Linux網橋，也支持OpenvSwitch，一些SDN的插件以及其他商業公司的插件。在網絡拓撲上，除了支持flat，vlan外，還支持gre, vxlan。但quantum不支持關鍵的multi-host特性。
quantum因爲和一家公司的名稱衝突，於是，改名爲neutron。
neutron繼續演進，quantum之前的實現存在這麼一個問題。我們說道說道。在quantum中，實現一種類型的插件一般包括兩個部分，一部分與數據庫db打交道稱之爲plugin，一部分是調用具體的網絡設備真正幹活的稱之爲agent。像plugin就有linux bridge plugin, opevswitch plugin, hyper-v plugin等，這些plugin因爲都是與db打交道，變化的字段並不多，所以代碼絕大部分是重複的。這樣也就出來了一個公共的plugin叫ml2 plugin(具體的代碼實現就是TypeDriver)。
但這只是一個表象，ml2還有更大的作用，那就是它裏面的MechanismDriver。我舉個例子講，之前沒有ml2的時候，plugin只能支持一種，用了linux bridge，就不能用openvswitch了，想要都用那怎麼辦，那就需要MechanismDriver上場，MechanismDriver的作用是將agent的類型agent_type和vif_type關聯，這樣vif_type就可以直接通過擴展api靈活設置了，所以這時候你想用linux bridge你在vif_type裏直接將port綁定成linux bridge就行了，同理，想用openvswitch就將vif_type將port綁定成openvswitch就行。
除了讓openvswitch, linux bridge這些不同的插件共存之外，ml2還能讓不同的拓撲如flat, vlan, gre, vxlan其樂融融和諧共存，直接在ml2_conf.ini這個配置文件裏都配上即可。這樣也就解決了一個問題，以前前端horizon中無法配置是用flat還是vlan，因爲你配了也沒有用，那時候後端還不支持flat和vlan同時存在了，現在皆大歡喜了。
上面的ml2解決的只是網絡中L2層的問題，對於L3層的路由功能neturon又單獨整出個l3-agent，對於dhcp功能又單獨整出個dhcp-agent，不過它們歸根結底仍屬於實際真正幹功能活的，對於和數據庫db打交道的那部分則是通過提供擴展api來實現的。那麼現在我們想加更多的網絡服務該怎麼辦呢，如L4-L7層的FwaaS, VPNaaS, DNATaaS, DNSaaS，所以現在neutron又出來一個新的服務框架用於將所有這些除L2層以外的網絡服務類似於上述ml2的思想在數據庫這塊一網打盡。並且這些網絡服務可能是有序的，例如可能需要先過FwaaS防火牆服務再過DNATaaS服務來提供浮動IP，所以也就有了service chain的概念。目前這塊代碼只進去了firewall, loadbalance, metering, vpn幾塊，但萬變不離其宗，未來neutron就是朝這個思想繼續往下做。想用哪些服務可以通過neutron.conf這個配置文件中的service_provider項指定。
最後，需要一提的是，從性能角度講，我認爲目前neutron仍然不能用於大規模的生產環境，理由如下：
1)雖然增加了更多的插件，更多的網絡服務，更多的網絡拓撲，但它仍然不支持multi-host功能，對性能是極大影響
2)neutron-server不支持workers通過fork實現的利用cpu多核的多進程機制，仍然是單線程實現的，阻塞的話(python解釋器是單進程的，使用greenlet保證每個線程在單進程下也是線性的），會延緩接受其他請求對性能產生影響。
3)neutron-server是無狀態的服務，理論上講是可以在多臺機器上運行前端再加haproxy實現HA的，但實際代碼中存在衆多競爭條件的bug。當然這個問題不僅在neturon有，其他組件我看一樣存在。
4)在遂道性能方面存在優化的可能，遂道如GRE,VXLAN等將虛擬L2層打通反而擴大了廣播風暴的可能，實際上虛擬網橋或者hypervisor都是知道虛機的IP和MAC地址的映射的關係的，根本不需要仍使用傳統的ARP廣播方式來獲得這種映射關係。
5)其他…
成熟的路上漫漫其修遠兮，這也正好給各位愛好openstack的童鞋們提供了大顯身手的好機會：）
文章來源：原創
文章作者：Joshua, OpenStack中國社區