你好,游客 登录 注册 发布搜索
背景:
阅读新闻

微软Azure App Services让云开发更轻松

[日期:2015-04-08] 来源: 51CTO  作者: [字体: ]

  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 App Services优缺点剖析

 

  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优缺点剖析

 

  微软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 App Services优缺点剖析

 

  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 App Services优缺点剖析

 

  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 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 App Services优缺点剖析

 

  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应用程序与记录系统整合起来

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

  缺点

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

  无法完全移植到其他云

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

收藏 推荐 打印 | 录入:574107552 | 阅读:
相关新闻       微软 Azure App Services 云 
本文评论   查看全部评论 (0)
表情: 表情 姓名: 字数
点评:
       
评论声明
  • 尊重网上道德,遵守中华人民共和国的各项有关法律法规
  • 承担一切因您的行为而直接或间接导致的民事或刑事法律责任
  • 本站管理人员有权保留或删除其管辖留言中的任意内容
  • 本站有权在网站内转载或引用您的评论
  • 参与本评论即表明您已经阅读并接受上述条款