重要的點從軟件工程角度來講，怎么樣做一個正確、又能夠被人們所理解，而且還能夠被驗證的計算機程序?我們有沒有辦法做到這個事情?軟件危機80年代出現(xiàn)，到現(xiàn)在還沒有完全解決，但是有了更好的方法個工具支持我們的工作。從通信行業(yè)來講我覺得這個問題可能比銀行、政府問題更加嚴重。最主要的，舉幾個現(xiàn)象：

第一，從大的廠商來講，我們現(xiàn)在很多公司有成百萬、千萬的代碼在支持運營、管理、服務。我們不知道大的供應商有多少人愿意花時間重構這些幾百萬行、幾千萬行的代碼?可能不會很多。根本上沒有解決復雜性的問題，比如說網(wǎng)絡里有多少協(xié)議?各個層次以千來計算。從產(chǎn)品上來說，每一個廠家、每一個型號、根據(jù)不同的協(xié)議度支持度產(chǎn)生的產(chǎn)品也是成千上萬，我們要組合一個可靠的可以管理的網(wǎng)絡難度自然存在。所以最后一點就是可管理性。大家都知道，很多情況下網(wǎng)絡已經(jīng)變得越來越不可管理，這就是08年的時候斯坦福和伯克利的教授和兩位學生期望以更簡單的方式描述網(wǎng)絡，在校園里先提供一個實驗的平臺?？纯催@些簡單更加可行的方法能不能變得通用。

剛才說了軟件危機以后從軟件工程這個方面我們經(jīng)歷了好多次的革新，從80年代中后期的面向對象，到90年代初期的面向組件，后來到面向服務。這樣一種越來越更加開放，面向重用這樣一種整體的軟件架構慢慢的為更多人所接受。但是我們覺得還是應該強調(diào)，沒有一個很完善的方法解決所有的問題。所有大型的復雜度比較高的，特別是需求比如說我們的協(xié)議的定義不很完善。比如說Openflow這個協(xié)議本身從1.0、1.1到1.2、1.3里面可圈可點的地方還挺多的。走進去以后會發(fā)現(xiàn)這里面一個小問題一句話理解就要多少人/天。

軟件工程學想干什么呢?是把做工程的辦法推到做軟件的產(chǎn)業(yè)里面去。最重要的是三個方面，一個是我們能不能以系統(tǒng)的辦法?另外有一套嚴格的方法，有一套工具管理需求構建中的一整套方法支持，同時我們能在設計、開發(fā)的過程中能夠測度我們在哪些方面取得了進步?離我們的整體目標到底還有多遠，能夠去測度這樣的一個工程的系統(tǒng)性。有一整套的比較完善的嚴格的過程定義和工具支持，另外能量化，這樣做工程的辦法去實現(xiàn)軟件。

我們從90年代末開始有沒有看到這方面的變更?我覺得是有的。我想強調(diào)的是IBM90年代中后期提出來的RUP，現(xiàn)在叫統(tǒng)一過程大家應該聽說過。它強調(diào)了三個點：第一是以架構為中心。就是我們所設計的軟件必須基于一個已經(jīng)認為可行，而且能夠把軟件的各個層面從底層硬件支持到上面的數(shù)據(jù)管理，到安全、到集成，能夠把一個所有軟件系統(tǒng)的方方面面能夠串起來的架構。在這個基礎上根據(jù)場景、業(yè)務、根據(jù)技術、根據(jù)數(shù)據(jù)的需求提出了各種通用的組件。在組件基礎上進一步的發(fā)展到我們應該需要什么樣的標準服務?這樣的話我們的系統(tǒng)才能夠真正的實現(xiàn)互相能夠互通。

另外一個就是架構師的工作并不是簡單的畫一些框圖，我們是要以一種可以重復工程化的方式來實現(xiàn)我們的架構和設計我們的架構，就是以模式驅動的架構和它的開發(fā)方式。我們必須有這樣的開發(fā)方式以后架構才可以擴展、重用。而且我們可以把我們的設計建立在前人已經(jīng)完成的工作的基礎上。

第二個是要業(yè)務驅動。具體來說用統(tǒng)一過程來說就是用例驅動。就是我們要有了有效的把我們對業(yè)務的理解和業(yè)務需求的理解，具體到統(tǒng)一過程里面所要實現(xiàn)的支持網(wǎng)絡控制和轉化分離的那些功能，我們怎么樣把它描述出來。以一種可以管理的方式，可以不斷的更新，用它來指導我們的架構設計以及后面的其他模型的設計。

第三點是我們不可能一下子把所有的東西都做出來，要按照一定的優(yōu)先級。以一種循環(huán)迭代的方式實現(xiàn)軟件工程方面的工作。這里提到一點，最開始統(tǒng)一過程是強調(diào)先把最關鍵的技術點設計好，把圓心做出來，這樣能夠在最早的時間里證明我們的方案，我們的問題可解還是不可解，如果不可解或者不可行，我們能夠盡早的控制風險。這三條原則是大家需要一直遵循的。

為了簡化復雜度兩個最重要的事情一個是抽象化。我們要不斷的把很多共性的東西抽象出來。在模式驅動方面底下我們提到過原模型與平臺無關的模型，或者是分析模型或者是設計模型。

另外一點就是怎么樣把大的復雜的系統(tǒng)分解以后怎么能夠一塊一塊的研究它，研究系統(tǒng)與系統(tǒng)之間相關的程度，以什么樣的方式讓它們進行互動。

當然我提到的所有這些作為一個架構師或者項目設計師我們不能簡單的就以畫一個圖為我們的終極目標。我們需要有集成的工具支持。最近這兩三年在支持模式驅動開發(fā)方面，尤其在工具進一步能力擴展和集成方面，我們已經(jīng)取得了突破性的進展。主要的就是我建了這些模式以后，可以在模式上進行各種不銅模是的轉換，可以進行擴展。另外我們可以把全周期的需求到一些功能、一些組件，服務，全周期的管理這些產(chǎn)品都把它很好的串起來。這樣當我們的技術發(fā)生變化和需求發(fā)生變化的時候我們知道從什么方面入手。比如1.3出來一個新的特性，我們通過模型做的比較好的話，能夠很快分析出來大概什么地方出現(xiàn)了什么影響，要花多大的代價。

另一個就是能不能盡可能的實現(xiàn)雙向從模型到代碼從代碼再回到模型的軟件工程的方式。

講到了一些很基本的東西不知道大家聽沒聽明白，現(xiàn)在講講華為設計LAB的過程中所涉及的原則，我們是一個開放的平臺。我們反復強調(diào)幾個著力點，一個是功能要能擴展，協(xié)議變了能花最小的代價把新的功能實現(xiàn)出來。第二個1.0里只有一個單一的控制器控制大的網(wǎng)絡，這是不太可能的。而且這個東西一旦出故障怎么辦?所以怎么樣把控制器系統(tǒng)變成一個很容易添加，而變得更加可靠。第二點是怎么樣最有效的使用基于模型驅動開發(fā)的方式來做架構組建、集成和擴展。

另外一個就是承用，Openflow從08年開始到現(xiàn)在基于Openflow1.0的版本，從控制器、交換機有很多開源的代碼，而且還有好幾個博士論文專門做這方面的工作。這些東西是我們需要充分學習、理解的。知道人家在某一個關鍵點上為什么用某種技術。所以我們要盡可能的重用，要利用人家做的應用縮短我們的研發(fā)周期。

剛才提到了SDN Openflow，第一個它很多地方需要更深層次的了解。另外我想強調(diào)，從Openflow1.0到2011年2月份公布的1.1，再到12月份公布的 1.2是有很大的差別的。Openflow1.0我們可以看作它是一種概念驗證的協(xié)議，它提了很多思想。但是它主要的目的不是為了產(chǎn)業(yè)化，它是希望能在校園網(wǎng)絡的環(huán)境下盡快的驗證這種簡單的思想可不可行。所以它在性能、高可靠性方面沒有太多的考慮。為了節(jié)省昂貴的存儲資源加速查找和找到更好的路由。再到 1.2是多控制器，就是需要多個控制器來管理一個大的子網(wǎng)。

另外對一些新的比如IPv6的支持，我們希望能夠盡量使用現(xiàn)在已經(jīng)開發(fā)、編寫更加成熟的一些技術。由于這些東西的加入。Openflow1.1、1.2更加復雜了，所以最近為有1.2恩的交換機，這是經(jīng)過一年多以后才看到有一些新的東西出來協(xié)議本身已經(jīng)是不兼容了。

以軟件工程的方式做軟件，我們是怎么做的呢?首先是需求開始，比如說就SAAS主要的特性從協(xié)議支持、網(wǎng)絡控制、虛擬網(wǎng)絡支持、交換機管理和網(wǎng)絡配置幾個特性方面把一些重要的特性列出來。我們自己有一套模型。我們在特性效果根據(jù)1.2的協(xié)議，把它需要的主要功能需求也組合到了一起，在業(yè)務或者需求模型底下。

有了比較抽象的功能需求以后，我們說到了要用例驅動，這樣就更加具體化，比如主機控制器、管理運用、網(wǎng)元包括交換機各自希望能做一些什么工作。當然在很多情況下是大家協(xié)同一起完成。

另外做軟件工程一些項目失敗或者變得不可控制的原因就是我們花了很多時間做前期的需求文檔。大的項目我看到過13卷的需求文檔，最后項目還是失敗了。有了需求文檔還不夠，怎么樣從需求到用例到組件到關鍵對象和邏輯服務，怎么樣把這些通過一種矩陣追蹤的方式讓我們很容易的查到在什么地方實現(xiàn)了什么特性?這是軟件工程里面現(xiàn)在需求管理里面融合軟件架構和設計很重要的一點。

整體架構：第一步是SOX，里面有對交換機的管理，局部化的網(wǎng)絡信息庫。另外一個是中央集中控制邏輯，包括公共的共享功能。包括底層對主機，對鏈路的管理、拓撲的管理，包括現(xiàn)在一些比較基本的路由的算法。再往上走是API，上面還有一層管理應用。這個看作控制器的話，要利用北上的API支持上層的管理利用，我們把管理利用和控制器的組合叫做智能網(wǎng)絡控制器操作系統(tǒng)，這個操作系統(tǒng)稍微擴展了一點點。因為我們?nèi)A為自己有一個管道操作系統(tǒng)，是比較抽象比較大的概念。

領域一個就是東西向，多個控制器的集群能夠把下面的網(wǎng)絡有效的控制起來，通過基于服務的分布式管理方式，我們叫做軟件服務定義的網(wǎng)絡，中間有一層就是網(wǎng)絡軟件服務層，通過它來實現(xiàn)東西向的集成。我們這個網(wǎng)絡就可以一步步的做大。

最后給大家匯報一下我們?nèi)ツ?0月份參加ONF測試的結果。我們第一次實現(xiàn)了1.2的組網(wǎng)事件，目前實現(xiàn)1.2對很多廠家都是非常困難的。第二我們實現(xiàn)了自動網(wǎng)絡拓撲的發(fā)現(xiàn)，交換機能力的學習以及可以和交換機談判、學習。用外了完成對1.2關鍵點特性的驗證。比如說多控制器、多流表，對IPv6部分支持。當我們把配置做好以后，我們網(wǎng)絡的展示界面可以把拓撲以及我們所學習到的能力展示給用戶。

另一個是多控制器。在我們這個網(wǎng)絡里面當逐步增加網(wǎng)絡流量的注入的時候可以看到控制器的矢量同開始的兩個慢慢增加到六個，流量降下去的時候回到了兩個，是根據(jù)獨立需求和網(wǎng)絡狀態(tài)。

我們未來想做些什么事情：我們完成一個控制性集群，現(xiàn)在想把它做分布式的網(wǎng)絡操作系統(tǒng)，基于完全豐富的網(wǎng)絡信息庫加上分布式的控制集群。第二個是進一步提高性能。其中某幾個重要的過程是把原模型或者說各種支持Openflow或者未來協(xié)議的模型構建出來。另外就是基于全網(wǎng)拓撲狀態(tài)和流量特征的資源分配。第四個是應用場景。我們希望能夠從對數(shù)據(jù)中心的支持到更加復雜的校園網(wǎng)、企業(yè)網(wǎng)包括運營商網(wǎng)絡更加具有意義的運營商層上來。

zhangcun