2012 R2 新增功能：通过 Windows Azure Pack 实现现代应用程序

 9 篇博客系列文章
的第 8 篇。

不要让标题蒙蔽了您 – 本篇博文对开发人员和 IT 专业人员都至关重要。

我之所以这样提醒是因为，当我在全球各地举行的技术大会上发言时，常常在我开始探讨开发人员前景和开发人员工具时，会议室中的许多 IT 专业人员就开始玩《愤怒的小鸟》，等待着开发人员部分快点结束。

为什么这对 IT 专业人员了解如何构建现代应用程序非常重要？答案很简单：IT 专业人员构建并运营承载这些应用程序的基础设施，而且您对如何构建这些应用程序了解得越多，您对平台要求的了解程度越深。

这是策略原因。另外还有战略原因。

如果您的组织尚未定义组织的云策略 － 这将指日可待。在这些对话中，您需要成为贡献者和领导者。通过掌握今天的主题，您可以成为对话的一员并定义长期的解决方案，而不是仅对他人制定的决策作出反应。

未来的 IP 专业人员角色需要您知道如何为云构建应用程序，以及这些应用程序工作的云基础设施是每位 IT 专业人员需要的内容，以便在定义组织的云战略的会议上发表您的意见。IT 专业人员还需要知道他们的团队如何适应这种以云为中心的模型，以及如何积极推动这些讨论。

这些 R2 博文将让您了解所需的内容，而且这种“实现现代业务应用”支柱将特别具有帮助作用。

在本系列的博文中，我们讲述了在私有云、托管云和公有云之间保持一致性的重要性，而且还探讨了 Microsoft 的愿景和提供一致云方面的独特性。Windows Azure Pack 是 Microsoft 在公有云领域进行创新的一个绝佳典范，而且为数据中心带来这种创新的优势。

Windows Azure Pack – 从字面意思上来说 – 是在我们的公有云中历经检验和证明的一组功能。现在，您可以使用这些功能来增强您的云，并确保实现我们认为非常重要的“一致性云”。

Windows Azure Pack 的一大优点是在构建应用程序之后，可以在任何 Microsoft 云（私有云、托管云或公有云）中部署和运营应用程序。

这种灵活性意味着您可以构建应用程序，最初部署在私有云中，然后，如果想在以后将应用迁移到服务提供商或 Azure，可以执行相应的操作，而不必修改应用。使类似的任务变得简单是我们有关云一致性承诺的一个重要组成部分，而且它是只有 Microsoft（并非 VMware，并非 AWS）才可以提供的东西。

这种使应用在环境之间迁移的能力，意味着应用程序和数据决不会锁定在一个单独的云中。这使您可以根据组织的需要、监管要求或者任何运营条件的变化而轻松地进行调整。

这种一致性和连接性的一个重要组成部分是 Windows Azure 服务总线，这将是今天博文的一个主要重点。

自 2010 年以来，Windows Azure 服务总线一直是 Windows Azure 的一个重要组成部分。我不想过度强调这一点，但是，服务总线在 Azure 中经历检验的时间已超过 3 年之久。现在，我们正式向您提供，以便让其在数据中心中运行。以下几点可以让您快速了解服务总线对 Microsoft 的重要性：服务总线在所有 Windows Azure 计费功能中使用，而且它负责收集所有评分和结果数据，并发送至 Halo 4 排行榜（现在，实在是太重要了 – 只要问问我的孩子们就知道了！）。不言而喻，负责 Azure 计费的人员和铁杆玩家不能容忍在获取数据时遭受任何延迟或停机时间。

对于今天的主题，请花一点时间切实了解 R2 系列中应用程序开发和应用程序平台功能。我想，您将会对如何介入这个过程并领导您的组织感到无比兴奋。

本篇博文由 Windows Azure 首席程序经理 Bradley Bartz 撰写，深入介绍了 Windows Azure Pack 和 Windows Azure 实现的新功能和令人吃惊的应用场景。与本 2012 R2 系列中的其他博文一样，您可以在本博文结尾处“后续步骤”下查看各个指向本博文中所介绍主题的更多信息介绍的链接。

* * *

 

在构建现代应用程序时，开发人员希望能有一种连接多层应用程序的方法，以及使用由第三方供应商所提供服务的方法。现代应用程序中不同的层可能具有不同的承载方法，例如前层组件常常被编写为 Web 应用程序，而后端服务可以托管在虚拟机中。

Windows Server 2012 R2 平台提供多种承载备选方案，但仍然需要实现应用程序的组件和服务之间的连接。其中一个常见的方法是使用代理交换消息。

两年前，我们推出的 Windows Azure 服务总线可以在公有云中提供消息传递功能。自发布以来，除了基本的后端/前端模式之外，我们见证了消息传递功能具有宝贵价值的多个应用场景。我们见证了用于将客户端和设备与云服务相连接的消息传递，以及使用消息传递实现集成的应用场景。

就在一年前，我们发布了 Service Bus for Windows Server v1.0，这使开发人员能够在自助管理的环境中和在开发人员的计算机上构建、测试和运行松散耦合的、消息驱动的应用程序。

现在，我们在发布 Windows Server 2012 R2（正好是在我们发布 Service Bus 1.0 for Windows Server 以及在内部部署引入代理型消息传递运行时功能之后一年！）之时，非常自豪地发布了代理的第二个版本，即 Service Bus 1.1 for Windows Server。

在这个版本中，我们在作为 Windows Azure Pack 一部分的集成体验方面进行了大量投入，目标是带来与 Windows Azure 中现有的体验相一致的自助租户体验。

我们用心倾听客户的意见，注重改进 Service Bus 1.1 for Windows Server 和 Windows Azure Pack 的以下 3 个核心应用场景：

1. 采用服务总线的应用程序消息传递模式
   我们通过服务总线支持现代应用程序中使用的基本消息传递模式和高级消息传递模式。对于这个版本，我们还增加了新的消息传递功能、附加协议和简化的 API，以便使开发人员能够更快地编写更好的应用程序。
2. 跨云管理消息传递实体
   无论您是针对公有云、私有云还是托管云进行开发（借助服务提供商），开发人员都可以在编写应用程序之后，在这些云中的任意位置使用这些应用程序 － 不需要重新编译。这可以通过仅仅更改配置文件中的条目来完成。
3. 通过服务总线提供备选方案
   无论您是为他人开发软件和服务的独立软件供应商、部署自主开发应用程序的企业，还是寻求轻松部署消息传递组件的开发人员，您都可以在拓扑中使用服务总线。对于这个版本，我们改进了针对企业和服务提供商的托管功能，从而实现了新的承载拓扑。

应用场景 1：采用服务总线的应用程序消息传递模式。

为了实现各种消息传递应用场景，服务总线提供消息队列和“发布/订阅”主题。

队列是按发送日期排序的消息存储。一个或多个发送方可以向队列发送消息，而一个或多个接收方可以从队列读取和删除消息。接收方收到消息之后，其他接收方无法收到该消息。

队列通常用于：

• 负荷量：接收方可以按自己的节奏处理消息。
• 临时去耦：如果接收方脱机，发送方不会受到阻止。
• 负载平衡：多个接收方竞相获取消息；自动负载平衡。

一个主题可以具有多项订阅，每项订阅的行为与队列相似。一个或多个发送方可以向主题发送消息。每条消息可以从主题复制到每项订阅。如果接收方接收来自不同订阅的消息，则每项订阅获取消息的一份副本。用户可以定义筛选条件，确定将哪些消息复制到哪些订阅。

主题通常用于：

• 消息分发：向一个以上的接收方提供相同的消息。
• 消息筛选：订阅方可以根据业务逻辑筛选消息。
• 消息分区：接收方使用筛选条件相互获取专有的消息流片段。

通过服务总线传递消息：构建松散耦合的应用程序

在紧密耦合的系统中，如果任何其中一个组件出现故障，整个系统都会出现故障，从而造成极坏的用户体验。组件之间的通信通常基于同步或异步调用来执行任务。

例如，请考虑从商店前端（Web 应用程序）至后端服务（比如装运和跟踪）执行调用的零售商应用程序。参见下面的图文块 1。

图文块 1：紧密耦合的应用程序。

通过引入消息队列，可以松散地耦合前端和后端应用程序。商店前端向队列发送装运请求，请求加入队列之后，商店前端向确认订单的用户发送确认函。装运服务按自己的节奏从队列提取订单。如果大量订单到达，而装运服务无法及时处理，或者如果装运服务暂时不可用，商店前端仍然可以处理新的订单。同时，在商店前端应用程序关闭的情况下，装运服务仍然可以处理已在队列中的订单。

扩展松散耦合的应用程序（参见下面的图文块 2 和图文块 3）非常简单。应用程序可以包含多个商店前端或装运服务的实例。队列使多个发送方和接收方可以向队列发送消息（或者从队列接收消息）。同时，队列保证每条消息只被处理一次。监控队列长度使您可以确定是否需要扩展应用程序。

图文块 2：松散耦合的应用程序。

图文块 3：扩展松散耦合的应用程序。

通过服务总线传递消息：发布－订阅模式

在某些系统中，必须由多个独立服务处理同一订单。除了装运服务之外，我们可能还需要由 CRM 系统处理每份订单。其中的一些订单将由欺诈检测系统进行处理。通过用主题和多项订阅取代队列，装运服务将继续接收每份订单的副本，同时 CRM 和欺诈检测系统接收这些订单的其他副本。由于欺诈检测系统只需要检查订单的子集，请根据欺诈检测的订阅定义筛选条件（参见下面的图文块 4）。针对订单的任何属性（例如采购价格）都可以完成筛选。

图文块 4：发布－订阅。

通过服务总线传递消息：跨平台互操作性

由于应用程序可以采用不同的方法与服务总线相连接，因此，它可以支持三种通信协议：

• 服务总线消息传递协议 (SBMP)
  这是一种基于 SOAP 的针对 TCP 的专有协议，这种协议具有丰富的功能，而且非常高效。服务总线消息传递 API，由 Azure .NET SDK 公开，这种协议允许客户端应用程序通过 SBMP 与服务总线进行通信。Azure .NET SDK 还公开了 WCF NetMessagingBinding。
• 高级消息队列协议 (AMQP)
  这是一种由国际标准化机构指定的开放协议。服务总线实施 AMQP 1.0，即标准的当前版本。与 SBMP 类似，Azure .NET SDK 允许应用程序通过 AMQP 与服务总线进行通信。除了 Azure .NET SDK，其他第三方客户端实施有各种语言的版本，例如 Apache Proton-C、Apache Qpid 或 Java/JMS AMQP 1.0（参见下面的图文块 5）。所有 AMPQ 1.0 客户端都可以与实施 AMPQ 1.0 的任何消息传递服务器或服务进行通信。可以在此处获取有关服务总线和 AMQP 的更多信息。
• HTTP/HTTPS
  这种协议允许采用与语言无关的方法来访问服务总线。HTTP 适用于 .NET、Visual Basic、Python、PHP、Java、Node.js 和其他语言。所有基本服务总线功能都可以通过 HTTP/HTTPS 获取。其中一些高级功能（例如会话）只能通过 SBMP 或 AMQP 获取。

图文块 5：服务总线支持的语言和协议。

习惯上，以消息为导向的中间件产品使用专有协议实现客户端应用程序和代理之间的通信。这意味着选择特定的供应商消息传递代理之后，必须使用该供应商的库，才能将客户端应用程序连接到代理。这将导致“锁定”该供应商，原因在于将应用程序移植到不同的产品需要对所有已连接的应用程序重新编码。

而且，连接来自不同供应商的消息传递代理非常棘手，而且通常需要应用程序级桥接，才能将消息从一个系统迁移到另一个系统，并在专有消息格式之间转换。

AMQP 1.0 是一种高效、可靠的线级消息传递协议，它可以用于构建强大的跨平台消息传递应用程序。该协议具有一个简单的目标：定义在双方之间安全、可靠、高效地传输消息的机制。

对于 Service Bus 1.1 版本，我们非常高兴地宣布 服务总线中现在提供 AMQP 1.0 支持功能。

增加对 AMQP 1.0 消息传递协议的支持使我们的客户能够以全新的方式体验消息传递。此版本实现的一个重要的新应用场景是在多个平台中编写的、在多个操作系统上运行的应用程序之间交换消息。

图文块 6（参见下文）说明了服务总线现在实现的丰富连接模式。

图文块 6：涉及各种编程语言的连接应用场景。

应用场景 2：跨云管理消息传递实体

基础设施层的创新使组织能够向业务组提供基于订阅的 IT 资源，从而开始担当类似云供应商的作用。此外，服务提供商现在可以提供更高级的云服务，比如平台即服务 (PaaS) 甚至软件即服务 (SaaS)。

在这种全新的连接服务和移动员工队伍的环境中，云战略决策可以影响整个组织 – 不仅仅是 IT 支出结构。

借助 Service Bus 1.1 for Windows Server 和 Windows Azure Pack，对于云战略，我们采用了一项关键原则：多个云中服务总线租户体验的一致性。多个云中服务总线租户体验的一致性。

换句话说，涉及代理消息传递的应用场景（比如与队列松散耦合和发布－订阅主题）在多个云产品中是一致的（但不一定相同）。

云一致性体现了使用服务总线的各个方面：

1. Windows Azure 和内部部署中使用相同的客户端 SDK 。
   请记住，由于发布节奏的差异，在某些时间点，最新的 SDK for Windows Azure 比私有云中支持的版本更新。但无论如何，始终存在一个二者均支持的 SDK 版本。
2. 对基于客户端的共享秘密采用相同的授权模型 。
   虽然公有云（例如 ACS）和内部部署（Windows 集成安全性）支持其他身份验证机制，但产品之间使用共享访问秘密是一致的。
3. 通过更改配置切换到选择的服务总线 。
   SDK 支持使用连接字符串来连接到服务总线。此连接字符串可以从配置读取，或者在运行时馈送到应用程序。
4. 自助租户门户与 Windows Azure 门户一致。
   一种基于 Web 的管理门户，用于创建订阅、服务总线命名空间和实体（队列和主题）。
5. 利用托管的服务总线支持 Windows Azure PowerShell Cmdlet 。

接下来，我们将解释服务总线自助租户体验如何遵循 Windows Azure 中的租户体验 － 以及开发人员将服务总线与应用程序配合使用所获得的一致体验。

租户体验

图文块 7：租户体验。

 

订阅、计划和服务总线命名空间

当在 Windows Azure Pack 中创建订阅和选择要使用的计划时，租户门户反映可以通过此订阅获取的服务。在所选的计划拥有已启用服务总线云的情况下（参见下面的图文块 8），租户可以查看门户中可用的服务总线，然后可以创建服务总线命名空间。Windows Azure Pack subscriptions 和计划（在本系列以前的一篇博文中已探讨）。

图文块 8：创建服务总线命名空间。

创建服务总线实体 – 队列和主题

为了创建队列和主题等消息传递实体，服务总线要求您首先创建一个命名空间。服务命名空间用于寻址、隔离和管理基础消息传递实体。所有服务总线消息传递实体均在服务命名空间的范围内创建。

通过自助门户创建队列非常简单、直接。借助“快速创建”功能，只需指定队列的名称和命名空间的名称（参见下面的图文块 9）。在未选择一个命名空间的情况下，这种快速创建体验将创建一个新的命名空间。

图文块 9：创建服务总线队列和主题。

设置队列级别的权限

Service Bus 1.1 for Windows Server 支持使用以下方式配置身份验证：

• Windows 集成安全性，根据用户的域凭据对用户进行身份验证。
• 共享访问秘密，根据共享秘密对用户进行身份验证。

服务总线支持两个级别的授权规则：

1. 命名空间级别授权适用于在此命名空间范围内定义的所有实体（队列和主题）。
2. 实体级别授权的范围为单个实体。在应用程序需要访问命名空间中实体子集的集成应用场景中，使用实体级别授权。

每项授权规则包括一个（或多个）权限，其中包括：管理、发送和聆听（参见下面的图文块 10）。

 

图文块 10：定义适用于命名空间实体的授权规则。

 

 

基本队列监控

在创建消息传递实体时，应用程序可以发送和接收消息。自助租户门户公开每个实体的基本监控属性，例如长度和最后访问时间，指明发送或接收消息的时间（参见下面的图文块 11）。

如果需要更高级的查询，可以使用服务总线 API 发出查询，比如：“Get me all queues which have more than 10 messages.”

图文块 11：监控队列或主题。

开发人员体验

在借助服务总线开发应用程序时，公有云和私有云中的一致性以使用相同的客户端 SDK 开始。事实上，如果您想在环境之间切换，则不需要更改应用程序或者重新构建应用程序。换句话说，通过更改配置文件中的单个条目，可以选择要使用的代理：私有云、托管云或公有云。

此外，只有将服务总线本地安装在使用 Express Database 的客户端操作系统上的情况下，Service Bus 1.1 for Windows Server 才会出于开发目的而支持本地部署。

可以在此处找到完整的端到端体验样本。

连接到服务总线

如上所述，单个配置条目指定要使用的代理。我们称之为服务总线连接字符串。在 Visual Studio 中创建新项目和通过 NuGet Package Manager 向服务总线 SDK 添加引用时，将向包含空连接字符串的配置文件（app.config 或 web.config）添加新的条目。

在部署应用程序时，用一个指向服务总线云、命名空间和安全设置的字符串取代连接字符串。

 

<appSettings>     <!-- Service Bus specific app settings for messaging connections -->     <add key="Microsoft.ServiceBus.ConnectionString" value="Endpoint=sb://[your namespace].servicebus.windows.net;SharedSecretIssuer=owner;SharedSecretValue=[your secret]" />   </appSettings>

 

发送消息

虽然服务总线提供许多高级消息传送功能，但最简单的应用场景就是发送和接收消息。

发送消息需要使用连接字符串以及提供一个向之发送消息的实体（队列或主题），使应用程序连接到服务总线。下面的示例使用配置文件中提供的连接字符串，连接到名称在本地变量中指定的主题。

// creates a topic client with a provided topic name. TopicClient topicClient = TopicClient.Create(ServiceBusTopicName); // creates a simple brokered message and send it over. topicClient.Send(new BrokeredMessage("Hello World"));

 

请注意，在使用主题之前，需要创建主题。

接收消息

在向队列或主题发送消息之后，消息保留在队列或主题中等待使用（已接收）。借助 Service Bus 1.1 for Windows Server 和 Windows Azure Pack，我们简化了应用程序接收消息的方法，并且推出了一种事件驱动型编程模型。在此模型中，您指定期望完成的操作，SDK 执行其余的操作。

下面的代码片段显示了使用来自服务总线订阅消息的最简单方法。

SubscriptionClient subsClient = SubscriptionClient.Create(ServiceBusTopicName, subsName); subsClient.OnMessage((receivedMessage) =>              {                                        Console.WriteLine(string.Format("Processing recived Message: Id = {0}, Body = {1}", receivedMessage.MessageId, receivedMessage.GetBody<string>()));             });

 

请注意，这并非一个完整的样本。例如，它缺少异常处理和性能优化。但此示例仍然证明了使用来自服务总线消息的简单程度。

应用场景 3：利用服务总线承载备选方案

通过发布 Windows Server 2012 R2 和 Windows Azure Pack，我们已经确定了使用服务总线的一些关键部署应用场景：

1. 本地托管和管理
   在本地 IT 团队管理多项部署而且每项部署针对不同的应用程序或业务部门的企业中，可以发现这种应用场景。这种应用场景是管理员体验首次与租户体验相分开。
2. 在多个应用程序之间共享
   这是较大规模的组织常见的应用场景，在此情况下，多个应用程序使用同一服务总线实例。在此应用场景中，应用程序可以或不可以在它们自己之间交换消息。这种拓扑主张扩展服务总线部署，以及为服务总线管理引进多个租户。
3. 在公有云中托管和专用
   在此应用场景中，提供 IT 服务的宿主寻求提供 PaaS 服务（包括消息）的方法。作为 Windows Azure Pack 的一部分，服务总线支持从一个单独的门户管理多个部署、将服务提供商与租户门户体验相分开，并且支持在租户之间创建隔离的计划和订阅。

此外，在以下情况下，客户也寻求“自托管”的代理：

1. 开发人员环境
   服务总线托管在开发人员的机器上（潜在的虚拟机），从而实现本地环境中的应用程序开发。这种拓扑的挑战是实现仅包括运行时组件的轻型部署。
2. 利用应用程序嵌入
   在此应用场景中，软件供应商在专用服务器上部署解决方案（包括服务总线）。除了运行时消息的轻型部署之外，这种拓扑需要一种通过脚本和 API 实现服务总线部署和管理自动化的方法。

除了上面提到的拓扑，Windows Azure 基础设施即服务 (IaaS) 完全支持服务总线，包括支持 SQL Azure。

接下来，我们将解释服务总线体系结构如何适应 Windows Azure Pack 整体体系结构，同时仍然实现消息传递运行时组件的轻型部署。我们还将描述服务提供商体验如何支持托管应用场景（共享或专用）。

服务总线体系结构

图文块 12：服务总线体系结构。

服务总线体系结构的一些关键要求包括：

• 服务总线需要 2008 R2 SP1 或更高版本的 64 位 Microsoft 操作系统。
• 其他平台组件有 Microsoft .NET Framework 4.0 PU3 和 Windows PowerShell 3.0。
• 作为持久的消息存储，服务总线需要 SQL Server 2008 R2 SP2 或更高版本。
• 服务总线设置安装以下本地服务：Windows Fabric、服务总线网关、消息代理和服务总线管理 API（资源提供商）。
• 外部管理组件（例如 Windows Azure Pack）潜在地单独安装在不同的服务器上。

服务提供商体验

借助 Service Bus 1.1 for Windows Server 和 Windows Azure Pack，我们推出了服务提供商体验。

在以前的版本中，我们借助一组用于配置的 PowerShell CmdLet 和用于监控的 Management Pack 帮助管理员。在我们开始进行 R2 规划时，客户反馈非常明确：他们希望实现租户的自助体验，并且需要一种管理不同规模和 SLA 的多项部署的方法 － 而且，他们希望所有一切均位于同一门户下。

为了实现客户的需求，我们通过提供以下功能，使服务总线的服务提供商体验与 Windows Azure Pack 中实现的其他服务体验保持一致：

• 自动部署新的服务总线云，同时选择用于计算的资源池，以及提供不同 SLA 水平的数据库。
• 能够在服务提供商的门户中了解服务总线状态、规模和使用情况。
• 通过向 Windows Azure Pack 计划增加服务总线资源，支持优惠和租户订阅。

已在此处探讨的服务提供商体验包括以下三个步骤（参见下面的图文块 13）：

1. 部署 Windows Azure Pack 并启用管理员的门户和租户的门户。
2. 服务总线云设置（自动或手动），并在服务总线云和门户之间创建信任关系。
3. 编写计划和添加服务总线资源（要使用的云）。

图文块 13：服务提供商体验。

连接到现有的服务总线云

如上所述，您可以通过 Windows Azure Pack 自动功能自动部署服务总线。但是，在手动安装服务总线的情况下，或者甚至从较早版本升级时，需要通过服务提供商的门户连接服务总线部署。

从门户的主屏幕，单击“新建”，然后单击“服务总线云”，选择要连接的服务总线云（参见下面的图文块 14）。

图文块 14：连接到现有的服务总线云。

与所有 Windows Azure Pack 服务一样，服务总线提供两组 REST API 由 Windows Azure Pack 门户使用。这些 API 通过两组凭据进行身份验证，在连接到服务总线云时，需要提供这些凭据。

服务总线云的基本状态监控

在将服务总线云连接到服务提供商门户时（参见下面的图 15），管理员可以列出所有云、查看每个节点的基本状态数据，并监控状态和空间消息传递数据库（参见下面的图文块 16）。

图文块 15：连接到服务总线云。

图文块 16：监控服务总线消息传递数据库。

 

通过 System Center Operations Manager 监控服务总线状态

与许多其他云服务一样，通过 System Center Operations Manager 可以对服务总线的状态进行监控（请参见下面的图文块 17）。Service Bus Management Pack 监控云的各种状态，其中包括状态/基础数据库、主机和服务。

根据一组丰富的监控规则和内置的提醒，管理员可以借助 System Center Operations Manager 检测与服务有关的问题和根本原因。

图文块 17：在 System Center 中监控服务总线。

 

 

 

后续步骤

• Service Bus 1.1 for Windows Server
  在此 MSDN 的深入技术概述中了解有关服务总线特点、组件和功能的更多信息。
• 服务总线主页
  在 Windows Azure 站点查阅视频教程、下载和其他信息。
• Windows Azure 服务总线中的 AMQP 1.0 支持功能
  有关如何使用开放标准协议构建跨平台、混合型应用程序的其他信息。
• 服务总线论坛