Azure Websites、Mobile Services和BizTalk Services之间加强了整合，这对面向云计算的开发人员来说无异于向前迈出了一大步。今年3月初，我曾测试了三大公有云的移动后端服务解决方案：亚马逊网络服务公司(AWS)Mobile SDK、谷歌Firebase和微软Azure Mobile Services。微软解决方案给人一个惊喜：微软全面实施了移动服务，而且Azure Mobile Services团队非常注重满足应用程序开发人员的需要，又不强迫用户选择解决方案，这给本人留下了深刻印象。于是，我们将;编辑选择奖;授予了它。

　　很显然，微软奉行;让人人都来测评Azure;的政策，因为该公司已经将Web服务和移动服务的后端整合提升到了新的水平。Azure App Service是目前处于预览版的托管服务，它把微软Azure Websites、Mobile Services和BizTalk Services整合成一项服务，并且增添了新的功能，以便能够与内部系统或云系统整合。它包含构建四种应用程序所需的工具和服务：Web Apps、Mobile Apps、API　Apps和Logic Apps(见图1)。我会在下面详细解释每一种应用程序。

　　App Service的价格方案不一，有的免费，有的每月每种App Service方案约300美元。较便宜的服务档次拥有数量较少的最多实例、手动扩展、较少的存储空间、较少的内存以及较少的处理器核心。如果你有较高的服务档次允许多个实例，就很容易启用并控制自动扩展(见图2)。你可以随时改动任何服务的档次。请注意：关闭服务并不能阻止它产生费用，要是你的数据存储空间小于1GB，将它降至免费档次也许能阻止它产生费用。删除服务当然会停止收费。

　　Azure Web和移动应用程序服务

　　图1：新的Azure Web和移动应用程序服务提供了可扩展的Web、设备、逻辑和API应用程序后端。这一类中的API管理服务和通知服务不是新的服务。

　　Azure SQL Server数据库的价格视数据库的大小和功能而定，有的每月只要约5美元，而有的每月需要约3720美元。性能级别以DTU(数据库吞吐量单位)来表示，这个新的度量指标结合了处理器、内存以及读写速率。现在可以获得的最低级别是5 DTU，最高级别是800 DTU或1000 DTU，这取决于你相信哪种说明文档。最高档次的数据库可以每秒执行约735个事务、存储500GB以及处理1600个并发请求。如果你需要更庞大的数据库，可以在Azure虚拟机中运行SQL Server，也可以在内部运行SQL Server，并从你的Azure应用程序服务连接至它。

　　Azure Web App Services

　　Web App Services基本上已更名为Azure Websites。与以前一样，它们也支持.Net、Node.js、PHP、Python和Java。你可以自动扩展它们，对流量实行地域管理，每个IP地址包含多个服务器名称指示(SNI)，并且让它们为持续集成作好准备，拥有多个试运行时隙(用于促销前测试，以及如果生产环境中发现错误，就恢复原状)。Web App Services可以托管运行WebJobs(下有讨论)，并且以取决于服务档次的频率来自动备份(参阅图2的左侧)。在新的Azure门户网站中，这一切管理起来要容易一点。

　　想把Azure Web或Mobile App连接到内部SQL Server数据库，你就需要为此建立一个混合连接。这需要在Azure云中使用BizTalk，并将混合连接管理器(Hybrid Connection Manager)安装到内部服务器上。这可能还需要创建一个虚拟网络。这一切都相当简单，而且文档很齐全。你在建立这种连接时，别忘了考虑网络延迟及其对应用程序性能的影响。

　　微软Azure App Services

　　图2：如果你的应用程序服务在允许多个实例的服务档次中运行，你就可以启用并调整自动扩展功能，那样它就能根据需要响应变化。

　　Azure Mobile App Services

　　在我之前对Azure Mobile Services的测评中，我提到了分析及构建入门级的To-do Azure Mobile Services应用程序和后端。Mobile App Services实际上拥有同样的入门级应用程序，只是目前支持的后端和客户软件选择比较少。唯一的后端用C#/ASP.Net编写，唯一的移动平台是Windows Phone、Objective-C/iOS、C#/Xamarin iOS和C#/Xamarin Android(见图3)。我没有遇到任何编译问题，不过我不得不更新安装的Visual Studio 2013和Xamarin，以便获得最新的Azure支持。我注意到过去是测试版附件的一些功能已向大众推出，比如面向iOS的断网操作和离线同步。

　　(我原本希望试一下用最新的Node.js Tools for Visual Studio即NTVS 1.0来调试Azure Node.js移动后端，但这种测试只好等一阵子了。)

　　作为Mobile App Services的一部分，Mobile Apps拥有当初作为Mobile Services时所没有的新功能，比如与内部系统整合(正如之前SQL Server所讨论的)和与SaaS系统整合(通过API Apps服务和连接件)。它们还可以使用试运行时隙(如上所述)、WebJobs、更好的扩展选项以及其他不大显眼的功能特性。

　　Azure Mobile App Services

　　图3：Azure Mobile App Services预览版目前支持四种客户软件的快速启动，这比之前的生产版Mobile Services中的11种有所减少。演示应用程序本身没有发生太大的变化。

　　连接件是负责将Swagger 2.0/JSON/REST接口呈现给Azure的预构建API App Services，有一个用于配置的Azure用户界面，知道如何使用其他服务(见图4)。REST当然是一种服务接口，采用了类似HTTP和HTTPS的结构;JSON当然是一种人可读的JavaScript对象。Swagger可能不大为人所知，这是一种用于记载REST API的规范。微软使用Swagger说明文档作为API App Services之间以及API Apps与其他App Services之间的一种;插件;。

　　WebJobs基本上是托管在Azure中的批处理服务，作为Web App Services的一部分;Mobile App Services包括面向后端的Web App，位于Mobile App Code之下。WebJobs可以扩展、自动备份，并具有适用于App Services的其他所有优点。WebJobs在类似Windows NT的环境中运行：除了你所要求的微软工具外，GNU Bash、Node.js、NPM、Grunt、Bower、Git、Mercurial、PHP和Python都安装在这个环境中。

　　免费服务档次中运行的WebJobs仅限于20分钟。除此之外，它们可以根据需要来运行、持续运行(相应的Web App Service 运行多久、它就运行多久)，或者按计划运行。眼下，你只好使用旧的Azure UI(manage.windowsazure.com)来建立计划任务。

　　Azure API App市场

　　图4：Azure API App市场为许多常见的SaaS方案(比如Salesforce、Twitter和Dropbox)提供了连接件。

　　你可以通过Visual Studio创建及部署WebJobs，使用持续交付，也可以通过新的Azure门户网站(portal.azure.com)来创建及部署。若是Mobile App Service，你需要添加WebJob：Mobile App Code > All Settings > WebJobs > Add。(Azure Batch Services有别于WebJobs，主要在于规模上，不过乍一看两者很相似，让人犯晕)。

　　Azure API App Services

　　如上所述，Azure API App Services使用Swagger和REST作为可插入式接口，使用JSON作为服务之间的数据格式。我在阅读了Azure教程后，通过Visual Studio构建并部署了使用C#编写的示例API App Service(见图5)，一旦我将Azure SDK升级到最新版本，没有遇到任何问题。你可以使用ASP.Net、Java、PHP、Node.js或Python来构建API Apps。Ruby在这里还没有得到支持，不过它在Azure中的其他地方得到支持。

　　眼下，C# 是Azure SDK将API App Service项目添加到Visual Studio 2013的唯一语言。我预计等到Azure API App Services推出正式版，这种情况会有所变化。

　　Azure API App Services

　　图5：Azure API App Services创建了Swagger记载的REST接口。你可以在Logic App Service中组合API App Services。

　　API App主机负责管理应用程序的验证，这让你免除了自行实施验证的头痛问题。除此之外，你可以在Web App Service上构建自己的REST接口，如果你希望这么做的话。我并不确信你能不能将REST/Swagger API暴露给Logic App Services中的组合服务，如果它是在普通Web App Service上构建的话。如果它作为API App Service来运行，你显然可以这么做。

　　Azure Logic App Services

　　正如我在前面所说，Logic App Services能够以可视化方式，将连接件及其他API Apps组合成一个业务流程(见图6)。在所示的例子中，我建立了一个流程，以便每小时搜索一次推特，寻找关于《InfoWorld》的推特消息，使用我的推特帐户，并将发现的任何推特消息保存到我的Dropbox，使用我的Dropbox帐户。我不得不授权这两个连接件应用程序都可以使用我的帐户。在测试时，手动运行该应用程序确实从推特消息创建了文件，并保存到我的Dropbox。Logic App Services方块的代码视图显示了为业务流程创建的XML。

　　所有Logic App Services都始于触发器。在图6中的示例中，我安排服务每小时运行一次。我可以像定义来自另一服务的事件那样来轻松定义触发器，比如SQL Server插入或更新触发器。

　　Azure Logic App

　　图6：Azure Logic App能够以可视化方式将连接件及其他API Apps组合成业务流程。在这个例子中，我建立了一个流程，以便每小时搜索一次推特，寻找关于《InfoWorld》的推特消息，使用我的推特帐户，并将发现的任何推特消息保存到我的Dropbox。代码视图显示了为该流程创建的XML。

　　Azure App Services在云后端整合方面向前迈出了一大步，甚至与之前版本的Azure Mobile Services相比也是如此。 如果你将它与亚马逊后端整合相比较――后者要求你手动到处拷贝粘贴服务验证GUID键，差异就非常明显。

　　小结

　　虽然是不尽完美的测试版，但Azure App Services在简化基于云的、后端服务整合方面却达到了新的高度。

　　既有免费，也有每月每个应用程序实例约300美元，按分钟计费，取决于所需要的资源

　　优点

　　让开发人员更容易在Azure上构建可扩展的Web和移动应用程序后端

　　让开发人员更容易在Azure上组合服务

　　让开发人员更容易将Azure应用程序与记录系统整合起来

　　降低了运行应用程序后端的成本

　　缺点

　　总体来看还是有一些缺陷，功能不太完善

　　无法完全移植到其他云

　　即使服务已被停用，依然收费，除非你将它们转移到免费档次或者索性删除。