1. 程式人生 > >連載38:軟件體系設計新方向:數學抽象、設計模式、系統架構與方案設計(簡化版)(袁曉河著)

連載38:軟件體系設計新方向:數學抽象、設計模式、系統架構與方案設計(簡化版)(袁曉河著)

數據業務 完全 等等 組裝 規劃 訪問 復雜 平臺 進一步

從另一個角度看設計

真理可能在少數人一邊。

---柏拉圖

最初偏離真理毫厘,到頭來就會謬之千裏。

---亞裏士多德

前面的章節中我們從一些正規的角度來闡述軟件設計的基本思想原理,然而,如果我們被桎梏於這些所謂的規範化之中,那麽我們的設計就黯然失色了,如果不采用另一只眼睛來觀察,則永遠不可能產生真正的突破。這一章我們就暢所欲言,從另外的角度來看設計。

1. 統一性

在物理學上,萬物歸一,就是統一成少數的一個或者幾個原理,而這樣的原理能夠更好的驅動整個世界的運轉,就如同有質量就有萬有引力(或者是更深奧的有質量的物體下具有空間彎曲的廣義相對論)一樣,對於我們的設計來說,如果能夠歸於統一是一個非常棒的思路。例如:在我們的一個資費設計中,從業務上將我們存在試用和正式使用的兩個狀態,試用有時間限制和數量限制。而正式使用的根據費率的方式進行計時和計數進行處理。如果按照一般的設計,我們必然將之劃分成兩個狀態。然後在程序或者數據庫中進行區別對待。但是我們想一想,這樣是否多余了呢?我們是否可以加之統一起來,我們將試用作為一個默認的處理,設置時間為

1周,數量限制為2個。那麽這個設置可作為數據庫記錄中的一個默認設置。這樣我就不必進行什麽特殊的類型甄別,試用和正式使用就只是數值上的區別,這樣我的設計方案就大大簡化了。

由於整個世界都趨於一個統一的特點,軟件設計的過程中,亟待需要我們的系統能夠進行統一化的方式來進行規劃和設計。

例如,從計算機體系結構來說,最為簡單的地址統一編碼,就能夠給我們帶來十足的好處,可能基於不同的訪問速度,不同硬件構造的設備,但是從抽象概念的地址方面,如果我們按照統一的地址進行編碼,那麽我們的軟件系統就首先從這些繁雜的硬件特性中獨立開來,在我們的軟件系統中,不用體現這些地址上讀寫方式存在何種差異,軟件系統的最為簡要的統一性就獲得體現。

PWE3邊到邊偽線仿真中,IETF指定的PWE3的動機:

ü 通用標簽,提供統一的數據傳送平臺

各種不同業務,如SDH/STM-N、ATM、IP網絡基於包,傳輸時運營商希望這些業務均能以統一的方式匯聚,減少網絡數量,配置維護的復雜度和鏈路的費用。

TDM采用固定帶寬的時隙劃分,它不支持突發數據業務的統計復用。

ATM技術,采用5字節頭家48字節凈荷固定長度的信元為基本傳送單元,它除了ATM短信元帶來的開銷以外,還有ATM分拆和組裝。(SAR)過程,特別是在高速率是非常困難,基於優化的PSN(分組交換網),這種網絡應支持任意長度的網絡流。具有執行優化的網絡流量工程的能力,並對網絡業務流具有分類,執行流量管理控制和按Qos優先等級的保障機制。

ü 仿真專線,提高高回報率的網絡業務

盡管Internet業務是增長速度最快的業務,但它沒有產生每比特最高的回報。對終端用戶來說,專線價格雖然要貴過IP數據業務,但它有更好的業務質量和安全性的保證。

ü 數據感知,實現了不同數據業務的匯聚

數據業務的突發引起整個網絡帶寬的不足和對業務的Qos構成影響,必須要具有差異化,數據感知的另一個好處是業務在PE側得到Qos的保障,在核心的IP/MPLS傳送網絡有專門的隧道,等於核心層通過PE側知道了用戶業務的質量要求,方便了端到端的業務和網絡資源配置,大大簡化了NGN網絡的操作。

ü 保護投資,提供網絡業務

PWE3提供了一個通用的封裝層,使用PWE3+MPLS構建的網絡,可以再新的2層封裝新式的業務加入時無需對原有網絡做任何改造,公用網絡中已經安裝巨大數量的傳統設備,需要保留這些設備,並與之互連互通。

進行統一首先需要分離,雖然這看起來相矛盾的處理過程,其實並非矛盾,因為只有分離才能夠進行統一,只有分離才能夠更好的進行抽象,並將共通的東西獨立出來,然後再規劃統一的處理過程,所以,分離是統一的基礎,在分離機制中比較詳細的描述了分離的方式和方法,這裏就不再贅述了。

一般的情況下,我們可以通過兩種不同的抽象過程來達到統一的目的,這兩種抽象過程稱為“弱抽象”和“強抽象”,前者是從特殊到一般的抽象過程,也就是把一類具體事物或事物關系中的共性加以抽象概括的過程,後者是通過引入新特征而強化原結構的手續所完成的抽象過程,可以簡單來說,前者就是我們常常看到的通過抽象的方式,將類事物的共有部分“抽離”出來,後者是通過“填補”的方式,引入新的特征方式,來達到整個系統的一致性的完備性。

第一種方式是常見的,只要我們采用抽象、比較轉換的處理就能夠更好的達到我們的預期的目標,但是這種方式往往容易因為一些特殊的反例而統一失敗的情況。我們還是用編碼的例子來說明特殊情況給我們帶來的困惑,過去我們常常使用過的ASCII編碼方式能夠很好的描述英文字母以及字符,ASCII可以使用8位也就是1個字節完全進行描述,但是,當我們需要表達漢字、日語、韓文等形式情況下,我們需要進行擴展,於是就促成了UNICODE編碼,UNICODE編碼采用2個字節,能夠覆蓋幾乎目前的語言字符,雖然從統一的場面來看已經非常完美了,但是,還存在一些特殊的字符(例如古漢語中的一些繁體字等)依然無法通過UNICODE來表示,但此時,如果再通過更多字節的擴展,其實我們的系統變得非常的生硬了,我們很難更好的進行“平滑的擴展”,註意這裏的“平滑”的含義(我們至少在兼容性方式,繼續擴展方面無法做到統一化的處理)。於是,為了更好的統一,就出現了一些中間格式的字符集,例如我們常常使用的UTF-8編碼。

UTF-8編碼規則:如果只有一個字節則其最高二進制位為0;如果是多字節,其第一個字節從最高位開始,連續的二進制位值為1的個數決定了其編碼的位數,其余各字節均以10開頭。

通過UTF-8進行編碼,給我們帶來了哪些好處呢?一方面是我們兼容ASCIIASCII表示的信息好UFT-8在表示這個區域的字符是一個值。另一方面,我們可以按照統一規律將字符擴展到4字節、6字節或者更多的字節,而且這樣的擴展也不需要重新打亂之前的編碼序號,這樣就通過規則的統一,達到一個更加“平滑”的兼容擴展。同時UTF-8編碼可以通過屏蔽位和移位操作快速讀寫。

因此,大家是否看到,在進行統一化處理過程中,一方面需要及時發現這些反例,另一方面需要及時的考慮如何將這些反例融入到我們的統一化系統中,有時候,就是因為一個這樣的反例就從某個角度上推翻了我們的統一化設計思路和方法,因此這對於我們將是十分寶貴的經驗。

第二種抽象方式,其實要求我們進行一些適當的補充,而這些補充能夠通過更加統一化的形式來進行處理,這樣的處理方式很多,例如將指針進行叠代器的泛化處理等等,我們這裏借用大師們的一個例子來說明這種統一化的方式的特點(通過定義NULL對象的方法來統一化我們的類體系)。

比如在一個系統中我們可以通過接口和組合模式來進行統一化的操作,如圖7-2所示。

技術分享圖片

7-2

但是,如果我們需要判斷一個指針(引用)的時候,我們需要執行判斷是否為空(NULL)的處理,此時如果我們增補這個NULL為一個NULL的類,將之統一到這個體系之中,那麽我們的程序代碼就能夠更好的脫離具體的環境,能夠更好的抽象並形成體系,如圖7-3所示。

技術分享圖片

7-3

這樣我們就可以在NULL的重寫接口的函數處理中進行我們認為非常合理的處理,然後非常美妙的達到我們的形式化的統一。所以這種抽象的方法要求我們自原有特性不足的情況下,能夠根據進一步的擴展來劃歸到一個統一的形式化處理中,但是,這樣的擴展也是有其條件和限制的,有很多時候,往往可能擴展不當而導致系統變得更加的非統一了,我想失敗的情況肯定比成功的情況多得多,不然我們可以信手拈來就形成一個統一了,然而現實可能會更加“殘酷”一些。

統一美揭示了系統的普遍聯系上,美在我們對客觀世界和諧協調、井然有序的真實反映上,從而使人們居高臨下,攬括一切,增強了人們洞察世界的深廣度,使人們獲得更多的新成果,理解更多的新現象,對未知事物作出更可靠的預言,在改造世界中取得更大的勝利.追求統一美,必將促進軟件設計的進一步發展。

由此統一性能夠直接帶給我們的是一種化繁為簡的方案,這樣的處理能夠大大簡化系統的復雜性,同時讓理解和分析系統的其他人也能夠非常簡單的明白我們的系統,並且能夠在這種統一的框架下進行更好的增量方式的開發和應用。

再回頭看一下REST設計風格:

REST即表述性狀態傳遞(英文:Representational State Transfer,簡稱REST)是Roy Fielding博士在2000年他的博士論文中提出來的一種軟件架構風格。它是一種針對網絡應用的設計和開發方式,可以降低開發的復雜性,提高系統的可伸縮性。

REST設計準則:

ü 網絡上的所有事物都被抽象為資源(resource)

ü 每個資源對應一個唯一的資源標識符(resource identifier)

ü 通過通用的連接器接口(generic connector interface)對資源進行操作。

ü 對資源的各種操作不會改變資源標識符。

ü 所有的操作都是無狀態的(stateless)


連載38:軟件體系設計新方向:數學抽象、設計模式、系統架構與方案設計(簡化版)(袁曉河著)