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

　　軟件界的設計模式破除了語言的隔閡。Gamma的設計模式(Design Pattern)這個術語是在1990年，由Erich Gamma等人從建筑設計領域引入到軟件計算機科學里。該書出版至今，國內軟件界在開發應用程序上一直很少運用到設計模式的理論，追根究底的原因很多，溝通應該是其罪魁禍首之一。由我們不容易從字面上感受到這種設計模式的目的或精神，但我們可以經過反復的研讀才能體會出來。這種勞民傷財的現象，和設計模式當初被推崇的原則完全不符;所以它在這里也就無從生根，程序設計人員當然也就沒有從這里得到太多好處。

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

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

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

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

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

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

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

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

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

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

 圖3 SQL Azure架構

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

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

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

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

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

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

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

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