#AzureChat – 自动伸缩和虚拟机

我们很高兴地推出再一次的 #AzureChat,这是 @WindowsAzure 团队为您精心打造的一个在 Twitter 上进行的聊天活动! #AzureChat 专注于云计算的各个方面以及云开发的最佳实践。想要了解有关特定云服务的更多信息?希望获得相关提示和技巧、开发人员趋势以及最佳实践?#AzureChat 就是一个很好的地方,让您能够参与社区讨论,与其他开发人员分享您的看法,同时还能得到 Microsoft 专家的指导。 太平洋标准时间 12 月 5 日(星期四)上午 9:00,我们将邀请 Corey Sanders 和 Stephen Siciliano 举行一次在线问答讨论会,主要议题为自动伸缩和虚拟机。Corey 和 Stephen 分别从事于Virtual Machine 团队和Autoscale 团队。当您将这两者联系在一起, 您会得到一个可伸缩的和具有成本效益的系统, 可以利用它来部署您的工作负载。Stephen 和 Corey 将回答您任何在Windows Azure中有关伸缩和虚拟机的问题。 他们还将介绍一些最新的公告,包括用于自动伸缩的新SDK。我们建议您提前将问题提交到 @WindowsAzure。 #AzureChat 的工作形式: 您可以加入 Tweet“聊天室”,浏览并参与到对话中 您也可以使用 Hootsuite、Tweetdeck 或任何其他 Twitter 客户端。您只需使用话题标签 #AzureChat 设置一栏即可。 请在太平洋标准时间 12 月 5 日(星期四)上午 9:00 参加这次聊天活动。(如果您来晚了,可以在聊天过程中随时加入进来,此次活动时长为…

1

Windows Azure 社区新闻综述(#77 版)

欢迎查看最新版本的每周综述,其中包含有关云计算和 Windows Azure 的社区推动新闻、内容和对话。以下是本周的亮点。 文章、视频和博客文章 文章: Windows Azure 表存储简介,作者 Mike Wood(11 月 14 日发布) 博客:关于 #WindowsAzure,作者 Alexandre Brisebois(11 月 19 日发布) 博客:Windows Azure 存储性能最佳实践,作者 Nuno Godinho(11 月 20 日发布) 博客:Windows Azure 视图,作者 Grant Fritchey(11 月 19 日发布) 博客:SQL Server 2014 混合版:在 Azure 存储中存储数据文件 – 难以置信?作者 Greg Low(11 月 20 日发布) 博客:MessageHandler – 早期采用者计划,作者 Yves Goeleven(11 月…

0

分区 Service Bus 队列和主题

编辑人员注释:本文章由 Windows Azure Service Bus 团队的二级项目经理 Ruppert Koch 撰写。 上周,Microsoft 发布了 Azure SDK 2.2 和 Service Bus SDK 2.2。这两种 SDK 都具有新的 Service Bus 功能,即分区实体。利用这些 SDK(或通过在您的 HTTP 请求中指定 api-version=2013-10),可以在 Azure Service Bus 上创建和使用分区队列与主题,从而改进可靠性。与此同时,您还会发现,大多数用例中的最大消息吞吐量有所提高。 分区队列和主题是什么? 传统的队列或主题由单个消息代理进行处理并存储在一个消息贮存区中,而分区队列或主题由多个消息代理进行处理并存储在多个消息贮存区中。这意味着某个分区队列或主题的总吞吐量不再受单个消息代理或消息贮存区性能的限制。此外,一旦某个消息贮存区暂时中断,也不会导致任何一个分区队列或主题不可用。 简而言之,分区队列或主题的工作原理如下:每个分区队列或主题均由多个片段组成。每个片段存储在不同的消息贮存区中,并且由不同的消息代理进行处理。当一个消息发送到某个分区队列或主题时,Service Bus 会将该消息分配给其中一个片段。这一分配过程由 Service Bus 或发送方指定的分区键随机完成。如果客户端要从分区队列或分区主题的订阅接收某个消息,Service Bus 将检查所有片段中的消息。如果找到此类消息,它将挑选其中一个并将其传递给接收方。 启用分区 有三种方法来创建分区队列或主题。第一种方法是从您的应用程序创建队列或主题。启用分区,方法是将 QueueDescription.EnablePartitioning 或 TopicDescription.EnablePartitioning 属性设置为 true。这些标志必须在创建队列或主题时设置。不能对现有的队列或主题更改此属性。 或者,也可以在 Visual Studio 中创建分区队列或主题。我们在 New Queue…

0

Windows Azure Service Bus 推动财务服务门户的高可用性和可伸缩性

抵押贷款公司和评估管理公司面临着快速、复杂且数据量极大的业务流程。他们需要可快速、轻松设置且容量几乎无限的可伸缩的企业级服务,来对处理评估订单以及自动化流程本身所产生的所有文档和数据进行管理。 这听起来像是云计算平台的工作。 Schakra Inc. 的产品解决方案副总裁 Anil Balakrishnan 也这样认为。Schakra Inc. 是一家解决方案提供商,他们的客户包括 Microsoft 和 Vodafone。为对评估管理公司创建此类解决方案,Schakra 与 Bradford Technologies 和 Nasoft 进行了合作,并最终推出了名为 PortalDirect™ 的Unified Collateral Data Portal(UCDP™) 提交服务。Balakrishnan 说这开辟了同类服务的先河。 在创建该服务时,Balakrishnan 及其同事可以选择很多云计算平台,他们仔细考虑了所有选项,包括 Amazon SQS with SNS、SimpleDB 和 S3,但最终选择了 Windows Azure。 他说:“促使我们使用 Windows Azure 的是熟悉的开发人员体验和社区支持。此外,我们在 .NET Framework 和其他 Microsoft 技术方面具有丰富的知识和经验,更加便于我们使用 Windows Azure 及其平台服务克服开发困难,而不需要自定义解决方案。” 抵押贷款公司和其他用户访问 PortalDirect 以提交其评估订单,这些订单通过与第三方服务集成的多步骤工作流进行处理。为了在工作流内协调这些服务,开发人员选择了以消息为导向的体系结构。每种服务都与 PortalDirect 交换消息,以告知所有参与者为了进一步推动工作流必须采取的操作。这种基于消息的体系结构无需将特定节点与工作流关联,而是一个无状态系统, 相同节点可进行大规模伸缩。   在设计…

0

宣布公开发布 Service Bus 对 AMQP 的支持

编辑人员注释:本文章由 Windows Azure 集成服务的高级产品经理 Kent Brown 撰写。 经过六个月的公开体验后,针对 OASIS 高级消息队列协议 (AMQP) 1.0 版的 Service Bus 支持现将公开发布 (GA)。AMQP 是一个开放、可靠、高效的消息协议,它提供广泛的支持,包括商业实现和开放源代码实现。通过增加 AMQP 支持,意味着您可以在各种平台中使用Service Bus提供的代理消息功能 (队列和发布/订阅)  – 目前已有针对 C#、Java (JMS)、C、PHP/Python 客户端的AMQP 客户端实现, 针对Ruby、 Perl 和JavaScript 的实现也在进行中。 有关更多信息,请参阅 Scott Guthrie 的博客文章和本概述文章。 本文翻译自: http://blogs.msdn.com/b/windowsazure/archive/2013/05/23/announcing-ga-for-amqp-support-in-service-bus.aspx

0

基于任务的Service Bus API

编辑人员注释:本文作者 Scott Seely 是 Windows Azure Service Bus团队的开发人员。 我们最近通过 NuGet 推出了 Windows Azure Service Bus客户端 SDK 的最新版本。目前版本号为 v2.0.0-beta。这个版本的 SDK API 中有一些改进,为所有异步API提供了基于 System.Threading.Tasks.Task 的版本。这意味您可以编写普通人都可以阅读的异步代码。如果您想知道哪些类得到了更新,答案很简单:全部更新了!在您之前看到 Begin/End 对的所有位置,您现在都可以看到一个异步版本的方法。因为 SDK 更新版是在 .NET 4.0 上编译的, 因此能在 Visual Studio 2010 和 Visual Studio 2012 上运行。 在这个简短的博文中,原作者想说明几个基本点: 如何获得 SDK 如何用通过async/await使用 SDK 谈一点关于Task出现异常的情况 对于 SDK 的用户而言,最重要的一点是,您现在可以使用Service Bus SDK 来编写异步可读代码。 获取 SDK 公测版 目前的2.0…

0

使用Service Bus中间消息改善性能的最佳方法

这篇文章描述了如何使用Service Bus中间消息功能以某种方式使其产生最佳性能。你可以在MSDN上阅读整篇文章以了解更多的细节。 使用Service Bus客户端协议 Service Bus支持Service Bus客户端协议和HTTP。Service Bus客户端协议更有效,因为只要消息库存在,它就会维持与Service Bus服务的连接。它还实现了批处理和预读取Service Bus客户端协议对.NET应用程序是可用的,即使用.NET托管的API。只要可能,通过Service Bus客户端协议连接到Service Bus。 重复利用Factories 和 Clients Service Bus客户端对象,例如QueueClient 或 MessageSender是通过一个MessagingFactory创建的,它还提供连接关系的内部管理。在发送完一条消息之后,建议不要关闭任何factories 、 queue、topic 和 subscription clients对象,然后在发送下一条消息时重新发送它们。相反地,请重用factory和client来执行多个操作。关闭一个消息库删除与Service Bus的连接关系。建立一个连接是要付出很大代价的。 使用并发的操作 执行一种操作(发送、接受、删除,等等)需要一定的时间。这个时间包括Service Bus服务操作的执行时间和请求及回复的延迟。为了每次增加操作的数量,应并发地执行操作。如果客户端和托管Service Bus命名空间的数据中心之间的延迟时间长的话,尤其如此。 并发执行多个操作有几种不同的方式: 异步操作。客户端管道通过执行异步操作来进行操作。在前一个请求完成之前开始下一个请求。 多个库。由同一个库创建的所有客户端(发送者以及接收者)都共用一个TCP连接。能够访问该TCP连接的操作的数量限制着最大消息吞吐量。吞吐量可以由单个库获得,因TCP的往返时间和消息大小的不同而不同。 使用客户端批处理 客户端批处理允许一个queue/topic客户端来将多个发送操作处理成单个请求。它还允许queue/subscription客户端将多个Complete的请求处理成单个请求。默认情况下。客户端使用批处理的时间间隔为20毫秒。你可以在创建消息库之前通过设置MessagingFactorySettings.NetMessagingTransportSettings.BatchFlushInterval来改变批处理的间隔时间。这个设定会影响由该库创建的所有客户端。 MessagingFactorySettings mfs = new MessagingFactorySettings();  mfs.TokenProvider = tokenProvider; mfs.NetMessagingTransportSettings.BatchFlushInterval = TimeSpan.FromSeconds(0.05); MessagingFactory messagingFactory = MessagingFactory.Create(namespaceUri, mfs); 在低吞吐量、低延迟的情况下,你希望禁用批处理。如果要这么做,请将BatchFlushInterval设为0。对于高吞吐量的情况,将批处理时间间隔增加到50毫秒。如果使用多个发送者,则将批处理时间间隔增加到100毫秒。 批处理只能用于异步的Send 和 Complete的操作。异步操作被立即送往Service Bus服务。批处理不能用于Peek 或 Receive操作,也不能用于跨客户端的操作。 使用批处理的存储访问 为了增加queue/topic/subscription的吞吐量,Service Bus服务对其内部存储进行写操作时批处理多个消息。如果启用一个queue 或 topic,向存储中写消息时将会被批处理。如果启用一个queue 或 subscription,删除存储中的消息将会被批处理。成批的存储访问只会影响到Send 和Complete的操作;接收操作不受影响。 当创建一个新的queue、topic或subscription,批处理存储访问的时间间隔被设为20毫秒。低吞吐量、低延迟的情况下要在创建该实体之前通过将QueueDescription.EnableBatchedOperations设置为false 来禁用批处理存储访问。…

0

使用Service Bus Explorer 工具来管理和测试Topics、 Queues 和 Relay Services

2011年5月发布的Windows Azure Service Bus 社区技术预览(CTP)首次介绍了queues和topics。那时候,Windows Azure Management Portal不提供用来管理、创建和删除消息实体的用户界面,完成这项任务的唯一方法是使用.NET或REST API。为此,我们决定构建一种称为Service Bus Explorer 的工具来使得开发人员和系统管理人员能够连接到Service Bus命名空间,并管理其消息实体。 在过去的几个月里,我继续开发此工具并添加新功能,预期目标是促进新的基于Service Bus的应用程序的开发和管理。在此期间,Windows Azure Management Portal 引进了用户创建queues、topics和 subscriptions并定义它们的属性的功能,而不是为现有的subscription定义或显示规则的功能。另外,Service Bus Explorer可以完成这些功能,例如导入、导出和测试实体,而Windows Azure Management Portal目前还不能提供这些功能。为此,Service Bus Explorer工具成为了官方Windows Azure门户最完美的伴侣,并且它还可以用于搜索由Service Bus中间消息提供的开箱即用的功能(基于session的相关性、重复消息的可配置检测、延迟消息,等等)。 不久前我发表了一个帖子,在那个帖子里我解释了该工具的功能和实现的细节,可以在MSDN代码库中找到它的源代码。在这篇文章里,我解释了如何使用这个工具来管理和测试queues 和 topics。 关于Windows Azure Service Bus的更多信息,请参考下列资源: MSDN网站上的“Service Bus”话题。 Windows Azure博客上的文章:“Queues、Topics 和 Subscriptions”。 视频:“理解 Windows Azure Service Bus Queues (和 Topics)”。 Channel9网站上的视频:“ 使用Windows Azure Service Bus…

0

怎样将BizTalk服务器应用程序和Service Bus Queues 和 Topics整合起来

微软BizTalk服务器使相关组织能够与贸易伙伴一起连接并跨企业扩展异构系统。Service Bus是Windows Azure的一部分,旨在提供连接、队列和路由功能,不仅仅是为云计算应用程序而且也为非云端应用程序。两者一起使用使得在相当多的情形中你可以构建安全、可靠、可扩展的跨越云和非云端环境的混合解决方案,例如:微软BizTalk服务器。 与贸易伙伴交换电子文档。 向第三方显示防火墙后运行的非云端服务。 启用分支和中心后台办公系统之间的通信。 我最近在MSDN上发表了一篇文章,在这篇文章中我演示了如何以一种可靠、灵活与可扩展的方式将一个BizTalk Server 2010 应用程序与Windows Azure Service Bus Queues、Topics、Subscriptions整合到与外部系统交换的消息中。2011年9月份推出的Windows Azure AppFabric SDK中介绍到的Queues和 Topics是新的基于云计算的消息和整合的基础设施的基础,该设施向基于微软及非微软技术的云和非云端应用程序提供可靠消息队列和持久publish/subscribe消息功能。.NET应用程序要么从一个全新的托管的API (Microsoft.ServiceBus.Messaging) 要么通过WCF的一个新绑定 (NetMessagingBinding) 来使用这个新的消息功能,并且任何微软或非微软应用程序能使用一个REST样式API来访问这些功能。 在这篇文章中你将学习怎么在一个.NET和BizTalk服务应用程序中使用WCF来执行以下操作: 向Service Bus queue发送消息。 向Service Bus topic发送消息。 从Service Bus queue接收消息。 从Service Bus subscription接收消息。 将BrokeredMessage 对象的属性转化成BizTalk消息的上下文属性,反之亦然。 下图显示了文章中涵盖的情形之一。关于这点,Windows Forms客户端应用程序模拟一个line-of-business系统在非云端或云端运行,使用Service Bus messaging.infrastructure 提供的queue、topic和 subscription实体与BizTalk服务应用程序交换信息。 在MSDN 代码库可以找到这篇文章的相应代码。在MSDN上阅读整篇文章。 关于AppFabricService Bus的更多信息,请参阅下列资源: Windows Azure博客上的文章:“现在可用: 2011年9月版的Service Bus发布了”。 MSDN上的文章:“Queues、Topics和Subscriptions”。 MSDN上的话题:“AppFabric Service Bus”。…

0

现在可用:2011年9月版Service Bus

如这个星期BUILD上所宣布的 ,2011年9月版的Service Bus现在可用了。这是自2010年1月服务建立以来生产环境最大的功能更新。 Service Bus提供了安全的连通性和消息传送能力,使得能够构建云里分布式的和松散耦合的应用程序,以及穿过非云端和云端的混合应用程序。它可用于各种通信和消息传递协议和模式,并让开发人员免于担心交付保险、可靠的消息传送和规模。在这里你能够学习更多有关Service Bus的信息。的全 此版本引入了Service Bus的增强功能,通过支持Queues、 Topics 和 Subscriptions、Rules等特征来改善pub/sub消息传送。此版本还在Windows Azure平台上一些新的情形中起作用,例如: 异步云事件——向偶尔连接的客户端分送事件通知(例如,电话、远程worker、终端等等)。 事件驱动面向服务体系结构(SOA)——构建松散耦合系统,可以随着时间演变。 先进的内部应用程序消息传递——加载资源调配和为构建高扩张性且有弹性的应用程序的均衡负载。 Queues 和 Topics里具体化的新的消息传递功能作为服务预览在May 2011 CTP里首次可用 ,现在在Service Bus生产环境里也可用了。新的消息传递功能的一些详细功能,像唯独支持session连同跟踪session处理状态的功能,这些都直接被客户项目需求所告知的,这些项目是那些我们已经跟进的早期体验项目和在Service Bus上花了很大功夫的其他的一些微软开发成果。 改变了什么 在看到文档和开发实例后开发人员立即注意到的是新的消息传递功能的API与2011年5月份发布的CTP相比有所改变——响应客户的反馈。API变化的主要目标之一是合理化API和减少使用Service Bus新功能的代码量;下面我将给出几个例子。 另一个目标是使得API的运行时组件更加健壮——例如:开发人员不得不根据CTP中明确的残缺网络连接来处理异常并采取明确的步骤来替换“故障”的接收器或发送对象;在此版本中发布的消息传递客户端API将自动尝试重新连接,就像Service Bus的中级侦听器和客户端对象不能进入“故障”状态,要求由应用程序显示地恢复。 没有改变什么 开发人员不会看服务中断或产品中Service Bus行为发生巨大改变。即使这样,我们笼统地抽出桌布并换上一个新的——伴随一个很大扩展的功能集——而不移动桌上的水晶、瓷器或银器。现有的应用程序使用Service Bus仍然运行并且先前版本SDK的Microsoft.ServiceBus.dll assembly 1.0.x.x“能运行”——不需要对现有程序做额外的工作来适应新版本。 怎样使用新特性 然而,从.NET利用Service Bus的所有新功能确实需要使用包含新的消息传递功能API的Microsoft.ServiceBus.dll 1.5.x.x版本的新SDK。我们建议甚至是那些只使用Relay功能被重新编译和针对这个新程序集的测试以及1.0.x.x程序集的客户部署均作为定期的升级和部署循环的一部分开始被淘汰。 请记住新的1.5.x.x程序集只在完全.NET 4.0 framework中可用——从Silverlight、新的Windows 8 client profile、.NET 4.0 client profile或从需要.NET 3.5的应用程序中访问新的消息传递功能,开发人员可以利用客户端示例为Silverlight提供的通过Service Bus REST API来访问绝大多数功能。这些Silverlight示例和从Java、PHP和其他平台访问Service Bus的代码,在即将到来几个星期的course里将会可用——它们当中的每个都将使用适当的当地的运行时API,但是从术语和模式上重复.NET API。 使用REST API也是一个不错的选择,对于此版本,如果应用程序取决于Service…

0