雲端計算和資料

公告：本部落格為微軟雲端計算中文部落格的映象部落格。部分文章因為部落格相容性問題，會影響閱讀體驗。如遇此情況，請訪問原部落格。

這篇部落格對在雲端計算解決方案中運算元據進行總覽性的介紹。

概覽

對於絕大多數解決方案而言，資料都是至關重要的一部分。在雲端計算裡面，絕大多數現成的建議都可以直接拿來用。但是雲端計算也有其獨特之處。這篇部落格將討論以下兩個用例：

• 將你存放在雲中的資料釋出至全世界
• 在雲端的專案中使用你本地的資料。

通用的建議

無論是哪種用例，這些建議都是通用的。

選擇一個拓撲

在SOA的世界中，最重要的一個概念就是契約（contract）。在雲端計算的世界中，有關通訊的最重要的概念也是契約。當一個契約被很多雲端計算解決方案使用之時，我們就可以把它稱作一個拓撲了。

現在我們只討論資料通訊。如果你選擇了微軟的解決方案，我們推薦你使用Open Data Protocol(OData)。OData是基於諸如HTTP和AtomPub的國際標準建立的，它提供了一個跨平臺的資料通訊的方案。如果你雲端的程式使用OData來發布資料，這個世界上的任何一個程式，只要是支援OData標準，就都能享用你的資料。同理，你雲端的程式也能使用OData來訪問你本機的資料。

很多目前的微軟產品已經在應用OData了。例如：indows Azure Table Storage，Dallas，SharePoint 2010，SQL Server 2008 R2，等等。

如果你打算使用其他的拓撲，有必要仔細思考它們的可伸縮性，有多少人在使用它們，等等。

選擇一門技術

既然拓撲已選定，下一步就是選擇一門技術來實現這個拓撲了。

如果你選擇了微軟的解決方案，我們推薦你使用WCF來處理所有程式間的通訊。針對資料通訊，WCF Data Services自然是最好的選擇。

首先，WCF Data Services是WCF服務，所以你可以使用所有現有的WCF知識。其次，WCF Data Services已經實現了OData拓撲，於是你可以致力於你的資料格式在你的程式中的表示，而不是AtomPub/JSON這些真正在網路上傳遞的資料格式。再有，WCF Data Services致力於資料傳輸，而不是資料儲存。你的資料可以存放在任何位置：本地的資料庫，雲端的資料庫，外部的web services，xml檔案，等等。無論資料是怎麼來的，你都可以用同樣的方式來發布/使用它們。

如果你選擇了其他技術，有必要仔細考慮使用該技術的需要花費多少精力來完成你的解決方案，該技術能否提供將來的解決方案擴充套件，等等。

接下來我們來看看微軟的產品如何幫助你們完成上述兩個用例。

將你存放在雲中的資料釋出至全世界

許多雲端計算解決方案都不是孤立的，它們需要和外部世界互動。說到資料，你很可能直接了當的反應出來DaaS (Data as a Service，資料即服務)。

雲端計算的資料可以存放在許多地方，而且資料本身也是非常多樣化的。本文將致力於討論結構化的資料（例如xml），以及關係型資料（例如關聯式資料庫）。當前微軟提供了兩大產品用於在雲中存放資料。

• Windows Azure Table Storage：用於儲存結構化資料。使用動態架構 (dynamic schema)。
• SQL Azure：用於儲存關係型資料。使用靜態架構(fixed schema)。

下面這張表格比較了靜態架構和動態架構各自的優勢。

靜態架構	動態架構
關係型資料庫，例如SQL Azure	Windows Azure Table Storage
經過了幾十年驗證的可靠架構	高度可擴充套件性（統一的儲存，但是不同的程式可以使用不同的資料結構）
可以使用許多現成的工具	基於ODataWeb協議
可以使用O/R Mapping方便的在OO程式語言中運算元據	體現出了動態語言（dynamic languages）的優勢

針對你具體的場景，請選擇一個合適的資料儲存方式。通常來說，如果你的服務對外部世界開放了寫的許可權（允許外部世界更新資料），動態架構是一個比較好的選擇，因為第三方的程式很有可能需要適當的修改你提供的資料結構。然而目前Windows Azure Table Storage還有一些侷限性，它並未實現OData所有的功能，再加上關係模型已經有了好幾十年的經驗，你的開發人員也很可能非常熟悉關係模型，所以如果對你而言使用動態架構成本太高，請選擇靜態架構。

無論你選擇了何種架構，OData和WCF Data Services都能起到非常大的作用。

剛才已經說過，WCF Data Services可以使用任意的資料來源。它預設就提供了兩種資料提供者：ADO.NET Entity Framework (EDM)和LINQ to SQL (L2S)。如果你使用的是這兩種資料來源，通常只需要寫一小部分程式碼即可完成一個專案。如果你選擇SQL Azure存放資料，你就可以使用EDM和L2S做資料來源。

如果你使用了其它資料來源，（例如Windows Azure Table Storage），你需要將你的資料模型轉換成WCF Data Services理解的模型。如果你的資料是隻讀的，這個過程就很簡單，因為你只需要寫一個很普通的類來表示你的資料結構。如果你需要完整的CRUD功能，就必須實現IUpdatable這個介面。這被稱作“Reflection provider for WCF Data Services”。在更高階的場合中，你還可以使用“Custom Data Service Providers”。詳細資訊可以參考http://msdn.microsoft.com/en-us/library/dd672591(VS.100).aspx。

Windows Azure Table Storage本身也是使用OData拓撲，所以你可能會試圖讓你的客戶直接訪問你的資料來源。但是在絕大多數的場合下，請不要這樣做。你必須竭盡全力保護你的storage賬號的key（把它想象成你的密碼）。如果你將自己的密碼給與一個受你信任的使用者使他/她能直接訪問你的Table Storage，而他/她濫用了這份許可權，到最後，使你必須支付你的storage賬號的費用。我們推薦使用者將資料和業務邏輯封裝成服務，使用WCF Data Services就是完成這一任務的很好選擇。

你可以從All-In-One Code Framework (Azure).zip中下載一個示例，它演示瞭如何使用WCF Data Services將存放在Windows Azure Table Storage中的資料釋出至全世界。示例的名稱是：CSAzureTableStorageWCFDS/VBAzureTableStorageWCFDS該示例也提供了一個Silverlight客戶端用於測試服務。

在雲端的專案中使用你本地的資料

另一個常見的場景就是在雲端的專案中使用你本地的資料了。絕大多數場合下，這些資料都使用了靜態架構儲存於關係型資料庫中（例如SQL Server），所以你通常不會考慮如何儲存資料。在這個場景中，你更關心的是可連線性以及安全性。

很多公司都有防火牆和NAT。很難找到一臺機體，既可以自internet訪問，又擁有一個固定的IP地址，所以要在雲端的程式直接連本地資料庫也就很難了。許可權控制也是一個問題。雲端的程式並不在你的公司的區域網中，和資料庫不在同一個域裡，要使用整合Windows驗證是不可能的，而federated驗證目前還沒有針對資料庫提供很好的解決方案。

為了解決第一個問題，微軟提供了Windows Azure platform AppFabric Service Bus。Service Bus就好比你本機服務和雲端程式之間的橋樑，本地服務對於Service Bus而言其實是一個客戶端，所以即使本地伺服器位於NAT之後，它還是可以和Service Bus交流。Service Bus會把你雲端程式傳送的訊息傳達給你本地的服務。

Service Bus同時支援TCP和HTTP。大多數防火牆至少是允許outbounding連線通過80/443埠的，而這也正是Service Bus的最低需求。這樣一來，Service Bus便可以穿越NAT和防火牆。

安全是一個很複雜的話題，本文不準備詳細探討。但是有必要指出，Windows Azure platform AppFabric Access Control在很多場合下都是很有幫助的，而且它預設就和Service Bus整合。

當然，OData和WCF Data Services在這個用例中也很有幫助。

你可以從All-In-One Code Framework (Azure).zip中下載一個示例，它演示瞭如何使用Service Bus和WCF Data Services在雲端程式訪問本地的SQL Server資料。專案名稱是：CSAzureServiceBusWCFDS/VBAzureServiceBusWCFDS。這個專案也提供了一個ASP.NET客戶端用於測試服務。你可以很輕鬆的將這個客戶段轉換成一個Windows Azure的Web Role，真正的在雲端進行測試。