Azure和Bing Maps API示例经验分享

　　头疼的Bug，糟糕的代码，崩溃的调试作为开发人员的你，遇到上述任何一种情况可能就会陷入抓狂。如果能直接获得需要的代码，编程的活儿就会轻松许多。

　　微软最新推出的一站式示例代码库，让开发人员可以免费获得所需的示例代码或向微软工程师提出示例请求，轻松解决常见的编程问题，大大减轻工作负担。

　　本文以一个名为AzureBingMaps的示例应用程序为例，分享了一些在开发该示例过程中积累的经验，以期对广大开发人员有所帮助。AzureBingMaps是一个旅游站点管理系统，演示了很多技术，可以认为是一个实际项目。

　　写这个示例的初衷

　　在Windows Azure论坛，我们常见到这样的开发人员：他们已经学习了很多开发技术，例如ASP、.NET、Silverlight等，并对这些技术有了较深入的了解。但当他们需要将学到的知识应用到实际项目中时，新的问题便产生了。

• 针对特定场景该如何选择平台和技术？

• 不同的技术怎样结合起来使用？

• 如果在使用某项技术的过程中发现了局限性该如何解决？

• 如果必须使用不熟悉的技术该怎么办？

　　如今的网络技术资源绝大多数都只针对某一种特定的技术，指导人们如何使用一个特定的功能，对那些希望学以致用、开发实际项目的开发人员而言，这远远不够。

　　鉴于此，我们开始尝试使用微软的各种技术开发一个相对完整的项目，体会大家可能遇上的问题，从而形成了本文。

　　选择合适的平台与技术

　　了解用户需求

　　在项目开发前，必须了解客户的需求。这项工作的范围很广，但由开发人员负责的部分通常仅限于选择合适的平台与技术。因此作为一个示例，我们省略了与客户访谈以了解需求的过程，直接将非功能性需求定义如下。

• 本系统在旅游旺季需要支持1,000,000个用户同时访问，在非旅游旺季只需要支持1,000个用户同时访问。

• 公司没有自己的数据中心，IT部门最多只能提供3台中档服务器给我们的系统。

• 我们团队对.NET和Visual Studio比较熟悉。

• 本系统对操作系统及网络环境并没有特定的需求。

• 第三方开发人员应该可以针对我们的服务自行开发客户端应用程序。

　　这些需求也正是我们的客户—Windows Azure论坛上参与讨论的开发人员—常常需要解决的问题。

　　选择合适的平台

　　需求明确地指出可伸缩性是必须考虑的因素。为了满足旅游旺季时1,000,000个用户同时访问的需求，我们可能会考虑如下方案。

• 使用一台高性能服务器，然而IT部门明确告诉我们他们只能提供3台中档服务器。

• 采用负载平衡，然而3台中档服务器即使采用了负载平衡也很难保证满足我们的需求。

• 寻找云计算供应商，将我们的系统部署在外部的数据中心，如果选择的供应商合适，支持多台服务器负载平衡，就能确保满足高并发访问的需求。

　　于是，我们的需求引领我们考虑选择云计算。然而市场上也有很多云计算供应商，选择哪家最适合呢？这个问题还是要通过需求来解答。

• 在非旅游旺季我们只需要支持1,000个用户同时访问，因此我们选择的供应商必须允许我们随时更改使用计划，例如，旅游旺季租用2,000台服务器，非旅游旺季只租用2台服务器。

• 鉴于项目组对.NET和Visual Studio比较熟悉，我们希望应用现有的知识进行开发，这意味着我们选择的供应商必须支持.NET。

• 既然我们的系统对操作系统和网络环境没有特定的需求，我们就不希望花太多的时间在这些环境配置上。例如，我们不希望手工配置操作系统和安装各种需要的软件；希望即使需要租用2,000台服务器，也可以让项目组致力于应用程序的开发，而不是基础设施的配置。

　　综上所述，我们发现Windows Azure平台可以满足需求。在Windows Azure平台中，我们可以随时简单通过修改配置文件的方式来选择租用几台服务器，而且理论上可租用的服务器数量确实没有上限。它也完全支持.NET平台，而且操作系统以及常用的软件（例如数据库），也不需要手工配置。

　　当然，我们承认如上定义正好符合WindowsAzure平台的需求，这也是出于我们是针对这个平台撰写示例的考虑。但在实际项目中，大家确实需要考虑上述因素。如果你不需要高度可伸缩性，Windows Azure平台可能就不适合你，毕竟它的价格相对于一般的Web供应商而言是比较高的。如果你对操作系统和网络环境有特定的需求，那么目前Windows Azure平台也不适合你。你应该根据实际需求，寻找合适的平台。

　　选择合适的技术

　　在选取技术的过程中，客户需求以及开发团队的经验也是非常重要的。

　　需求指出第三方开发人员需要针对我们的服务自行开发客户端程序，因此开发服务时我们需要选择一个能让较多客户端平台都接受的技术，最好是一个国际标准。于是我们决定使用REST。此外，我们的服务需要暴露一些数据给客户端，因此将使用OData。OData是基于REST标准，定义了如何访问数据的一种拓扑，并且被广泛地使用着。我们的开发团队熟悉.NET，于是我们选择在.NET平台上能方便地实现OData的一项技术，也就是WCF Data Services。

　　在数据存储方面，Windows Azure平台上有两种常见的数据存储服务：Table Storage和SQL Azure。考虑到Table Storage目前还有较多局限性（例如不支持排序），我们决定使用SQL Azure。不过SQL Azure也有自己的局限性，最重要的一点就是目前它不具备Table Storage所提供的自动伸缩功能，也就是说当数据量大的时候，如何确保高效访问数据，是一个问题。不过这个问题也不是特别难以解决，请参考本文设计可伸缩的数据库章节寻找解决方案。此外，SQL Azure还支持空间数据（Spatial Data），也就是存放地理信息的数据，我们示例的场景正需要地理信息，所以空间数据也是一个很自然的选择。

　　至于数据访问，.NET平台提供了Entity Framework，这是一种O/R Mapping的框架，可以让开发人员在不需要考虑如何撰写SQL语句的情况下进行数据访问操作，而将精力专注于面向对象的设计。不过目前Entity Framework对空间数据的支持并不很完美，所以采用它将会给项目带来一定风险。

　　另外一个选择是直接使用SqlConnection以及SqlCommand，但这种方式比较烦琐，而且代码也不易维护。综合考虑，我们决定先做一个简单的原型，尝试将Entity Framework和Spatial Data结合使用，如果在开发该原型的过程中遇上了太多困难，我们将采用SqlConnection的方式。当然最终证明困难并不是很大，于是我们的示例还是采用了Entity Framework。

　　最后还有客户端，在客户端的技术选择上，我们首先考虑是选择Web还是Desktop。绝大多数情况下，Web应用程序都占据着得天独厚的优势，因为用户不需要安装，甚至不需要下载。当然Web应用程序在用户体验上可能略有不足，不过随着HTML5以及Silverlight的普及，差距也是越来越小了。如今Desktop程序最大的优势在于能够访问更多的系统资源，以及可以更好地支持离线使用。

　　对于我们的场景而言，我们不需要访问特定的系统资源，而且可以暂时不考虑离线访问的状况，所以针对PC类的大型设备我们选择了Web。不过，手机类的设备则是另外一回事。大多数手机浏览器不仅相对而言屏幕较小，而且功能支持也比较少，例如Silverlight一类的插件不受支持，而且也缺乏PC浏览器常见的那种TabbedView一类的效果。所以如果针对手机设备开发，往往还需要选择该设备直接支持的技术。

　　至于为何选择AJAX和Silverlight两个PC客户端，以及Windows Phone，就纯粹是出于示例的需要了。还是那句话，如果你的需求不同，你就应该根据需求选择适合于当前项目的技术，而不是生搬硬套...