自斯坦福CLEANState項(xiàng)目孵化OpenFlow協(xié)議，在2009年業(yè)界正式提出軟件定義網(wǎng)絡(luò)(SDN)以來(lái)，業(yè)界已經(jīng)有上百家企業(yè)正式加入到開(kāi)放網(wǎng)絡(luò)基金會(huì)(ONF)。SDN的產(chǎn)品及樣機(jī)覆蓋了SDN控制器、交換機(jī)、路由、虛擬網(wǎng)絡(luò)功能部件等產(chǎn)品，應(yīng)用場(chǎng)景覆蓋了數(shù)據(jù)中心網(wǎng)絡(luò)、企業(yè)網(wǎng)、校園網(wǎng)、光網(wǎng)絡(luò)及業(yè)務(wù)邊緣網(wǎng)絡(luò)等。迄今為止，SDN的功能架構(gòu)在不同的領(lǐng)域，出于技術(shù)和利益博弈兩個(gè)方面的原因，業(yè)界尚無(wú)統(tǒng)一的認(rèn)識(shí)。一般來(lái)說(shuō)，ONF定義的轉(zhuǎn)發(fā)、控制、應(yīng)用3層架構(gòu)得到相對(duì)廣泛的認(rèn)同。

　　1.SDN架構(gòu)

　　按照ONF的定義，SDN分為基礎(chǔ)設(shè)施層、控制層和應(yīng)用層，見(jiàn)圖1所示。虛擬化在基礎(chǔ)設(shè)施以及控制層兩個(gè)層面上實(shí)現(xiàn)，前者實(shí)現(xiàn)設(shè)備級(jí)的虛擬化，比如一個(gè)物理交換機(jī)支持多個(gè)邏輯交換機(jī)；后者實(shí)現(xiàn)網(wǎng)絡(luò)級(jí)的虛擬化，首先是SDN控制器將整個(gè)網(wǎng)絡(luò)當(dāng)成一個(gè)邏輯的超級(jí)交換機(jī)進(jìn)行管理控制，其次將物理資源進(jìn)一步根據(jù)端口、媒體訪問(wèn)控制(MAC)地址、IP地址段等信息劃分為多個(gè)虛擬網(wǎng)絡(luò)遵照傳統(tǒng)通信領(lǐng)域的慣例，在架構(gòu)圖中下方為南，上方為北，因此基礎(chǔ)設(shè)施層和轉(zhuǎn)發(fā)層之間的接口稱為南向接口。ONF標(biāo)準(zhǔn)化的是OpenFlow協(xié)議，互聯(lián)網(wǎng)工程任務(wù)組(IETF)正在制訂路由系統(tǒng)接口(12RS)協(xié)議�？刂茖雍蛻�(yīng)用層之間的接口稱為北向接口，業(yè)界主流實(shí)現(xiàn)的是基于超文本傳輸協(xié)議(HTTP)的RESTful接口，具體編程接口隨應(yīng)用場(chǎng)景不同而有所區(qū)別。

圖1 SDN分層架構(gòu)

　　在更廣義的SDN架構(gòu)中，控制層之上還有業(yè)務(wù)編排層，主要實(shí)現(xiàn)SDN域間資源的統(tǒng)一管理、SDN網(wǎng)絡(luò)和其他資源的統(tǒng)一調(diào)度，比如0penstack+SDN的數(shù)據(jù)中心解決方案。

　　Openstack統(tǒng)一調(diào)度計(jì)算、網(wǎng)絡(luò)和存儲(chǔ)資源，相當(dāng)于SDN的業(yè)務(wù)編排層。站在SDN的角度來(lái)看，控制層之上如何劃分則是廠商解決方案、應(yīng)用實(shí)現(xiàn)的具體行為，就如同傳輸控制協(xié)議，網(wǎng)間協(xié)議(TCP/IP)并不關(guān)心應(yīng)用層進(jìn)一步如何分層設(shè)計(jì)，統(tǒng)稱為應(yīng)用層。站在整個(gè)網(wǎng)路架構(gòu)的層面來(lái)看SDN，則業(yè)界存在不同的看法：

    (1)SDN只進(jìn)行區(qū)域性網(wǎng)絡(luò)改造，可將SDN控制域看成一個(gè)超級(jí)設(shè)備。SDN并不改變?cè)�有的網(wǎng)絡(luò)橫向接口，邊界網(wǎng)關(guān)協(xié)議(BGP)/多協(xié)議標(biāo)簽交換(MPLS)等仍然有效。

    (2)SDN控制域間定義專門(mén)/增強(qiáng)的SDN東西向接口，將SDN作為整個(gè)網(wǎng)絡(luò)的控制平面。

    本文認(rèn)為，第一種方案更加具有現(xiàn)實(shí)意義，利于網(wǎng)絡(luò)的平滑演進(jìn)。第二種方案中的東西向接口要么可以通過(guò)擴(kuò)充現(xiàn)有的BGP，MPLS協(xié)議實(shí)現(xiàn)，要么可以通過(guò)北向接口在業(yè)務(wù)編排層面進(jìn)行實(shí)現(xiàn)，如果要定義更加專用的SDN東西向接口，雖然有可能可以增強(qiáng)整網(wǎng)的能力，但是無(wú)疑也為部署增加了難度，業(yè)界正在探索之中。

　　2.ZENIC架構(gòu)及控制面關(guān)鍵技術(shù)實(shí)現(xiàn)

　　現(xiàn)有來(lái)自于學(xué)術(shù)界的開(kāi)源SDN控制器實(shí)現(xiàn)基于OpenFlow協(xié)議，整個(gè)轉(zhuǎn)發(fā)模型也綁定于某個(gè)具體的OpenFlow協(xié)議版本”。對(duì)于商用系統(tǒng)而言，必須要考慮整個(gè)產(chǎn)品生命周期內(nèi)協(xié)議接口的兼容，還要考慮不同應(yīng)用場(chǎng)景的區(qū)別以及和多廠家、多協(xié)議接口的差別，因此SDN控制面必須設(shè)置一個(gè)兼容多版本OpenFlow、多種控制協(xié)議以及不同轉(zhuǎn)發(fā)面能力的抽象層，我們稱之為轉(zhuǎn)發(fā)抽象層(FAL)，在此之上為網(wǎng)絡(luò)操作系統(tǒng)(NOS)核心以及應(yīng)用層提供的接口是獨(dú)立于具體的協(xié)議和硬件能力的。在OpenDaylight中，此層次稱為業(yè)務(wù)抽象層(SAL)”。

　　本文實(shí)現(xiàn)一種SDN控制器——ZENIC，其架構(gòu)如圖2所示。圖2自上而下主要包括協(xié)議棧、驅(qū)動(dòng)和轉(zhuǎn)發(fā)抽象層、NOS內(nèi)核和應(yīng)用層。

圖2 ZENIC架構(gòu)

    2.1 轉(zhuǎn)發(fā)抽象層及驅(qū)動(dòng)層

    轉(zhuǎn)發(fā)抽象層定義統(tǒng)一的轉(zhuǎn)發(fā)控制接口，包括對(duì)抽象轉(zhuǎn)發(fā)面的狀態(tài)、能力、硬件資源、轉(zhuǎn)發(fā)表、統(tǒng)計(jì)信息等進(jìn)行讀取/操作，相當(dāng)于驅(qū)動(dòng)的基類。同時(shí)轉(zhuǎn)發(fā)抽象層還管理轉(zhuǎn)發(fā)面驅(qū)動(dòng)的實(shí)例，根據(jù)轉(zhuǎn)發(fā)面接入時(shí)的基本能力協(xié)商加載不同的驅(qū)動(dòng)實(shí)例，將轉(zhuǎn)發(fā)面的控制連接綁定到相應(yīng)的驅(qū)動(dòng)實(shí)例。

    每個(gè)具體設(shè)備的驅(qū)動(dòng)實(shí)現(xiàn)轉(zhuǎn)發(fā)抽象層的接口，完成不同接口協(xié)議、不同硬件能力到轉(zhuǎn)發(fā)抽象層的統(tǒng)一適配。從控制面及其上層應(yīng)用的角度來(lái)看，F(xiàn)AL提供了一個(gè)統(tǒng)一的轉(zhuǎn)發(fā)操縱接口，但是由于各轉(zhuǎn)發(fā)面的能力差別較大，應(yīng)用對(duì)于轉(zhuǎn)發(fā)面的操作存在失敗的可能，因此FAL需要向應(yīng)用提供轉(zhuǎn)發(fā)面能力獲取/協(xié)商的接口。ZENIC已經(jīng)實(shí)現(xiàn)對(duì)于OpenFlow1.1/1.2/1.3的自適應(yīng)協(xié)商。

    2.2 網(wǎng)絡(luò)操作系統(tǒng)內(nèi)核層

    NOS內(nèi)核層是對(duì)網(wǎng)絡(luò)、系統(tǒng)資源的管理，包括拓?fù)涔芾�、主機(jī)管理、接口資源管理、轉(zhuǎn)發(fā)表管理等，并管理物理拓?fù)�、虛擬拓?fù)�、轉(zhuǎn)發(fā)表等構(gòu)成的網(wǎng)絡(luò)信息庫(kù)。總體而言，內(nèi)核層并無(wú)預(yù)設(shè)的網(wǎng)絡(luò)轉(zhuǎn)發(fā)邏輯處理，而是維護(hù)準(zhǔn)確的網(wǎng)絡(luò)拓?fù)�、資源狀態(tài)以及轉(zhuǎn)發(fā)表的存儲(chǔ)、合成，接受應(yīng)用對(duì)于網(wǎng)絡(luò)、資源狀態(tài)的訂閱以及應(yīng)用對(duì)于網(wǎng)絡(luò)資源、轉(zhuǎn)發(fā)邏輯的操作。

    拓?fù)涔芾淼膶?shí)現(xiàn)目前能夠基于OpenFlow標(biāo)準(zhǔn)化的實(shí)現(xiàn)是基于控制器在鏈路上周期下發(fā)探測(cè)報(bào)文實(shí)現(xiàn)的，以太網(wǎng)一般是基于鏈路層發(fā)現(xiàn)協(xié)議(LLDP)實(shí)現(xiàn)。這樣實(shí)現(xiàn)的好處是轉(zhuǎn)發(fā)面完全無(wú)需感知，缺點(diǎn)是鏈路較多、檢測(cè)定時(shí)器較短時(shí)，控制器的開(kāi)銷較高。另外一種方式是有轉(zhuǎn)發(fā)面維護(hù)鏈路檢測(cè)定時(shí)器，自行檢測(cè)，將狀態(tài)上報(bào)，這一實(shí)現(xiàn)方式的優(yōu)點(diǎn)是控制面開(kāi)銷小，缺點(diǎn)是需要轉(zhuǎn)發(fā)面具有一定的預(yù)設(shè)邏輯。

    內(nèi)核層不僅要維護(hù)網(wǎng)絡(luò)節(jié)點(diǎn)、拓?fù)錉顟B(tài)，而且也需要收集基本的主機(jī)位置、狀態(tài)，從而可以給應(yīng)用提供一個(gè)完整的網(wǎng)絡(luò)視圖，進(jìn)一步做轉(zhuǎn)發(fā)、業(yè)務(wù)的決策。

　　對(duì)于SDN控制器而言，網(wǎng)絡(luò)虛擬化應(yīng)該內(nèi)置支持。虛擬化應(yīng)該內(nèi)置支持。虛擬化首先是轉(zhuǎn)發(fā)面資源的分區(qū)和隔離，比如按照端口、邏輯端口、主機(jī)MAC地址、IP地址段等進(jìn)行虛擬網(wǎng)絡(luò)的劃分，其次是虛擬拓?fù)鋵?duì)于其上客戶/應(yīng)用的權(quán)限管理適配。

　　OpenFlow的流表模型以及對(duì)于交換機(jī)統(tǒng)一、扁平化的管理視圖帶來(lái)了很多問(wèn)題，包括交換機(jī)硬件復(fù)雜化、不靈活、主機(jī)和網(wǎng)絡(luò)需緊耦合”。在ZENIC系統(tǒng)中，將內(nèi)聯(lián)網(wǎng)絡(luò)管理作為內(nèi)核服務(wù)之一，解耦接入網(wǎng)絡(luò)和互聯(lián)網(wǎng)絡(luò)。內(nèi)核管理互聯(lián)網(wǎng)絡(luò)的封裝格式，上層應(yīng)用只需要決策SDN控制域內(nèi)兩個(gè)接入端口的位置和策略。內(nèi)核計(jì)算出完整端到端路徑，并在接入側(cè)將轉(zhuǎn)發(fā)決策映射到互聯(lián)網(wǎng)絡(luò)路徑的封裝標(biāo)簽。ZENIC支持多種互聯(lián)網(wǎng)絡(luò)封裝格式，包括MPLS、虛擬局域網(wǎng)(VLAN)等，下一步將支持虛擬擴(kuò)展的局域網(wǎng)(VXLAN)/通用路由封裝協(xié)議(GRE)。這種接入一互聯(lián)網(wǎng)絡(luò)的模式，應(yīng)用完全無(wú)需感知，專注于主機(jī)接入側(cè)的策略。同時(shí)內(nèi)連網(wǎng)絡(luò)管理本身也可以開(kāi)放接口，支持應(yīng)用自定義的路由算法和策略。

　　2.3 北向應(yīng)用編程接口

　　北向應(yīng)用編程接口(API)在不同的應(yīng)用場(chǎng)景中需求不同，對(duì)于封裝的要求也有區(qū)分。如果將網(wǎng)絡(luò)的原子能力暴露給應(yīng)用，是有可能形成統(tǒng)一的API，但是由于缺乏封裝和易用性，應(yīng)用編程、實(shí)現(xiàn)的復(fù)雜度較高。比如有廠商實(shí)現(xiàn)的設(shè)備級(jí)開(kāi)放API多達(dá)700多個(gè)，涵蓋幾乎所有協(xié)議和設(shè)備功能，但是對(duì)于SDN而言，將會(huì)面臨至少兩類應(yīng)用，需求迥異：

　　(1)專業(yè)網(wǎng)絡(luò)應(yīng)用

　　訂制化需求高，需要更加細(xì)節(jié)的API，對(duì)底層網(wǎng)絡(luò)的操作操縱能力強(qiáng)，比如訂制開(kāi)發(fā)路由協(xié)議、訂制進(jìn)行精細(xì)化的流量調(diào)度。

　　(2)普通應(yīng)用

　　將網(wǎng)絡(luò)作為一種服務(wù)，只是請(qǐng)求網(wǎng)絡(luò)為應(yīng)用提供服務(wù)，并不關(guān)心網(wǎng)絡(luò)細(xì)節(jié)。

　　對(duì)于后者，北向接口最好能封裝幾個(gè)模型和交互簡(jiǎn)單、易懂的服務(wù)接口，如向網(wǎng)絡(luò)請(qǐng)求創(chuàng)建從交換機(jī)A端口l到交換機(jī)B端口2的一條lGb/s有帶寬保證的通路，而不是由應(yīng)用向路徑上的交換機(jī)逐個(gè)下發(fā)轉(zhuǎn)發(fā)表以及相應(yīng)的隊(duì)列配置參數(shù)。

　　還有一種北向接口的思路就是由應(yīng)用定義自身對(duì)網(wǎng)絡(luò)的需求和操作接口，網(wǎng)絡(luò)廠商提供插件實(shí)現(xiàn)應(yīng)用的網(wǎng)絡(luò)接口。比較典型的是Openstack的Quantum組件，其定義了網(wǎng)絡(luò)的API，由各個(gè)廠商提供Quantum Plug—In來(lái)控制自己的SDN控制器或網(wǎng)絡(luò)設(shè)備。此架構(gòu)相當(dāng)于把SDN的北向接口標(biāo)準(zhǔn)化工作往上推到應(yīng)用，網(wǎng)絡(luò)去適配應(yīng)用需求。

　　兩種思路各有利弊，由SDN定義北向接口比較理想化，試圖統(tǒng)一解決所有問(wèn)題，但是網(wǎng)絡(luò)很難一一理解應(yīng)用的需求，標(biāo)準(zhǔn)化的推進(jìn)工作相對(duì)困難，而且易用性也很難保證；應(yīng)用驅(qū)動(dòng)的模式使得SDN落地更加容易，但是應(yīng)用和多廠商網(wǎng)絡(luò)之間的互通要較耗費(fèi)更大代價(jià)。ZENIC提供基本的細(xì)顆粒度的底層API，同時(shí)提供封裝后的虛擬網(wǎng)絡(luò)API，目前已經(jīng)提供Openstack的Quantum Plug—In接入到Openstack之中。

　　2.4 分布式處理算法

　　控制面本身的分布式架構(gòu)以及SDN轉(zhuǎn)發(fā)控制分離的架構(gòu)帶來(lái)了狀態(tài)同步的額外開(kāi)銷，準(zhǔn)確的SDN全局視圖能夠保證決策的精確性和實(shí)時(shí)性，對(duì)于負(fù)載均衡等應(yīng)用而言可以提升資源利用率，但需更加頻繁的信息同步，這大大降低了系統(tǒng)性能。本文從設(shè)計(jì)上采用兩種手段：控制器的分布式方案盡可能減少消息的復(fù)制；控制轉(zhuǎn)發(fā)之間的狀態(tài)同步由用戶根據(jù)需求進(jìn)行配置，只進(jìn)行必要、夠用的狀態(tài)復(fù)制。

　　傳統(tǒng)的集群網(wǎng)絡(luò)系統(tǒng)控制面基本上是基于進(jìn)程的分布式處理，比如各個(gè)不同的業(yè)務(wù)進(jìn)程分布在不同的CPU上，但是一種進(jìn)程仍然是單實(shí)例或少數(shù)實(shí)例，并行度受限。在單一業(yè)務(wù)進(jìn)程突發(fā)負(fù)載的情況下，比如自治域問(wèn)路由調(diào)整時(shí)的邊界網(wǎng)關(guān)協(xié)議(BGP)進(jìn)程就是“瓶頸”。對(duì)于SDN而言，由于控制的網(wǎng)絡(luò)規(guī)�？赡苓h(yuǎn)”高于集群路由器，對(duì)控制面節(jié)點(diǎn)數(shù)墮的要求更高，因此這種方法存在“瓶頸”不太可行。

　　分布式哈希表(DHT)算法提供了一個(gè)可伸縮的分布式數(shù)據(jù)存儲(chǔ)/路由算法。對(duì)于傳統(tǒng)應(yīng)用不穩(wěn)定網(wǎng)絡(luò)的Log2(N)查找復(fù)雜度的算法，在數(shù)據(jù)中心、電信網(wǎng)絡(luò)應(yīng)用時(shí)，業(yè)界提出了多種增強(qiáng)的單跳算法，部分基于單跳DHT的增強(qiáng)型結(jié)構(gòu)化查詢語(yǔ)言系統(tǒng)(No—SQL)開(kāi)源系統(tǒng)也已經(jīng)過(guò)商用考驗(yàn)，包括Dynamo、Cassandra等，最早公開(kāi)采用DHT分布式算法的SDN控制器是onix，OpenDaylight項(xiàng)目近期也提出來(lái)采用Cassandra作為底層的分布式數(shù)據(jù)庫(kù)系統(tǒng)。作者所在團(tuán)隊(duì)也實(shí)現(xiàn)了改良的單跳DHT算法”。

　　DHT算法基于一致性哈希，適用于鍵一值(Key—Value)存儲(chǔ)模型，類結(jié)構(gòu)化查詢語(yǔ)言(SQL)的支持需要進(jìn)一步封裝。對(duì)于SDN控制器而言，拓?fù)湫畔⑹侨�局性的，不適合于DHT存儲(chǔ)，而是需要進(jìn)行額外的全局復(fù)制。與轉(zhuǎn)發(fā)設(shè)備相關(guān)的信息組織以交換節(jié)點(diǎn)為單位進(jìn)行分布式儲(chǔ)存，可以滿足基本要求，但是顆粒度較粗，不利于控制節(jié)點(diǎn)之間的負(fù)載均衡。主機(jī)信息可以按IP地址、MAC表兩個(gè)維度進(jìn)行分布化，更加均勻。

　　3.轉(zhuǎn)發(fā)層面的轉(zhuǎn)發(fā)抽象技術(shù)實(shí)現(xiàn)

　　OpenFlow 1.0提供的是一個(gè)單流表的抽象模型91，OpenFlow 1.1之后定義了一個(gè)多級(jí)流表的模型。12RS以及部分廠商的開(kāi)放接口給應(yīng)用暴露的是一個(gè)路由信息庫(kù)(RIB)之上的多種業(yè)務(wù)表，表之間隱含了協(xié)議規(guī)定的各種邏輯。OpenFlow給了應(yīng)用/控制面對(duì)轉(zhuǎn)發(fā)面最大程度的操縱能力，理論上可以完全不受現(xiàn)有網(wǎng)絡(luò)協(xié)議的限制，轉(zhuǎn)發(fā)面可以是完全傻瓜化指令執(zhí)行引擎，而其他開(kāi)放API則是現(xiàn)有協(xié)議框架下的開(kāi)放API，有嚴(yán)格的限定條件。

　　OpenFlowl.0非常簡(jiǎn)單，但是需要三態(tài)內(nèi)容尋址存儲(chǔ)器(TCAM)的支持，而TCAM價(jià)格相對(duì)較昂貴，同時(shí)其單表結(jié)構(gòu)使得復(fù)雜轉(zhuǎn)發(fā)邏輯的分解很困難。在現(xiàn)有基于專用集成電路芯片(ASIC)的交換機(jī)上，OpenFlow1.0可以很容易地映射到AcL流水線之上，因此目前市場(chǎng)上支持OpenFlow的以太網(wǎng)交換機(jī)絕大多數(shù)都是只支持OpenFlow 1.0。

　　OpenFlow 1.x提供了多級(jí)流表模型，增加了更多的表匹配字段和指令類型，能力越來(lái)越強(qiáng)，但是離現(xiàn)有交換機(jī)ASIC的能力越來(lái)越遠(yuǎn)。軟件交換機(jī)可以容易地實(shí)現(xiàn)OpenFlow1.x的多表模型。硬件交換機(jī)可以通過(guò)將自身的傳統(tǒng)ASIC流水線進(jìn)行一些必要的封裝，形成多級(jí)流表上報(bào)給控制面，由控制面進(jìn)行適配，只下發(fā)轉(zhuǎn)發(fā)面支持的指令和表結(jié)構(gòu)。這對(duì)轉(zhuǎn)發(fā)面和控制器均提出了更高的要求。業(yè)界也有少數(shù)廠商推出了可配置TCAM流水環(huán)節(jié)的ASIC，這些將固定寬度的TCAM查表處理單元分解成更小的分片，比如每32比特TCAM是一個(gè)基本分片。應(yīng)用可以靈活定義多個(gè)分片構(gòu)成一級(jí)OpenFlow流表，從而支持了OpenFlow的多級(jí)流表模型。應(yīng)用可以將L2交換、L3交換，路由、ACL等分解到不同的流表上實(shí)現(xiàn)，從而避免了超長(zhǎng)單一流表關(guān)鍵字帶來(lái)的不必要的TCAM開(kāi)銷。

　　4.結(jié)束語(yǔ)

　　SDN通過(guò)采用轉(zhuǎn)發(fā)控制分離、集中控制的理念改造網(wǎng)絡(luò)，試圖將轉(zhuǎn)發(fā)設(shè)備改造為簡(jiǎn)單的受控轉(zhuǎn)發(fā)設(shè)備，將智能留在純軟件化的SDN控制器之中，使得網(wǎng)絡(luò)的創(chuàng)新更加快速、簡(jiǎn)單，這帶來(lái)了開(kāi)放的產(chǎn)業(yè)鏈和新的技術(shù)變革的機(jī)會(huì)。本文描述了作者及其團(tuán)隊(duì)對(duì)于SDN相關(guān)關(guān)鍵技術(shù)的研究成果及SDN控制器產(chǎn)品實(shí)現(xiàn)架構(gòu)，并闡述了各種對(duì)比方案的優(yōu)劣勢(shì)。

核心關(guān)注：拓步ERP系統(tǒng)平臺(tái)是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊(yùn)涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。

轉(zhuǎn)載請(qǐng)注明出處：拓步ERP資訊網(wǎng)http://www.ezxoed.cn/

本文標(biāo)題：軟件定義網(wǎng)絡(luò)關(guān)鍵技術(shù)及其實(shí)現(xiàn)

本文網(wǎng)址：http://www.ezxoed.cn/html/consultation/10839712677.html