我們談云計算SQL Azure本質(zhì)，我們可以換一個角度先從設(shè)計模式上講起。設(shè)計模式(Design Pattern)的一項重要目的就是“溝通”當(dāng)人們談到“歌德式”的設(shè)計模式時，腦海里浮現(xiàn)的應(yīng)該都是一幅很類似的景致，例如：高聳的尖頂建筑、教堂式的外觀門庭……，這是建筑師的設(shè)計模式。當(dāng)然它也成功的融入了大眾的生活層面，而這才可稱為“設(shè)計模式”。

　　軟件界的設(shè)計模式破除了語言的隔閡。Gamma的設(shè)計模式(Design Pattern)這個術(shù)語是在1990年，由Erich Gamma等人從建筑設(shè)計領(lǐng)域引入到軟件計算機科學(xué)里。該書出版至今，國內(nèi)軟件界在開發(fā)應(yīng)用程序上一直很少運用到設(shè)計模式的理論，追根究底的原因很多，溝通應(yīng)該是其罪魁禍?zhǔn)字弧Ｓ晌覀儾蝗菀讖淖置嫔细惺艿竭@種設(shè)計模式的目的或精神，但我們可以經(jīng)過反復(fù)的研讀才能體會出來。這種勞民傷財?shù)默F(xiàn)象，和設(shè)計模式當(dāng)初被推崇的原則完全不符;所以它在這里也就無從生根，程序設(shè)計人員當(dāng)然也就沒有從這里得到太多好處。

　　在這里，我想以聲名遠(yuǎn)播的北京烤鴨是大家再熟悉不過的北京特色了!我們就用“北京烤鴨”來談?wù)?ldquo;一目了然的facade設(shè)計模式”。Facad(外觀模式)設(shè)計模式，是一種結(jié)構(gòu)型模式，它主要解決的問題是：組件的客戶和組件中各種復(fù)雜的子系統(tǒng)有了過多的耦合，隨著外部客戶程序和各子系統(tǒng)的演化，這種過多的耦合面臨很多變化的挑戰(zhàn)。它的目的是將雜亂或設(shè)計不好的應(yīng)用程序編程接口(API)再加上一層，把它包起來并提供一個容易看懂的新接口，本因就是提供一個簡單的接口，讓復(fù)雜龐大的程序接口隱藏起來。

　　我們可以借用北京烤鴨作例子，想象一下當(dāng)你聽到“北京烤鴨”時腦中浮現(xiàn)的是甚么呢?一只肉香四溢的烤鴨的全景圖嗎?若是直覺的、自然的反應(yīng)那就對了，所以我嘗試把facade設(shè)計模式直接用一目了然的成語作取代。如圖1所示。

　　如上圖所示，我們可以舉一個façade模式的例子。比如說，現(xiàn)在有一輛汽車，我們(客戶程序)要啟動它，那我們就要發(fā)動引擎(子系統(tǒng)1)，使四個車輪(子系統(tǒng)2)轉(zhuǎn)動。但是實際中我們并不需要用手推動車輪使其轉(zhuǎn)動，我們踩下油門，此時汽車再根據(jù)一些其他的操作使車輪轉(zhuǎn)動。油門就好比系統(tǒng)給我們留下的接口，不論汽車是以何種方式轉(zhuǎn)動車輪，車輪變化成什么牌子的，我們要開走汽車所要做的還是踩下油門。

　　前面說了一堆，讀者們一定會想問，到底北京烤鴨跟SQL Azure到底有甚么關(guān)系?答案是“目的相同”，也就是考慮到提供使用者一個易讀易寫的應(yīng)用程序編程接口。微軟的SQL Azure開發(fā)團隊，正在思考是否應(yīng)該在云端上就把SQL數(shù)據(jù)庫整個包裝起來，再提一個完整而簡單的應(yīng)用程序編程接口給它，藉此讓使用者能夠輕易上手。

　　另一個選擇是考慮到現(xiàn)有程序能夠很容易的運用上來的作法，可以讓SQL數(shù)據(jù)庫以原本的風(fēng)貌放置在云端，再透過標(biāo)準(zhǔn)的存取協(xié)議讓既有的程序都能夠立即能使用。這樣的抉擇也曾不斷的出現(xiàn)在一般的IT部門，其立足點是思考是否隱藏那些數(shù)據(jù)庫中的復(fù)雜表格信息，用簡單易用的API取代，提供程序人員更容易上手的程序環(huán)境。今天的SQL Azure正是歷經(jīng)這種選擇后的結(jié)果，也就是決定采不采用設(shè)計模式包裝技術(shù)在做這個選擇的好范例。

　　另外需要考慮，是否提供有效率的讀取云端數(shù)據(jù)的選擇。能夠快速讀寫數(shù)據(jù)庫中的數(shù)據(jù)一直被視為企業(yè)信息中心的必備技能，程序設(shè)計人員在進入信息單位報到之初，往往都必先從熟悉數(shù)據(jù)庫表開始，也只有在慢慢熟悉數(shù)據(jù)庫表的Layout后才能開始有產(chǎn)能。因此許多信息部門都會為此制訂一套數(shù)據(jù)庫的存取應(yīng)用程序編程接口，然后美其名為“快速數(shù)據(jù)庫存取API”，目的在讓程序設(shè)計人員能夠更簡單更輕易的上手。從此，新進人員只要用很短的前置時間來了解這份API就能很快的上手。上面這一段說詞，看起來非常合理，也真的有很多人這么做的，但實際上這么做卻隱含著一些不好的后遺癥。比方說，隨著人員及業(yè)務(wù)種類的增加，一旦應(yīng)用界面(API)不夠用的時候，負(fù)責(zé)維護的同事就會開始接到報怨及要求;要求新增合用的快速數(shù)據(jù)庫存取API，然后這個API就開始增加，而隨著人員及業(yè)務(wù)種類的增加，API就又得開始增加，這種情形會一直持續(xù)的發(fā)生一直到你受不了，終于，你提供了一個可以直接傳送SQL腳本到數(shù)據(jù)庫上執(zhí)行的API為止(這跟程序直接呼叫數(shù)據(jù)庫不用透過API，在意義上是完全相同的，因此這個API接口也就名存而實亡)。

　　SQL團隊的抉擇。這是一段有趣的話題，當(dāng)微軟的數(shù)據(jù)庫團隊面臨要將SQL服務(wù)器放在云端的時候，也碰到了跟上述話題同樣的問題，是應(yīng)該以提供各式服務(wù)接口讓用戶容易的存取，靠著強大好用的服務(wù)接口徹底的將SQL服務(wù)器隱藏起來?還是拿掉這個便利存取的抽象層，讓SQL服務(wù)器直接面對外部的程序接口呢?

　　最后的結(jié)果是，微軟選擇了讓SQL服務(wù)器直接面對外部的程序接口，也就是讓程序能夠運用T-SQL直接對數(shù)據(jù)庫作存取的動作。
 

　　SQL Azure開發(fā)團隊使得SQL服務(wù)器直接面對程序開發(fā)人員，能夠在客戶者端的程序中運用傳統(tǒng)的TDS(Tabular Data Stream)與位在云端的SQL服務(wù)器溝通，但基于安全與橫向擴展服務(wù)器數(shù)量的考慮，特別在中間設(shè)計了一層Gateway層，如圖2所示的Security Boundary 所指的就是Gateway層。

　　如圖2所示，我們隱約可以看出SQL Azure分成了好幾個層次，如果再參考圖3一起來看的話，就看得出來它實際上能夠分成四層，最下面是基礎(chǔ)架構(gòu)(Infrastructure)這是架構(gòu)底層的服務(wù)程序它摻雜著軟硬件的I/O配合，也就是處理大量CPU群組的地方，它負(fù)責(zé)橫向的多重架構(gòu)作業(yè)(Fabric)、故障移除(Failover)、復(fù)制(Replication)及負(fù)載均衡(Load Balancing)，當(dāng)然還包含軟件版本的自動更新維護(它也負(fù)責(zé)實時偵查軟件或是硬件所產(chǎn)生的異常現(xiàn)象并能自動采取相對的措施)等作業(yè)，這是一般云端架構(gòu)的基礎(chǔ)層。對于云端應(yīng)用程序而言，它提供一些自我管理的機制，目前仍然相當(dāng)神秘并沒有對外開放，不過一些基本的API將會在近期內(nèi)公開出來。

 圖3 SQL Azure架構(gòu)

　　SQL Server層是以SQL 2008為基礎(chǔ)上，修改成適合云端作業(yè)的數(shù)據(jù)庫層，所謂的“云端工作”指的是高可適用性(High Availability)及快速復(fù)制等配合功能。它可以接受傳統(tǒng)的Transact-SQL(T-SQL)指令，但從網(wǎng)絡(luò)端傳送過來的資料并不會直接進到SQL服務(wù)器內(nèi)，而是透過更高一層的Gateway層傳入。

　　Gateway層的較完整名稱應(yīng)該是TDS Gateway，當(dāng)程序進行SQL Azure聯(lián)機時，實際上是聯(lián)機到Gateway層，在這里進行防火墻及安全驗證的安全性的計劃后，聯(lián)機才會真正進入到SQL服務(wù)器內(nèi)，真正進行聯(lián)機的建立(所有的惡意攻擊、或非法的Login企圖都依靠Gateway層來做阻擋過濾)。但一旦通過Gateway建立聯(lián)機之后，就會由另一個通用管道負(fù)責(zé)后續(xù)的傳送作業(yè)，這樣做的目的則是為了減少通信上不必要的耽擱作業(yè)。

　　另外，網(wǎng)絡(luò)的再因特網(wǎng)的入口處，圖中在云的下方寫著LB的方塊，是整個SQL Azure中唯一面對因特網(wǎng)的部分，也就是程序唯一可以看得懂URL地址的部分，在網(wǎng)下就Gateway中存有的相對地址，它負(fù)責(zé)均衡分配進入點到各個Gateway層。如果你的程序是由Windows Azure呼叫進來的話，也是依循這個相同的端點來進入的。如圖2所示，最上方則是你的應(yīng)用程序，當(dāng)然你可以采用SQL client Libraries，或是ADO.NET Data Service或是其他更高階的程序語言來做開發(fā)，例如php等程序語言。這是由于開發(fā)團隊決定采用傳統(tǒng)的TDS(Tabular Data Stream)作中間的傳輸協(xié)議，造成使用這可以運用許多原有的或是標(biāo)準(zhǔn)的公具來做連線工作，甚至是偵錯或監(jiān)看的動作。

　　SQL Azure選擇以傳統(tǒng)的TDS為傳輸協(xié)議，而不是將SQL Server使用了一大堆的服務(wù)包裝起來，讓程序設(shè)計師十分容易延續(xù)對SQL SERVER的開發(fā)功能，這算是微軟成功的第一步，當(dāng)然SQL Azure為了適合云端的環(huán)境，也拿掉了一些不適合的功能，包括安全性、絕對路徑等API功能，參考圖2的上半部可以看出，ODBC及ADO.NET是標(biāo)準(zhǔn)的入口，因此，原本在ASP.NET端的大部分功能都能順利的運用在這里，使得Windows Azure能夠成為真正執(zhí)行云端運算(Cloud Computing)的關(guān)系數(shù)據(jù)庫服務(wù)，這是一種云端儲存(Cloud Storage)的實作，成功的提供網(wǎng)絡(luò)型的應(yīng)用程序數(shù)據(jù)儲存的服務(wù)，讓許多既有的程序只要少許的修改就能存取云端數(shù)據(jù)資源。

　　facade設(shè)計模式可以將雜亂或設(shè)計不好的應(yīng)用程序編程接口(API)再加上一層，把它包起來并提供一個容易看懂的新接口。簡單的接口可以讓復(fù)雜龐大的程序接口隱藏起來。模式與SQL Azure的共同關(guān)系既是“目的相同”，也就是考慮到提供使用者一個易讀易寫的應(yīng)用程序編程接口，這樣使得微軟從數(shù)據(jù)庫平臺架構(gòu)演變中，獲得更合理的設(shè)計抉擇。

     為IT168輯文，原文：http://tech.it168.com/a2010/0706/1074/000001074190_all.shtml

it知識庫：架構(gòu)抉擇:享用微軟SQL云平臺就像吃烤鴨，轉(zhuǎn)載需保留來源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請第一時間聯(lián)系我們修改或刪除，多謝。