云计算和数据

公告：本博客为微软云计算中文博客的镜像博客。部分文章因为博客兼容性问题，会影响阅读体验。如遇此情况，请访问原博客。

这篇博客对在云计算解决方案中操作数据进行总览性的介绍。

概览

对于绝大多数解决方案而言，数据都是至关重要的一部分。在云计算里面，绝大多数现成的建议都可以直接拿来用。但是云计算也有其独特之处。这篇博客将讨论以下两个用例：

• 将你存放在云中的数据发布至全世界
• 在云端的项目中使用你本地的数据。

通用的建议

无论是哪种用例，这些建议都是通用的。

选择一个拓扑

在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，真正的在云端进行测试。